James Bottomley mailto:[EMAIL PROTECTED] sez:
On Tue, 2007-06-19 at 11:41 -0400, Salyzyn, Mark wrote:
It was discovered that if we had a busy status return
from the Adapter for the SCSI srb command to a physical
component, that we returned DID_NO_CONNECT rather than
what one would expect DID_BUS_BUSY.
Are you sure you want DID_BUS_BUSY? I'm just asking because
I'm not sure of the firmware ramifications. DID_BUS_BUSY
will turn the command around for an immediate retry.
If there's a firmware resource issue, you should return
something like DID_REQUEUE which will throttle the
queue and reissue this command when another one returns.
Thanks for noting this. I believe that this is the behavior we want.
This is related to a SCSI pass-through to the physical targets. I see no
dummied-up returns of SRB_STATUS_BUSY from the top all the way down to
the CHIM. This is a report from the physical bus or end device and thus
does not represent an Adapter resource limit. Immediate re-queuing is
indicated.
I noticed this issue when we were talking internally about mitigating
the sequential queuing of commands to SATA ATAPI devices at the CHIM
level. A long command (erase CD for example) issued by an application
was followed by a test unit ready with a short timeout issued by the
Linux device class layer for media checking and we ended up timing out
the test unit ready. I had suggested, in violation of the sat
specification, to return the test unit ready with SRB_STATUS_BUSY when
timed out prior to even making it to the physical transport while
sitting in the sequential queue. Thus I noticed the shortcoming in the
driver regarding the recent ( 2.6.10) addition of this return value.
The CHIM folks balked at a spoofed SRB_STATUS_BUSY response. Even though
the workaround was not accepted, this scenario would still be acceptable
for immediate re-queuing.
Sincerely -- Mark Salyzyn
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
