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

[Brian King <brking@us.ibm.com>]

Luben Tuikov wrote:
> Alan Stern wrote:
> 
>> The SCSI core doesn't react properly when it receives SK/ASC/ASCQ = x
>> 02/04/01 = Not Ready, Logical unit in process of becoming ready.
>>
>> The core is complex enough that I can't tell exactly what's wrong or how
>> it should be fixed.  That particular sense data combination is spotted in
>> two different places: scsi_lib.c:scsi_io_completion() and
>> scsi_error.c:scsi_check_sense().  It's not clear which one is causing the
>> problem -- maybe they both are.
>>
>> Anyway, the reaction in both routines is to requeue the request for
>> immediate retry.  Obviously that's the wrong thing to do.  The request
>> should be retried, yes, but only after a delay of, say, a second or 
>> so. (Presumably the queue should remain blocked during that time.)  
>> And this
>> should keep happening for up to maybe 30 seconds.
> 
> 
> 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.
> 
> 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.

Is there any way you can reuse the 02/04/02 handling code in 
scsi_error.c? It could probably be generalized a bit to handle both.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center