Re: Incorrect response to SK/ASC/ASCQ = x 02/04/01 (becoming ready)

[Nathan Bryant <nbryant@optonline.net>]

Luben Tuikov wrote:

> If the queue is a _general_ SCSI queue on which _any_ kind of
> SCSI command can be queued to the LU/target (i.e. not necessarily
> medium access), then you must _not_ block it.  HOQ task attribute
> commands could be sent which may operate other components of the
> LU/target.

Since we know that START STOP UNIT is unreliable...

Maybe the solution, then, instead of blocking, is to do something 
similar to quiesce, wherein we block normal user-initiated medium access 
but allow special requests. (?)

Not sure what an HOQ task attribute command is. Where in the t10.org 
specs should I look for a definition of that?

> 
> But you should block the IO (R/W) general queue, yes.  _A_ way
> to do this is to send START STOP UNIT (0x1B) with the IMMED
> bit set to 0.  When the command completes, you'll get status
> and set the device to active, unblock the IO queue, etc.

How would this interact with tagged command queueing? We don't want to 
attempt to queue other commands while START STOP UNIT is pending at the 
device. We don't want to disable disconnects, either, otherwise the bus 
would be blocked while waiting for START STOP UNIT, correct?

Maybe this is a SCSI-novice question, but, does disconnection require 
tagged commands? Is the Linux midlayer smart enough to know that some 
kinds of commands need to block others until they complete?