"adapter resource shortage"?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I recently started trying to run a Sun Fire X4100, with amd64 5.2.

I did a large data transfer to it, to a filesystem (FFS with no
particular options) mounted -o async.  The machine has way more than
enough RAM to buffer everything I copied, so the copy completed
reasonably quickly, limited mostly by the sending system's disk (the
network was running gigabit).  But, all through it, I was seeing

sd1(mpt0:0:1:0): adapter resource shortage

appearing once a second on the console (sd1 is the drive I was copying
to, the one mounted -o async; the OS is on sd0).  These stopped when
the transfer finished; when I told it to sync, in preparation for
unmounting, they started again, and, watching the disk's busy light, I
would estimate it is busy between 1/3 and 1/2 the time with a cycle
time of about 1Hz, which is cripplingly inefficient.

Reading the code leads me to suspect this is a perfectly normal
resource shortage in the presence of more transfers pending than the
hardware can handle.  However, arguing against this are (a) that
someone felt that message worth printing and (b) that the recovery
mechanism is a huge performance-killer, apparently locking up all
transfers to that drive for an entire second.  (At least, that's what
the code appears to be doing, and it matches well enough with the
behaviour I saw.)

I'm tempted to rip out the message entirely and decrease the wait time
drastically, probably somewhere in the 10-to-100 millisecond range, so
that it normally wakes up before the previous transfers have completely
drained.  But I am hesitant to do this without having some idea why
it's set up the way it is.  (It'd be a gross kludge anyway; the right
answer, it seems to me, would be to issue transfers as the existing
ones finish, rather than just waiting and retrying.  But it would be an
acceptable workaround in this case.)

So, what's the scoop with this?  Would rolling back to 4.0.1 help any?
It is known to run at leas tminimally on that hardware, though I
haven't stress-tested it enough to know whether it'd exhibit the same
issue.  (A quick glance at the code leads me to suspect it would.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B