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

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

[Alan Stern]

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.

Instead what happens is that all the retries get exhausted in a fraction 
of a second, which isn't long enough for any device to spin up.  The 
drivers then proceed blindly with whatever else they want to do, which 
generally incurs its own set of errors.

This problem seems to be particularly bad for USB DVD drives.  One user
was able to work around it by manually loading the usb-storage driver 20
to 30 seconds after plugging the drive into the computer.  Obviously it
would be much better to have the system do the right thing in the first
place.

I don't know enough about the SCSI core to change it properly.  Can
someone please help?

Alan Stern

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

[Nathan Bryant]

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.
>  
>
I agree that this needs to be fixed in the error handler proper. I'm 
currently working around this  kind of problem in my scsi suspend/resume 
patch by inserting explicit spinup calls on resume. It would be much 
better to not have to do so; I don't think it's possible to implement 
auto spindown/spinup without the error handler doing it for us.

>Instead what happens is that all the retries get exhausted in a fraction 
>of a second, which isn't long enough for any device to spin up.  The 
>drivers then proceed blindly with whatever else they want to do, which 
>generally incurs its own set of errors.
>
>This problem seems to be particularly bad for USB DVD drives.  One user
>was able to work around it by manually loading the usb-storage driver 20
>to 30 seconds after plugging the drive into the computer.  Obviously it
>would be much better to have the system do the right thing in the first
>place.
>  
>
It's probably also going to bite SATA drives. People are going to want 
SATA drives to have the same power-management features that IDE has, 
including standby timers and the associated ioctl's... sooner or later 
I'll bet laptops will end up with SATA.

>I don't know enough about the SCSI core to change it properly.  Can
>someone please help?
>
>Alan Stern
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

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

[James Bottomley]

On Sun, 2004-08-22 at 12:21, 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.
> 
> Instead what happens is that all the retries get exhausted in a fraction 
> of a second, which isn't long enough for any device to spin up.  The 
> drivers then proceed blindly with whatever else they want to do, which 
> generally incurs its own set of errors.

Well, that all depends on what's causing this.

You're correct in that the mid-layer assumes an operational device won't
spontaneously spin down, so it does interpret this sense as indicating a
transient error....In fact, most often it's the sense returned by disc
arrays after a bus or device reset, which is the case the code is
designed to handle.

If the spin down is caused by user intervention (actually sending a spin
down command followed by a spin up) then I'd say the user needs to
ensure the device has fully spun up before using it.

What other conditions produce something like this?

> This problem seems to be particularly bad for USB DVD drives.  One user
> was able to work around it by manually loading the usb-storage driver 20
> to 30 seconds after plugging the drive into the computer.  Obviously it
> would be much better to have the system do the right thing in the first
> place.

Hmm, well, the sr code does contain a loop (in get_capabilites()) for
waiting for the device to become ready, but it obviously simply sends
the command five times and then gives up.  Perhaps adding logic here to
wait much longer might fix the DVD problem?

James

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

[Burn Alting]

On Mon, 2004-08-23 at 09:32, James Bottomley wrote:
> On Sun, 2004-08-22 at 12:21, 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.
> > 
> > Instead what happens is that all the retries get exhausted in a fraction 
> > of a second, which isn't long enough for any device to spin up.  The 
> > drivers then proceed blindly with whatever else they want to do, which 
> > generally incurs its own set of errors.
> 
> Well, that all depends on what's causing this.
> 
> You're correct in that the mid-layer assumes an operational device won't
> spontaneously spin down, so it does interpret this sense as indicating a
> transient error....In fact, most often it's the sense returned by disc
> arrays after a bus or device reset, which is the case the code is
> designed to handle.
> 
> If the spin down is caused by user intervention (actually sending a spin
> down command followed by a spin up) then I'd say the user needs to
> ensure the device has fully spun up before using it.
> 
> What other conditions produce something like this?

How about when disk arrays are booting? Typically, a disk array will
quickly present target(s) to the host and then take some time to
initialise before being ready for medium access. I assume most disk
arrays will present the above sense condition (becoming ready) to all
medium access commands until it is ready for medium access.

It appears that devices are getting more specific about what they return
in their request sense data (ie sense key but more importantly the ASC/Q
fields) so perhaps a generic scsi of routines are needed which perform
some sort of analysis of the returned sense data and with the knowledge
of the command sent, perform more informed actions. For example, in the
above case, if we see a 'Becoming ready' ASC/Q we may retry the command
N times with X or fn(X) timeouts between each retry before aborting the
command or taking whatever action is required when the command can't
complete.

> 
> > This problem seems to be particularly bad for USB DVD drives.  One user
> > was able to work around it by manually loading the usb-storage driver 20
> > to 30 seconds after plugging the drive into the computer.  Obviously it
> > would be much better to have the system do the right thing in the first
> > place.
> 
> Hmm, well, the sr code does contain a loop (in get_capabilites()) for
> waiting for the device to become ready, but it obviously simply sends
> the command five times and then gives up.  Perhaps adding logic here to
> wait much longer might fix the DVD problem?
> 
> James
> 
> 
> -

Burn

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

[James Bottomley]

On Sun, 2004-08-22 at 19:56, Burn Alting wrote:
> How about when disk arrays are booting? Typically, a disk array will
> quickly present target(s) to the host and then take some time to
> initialise before being ready for medium access. I assume most disk
> arrays will present the above sense condition (becoming ready) to all
> medium access commands until it is ready for medium access.

If you power off a disc and power it on again, the same thing happens.

I'd like to distinguish between normal occurrences at start of day which
we need to handle (like spinning up devices or waiting for them to
become ready from power on).  And normal occurrences during device
operation.  The former are handled in the ULD and the latter in the
mid-layer error handler.

It's certainly possible to rejig the mid-layer to add an extra delay via
schedule_delayed_work(), but I'd like to be sure its necessary first,
since the addition looks to be slightly messy.

James

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

[Burn Alting]

On Tue, 2004-08-24 at 01:31, James Bottomley wrote:
> On Sun, 2004-08-22 at 19:56, Burn Alting wrote:
> > How about when disk arrays are booting? Typically, a disk array will
> > quickly present target(s) to the host and then take some time to
> > initialise before being ready for medium access. I assume most disk
> > arrays will present the above sense condition (becoming ready) to all
> > medium access commands until it is ready for medium access.
> 
> If you power off a disc and power it on again, the same thing happens.
> 
> I'd like to distinguish between normal occurrences at start of day which
> we need to handle (like spinning up devices or waiting for them to
> become ready from power on).  And normal occurrences during device
> operation.  The former are handled in the ULD and the latter in the
> mid-layer error handler.
> 
> It's certainly possible to rejig the mid-layer to add an extra delay via
> schedule_delayed_work(), but I'd like to be sure its necessary first,
> since the addition looks to be slightly messy.

Good point. I'm just concerned that over time, devices are going to be
more specific about the errors they generate at "run-time" (as opposed
to boot/power-on stage) - the ASC/Q table in the scsi standard is
growing rapidly.

I don't think we can get around this and eventually complex error
recovery code (which is messy by nature) is going to be needed. Perhaps
we should get an early start by making the error recovery code as
generic as possible now.

> 
> James
> 

Burn

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

[Jeremy Higdon]

On Mon, Aug 23, 2004 at 11:31:57AM -0400, James Bottomley wrote:
> On Sun, 2004-08-22 at 19:56, Burn Alting wrote:
> > How about when disk arrays are booting? Typically, a disk array will
> > quickly present target(s) to the host and then take some time to
> > initialise before being ready for medium access. I assume most disk
> > arrays will present the above sense condition (becoming ready) to all
> > medium access commands until it is ready for medium access.
> 
> If you power off a disc and power it on again, the same thing happens.
> 
> I'd like to distinguish between normal occurrences at start of day which
> we need to handle (like spinning up devices or waiting for them to
> become ready from power on).  And normal occurrences during device
> operation.  The former are handled in the ULD and the latter in the
> mid-layer error handler.
> 
> It's certainly possible to rejig the mid-layer to add an extra delay via
> schedule_delayed_work(), but I'd like to be sure its necessary first,
> since the addition looks to be slightly messy.
> 
> James


I believe that 02/04/01 should be treated like a Busy status.  The
semantics are slightly different, but the action taken by the
initiator is the same: wait a bit and then retry.

I have seen this key/asc/asq before and had to handle it that way.
I believe the device in question was a disk drive that had been
powered on recently.  Disks set to have a variable spinup delay
(based on ID, so that not all disks in a 16-drive box power up at
the same time and overstress a power supply) can return this code
up to a couple of minutes after power on.

jeremy

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

[James Bottomley]

On Wed, 2004-08-25 at 22:54, Jeremy Higdon wrote:
> I believe that 02/04/01 should be treated like a Busy status.  The
> semantics are slightly different, but the action taken by the
> initiator is the same: wait a bit and then retry.

Well, that's dangerous.  BUSY is assumed always to be a transient
condition, so it doesn't count against the retries, so if this thing
never comes back, we'd loop forever there.

The other thing about BUSY handling is that, for a device with no
outstanding commands like this, we retry based on I/O pressure, so even
if I increment the retry count time waited would depend on how much I/O
pressure the system had.

> I have seen this key/asc/asq before and had to handle it that way.
> I believe the device in question was a disk drive that had been
> powered on recently.  Disks set to have a variable spinup delay
> (based on ID, so that not all disks in a 16-drive box power up at
> the same time and overstress a power supply) can return this code
> up to a couple of minutes after power on.

But that's a start of day thing, which would be handled by sd's TUR
code.

James

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

[Jeremy Higdon]

On Thu, Aug 26, 2004 at 11:38:08AM -0400, James Bottomley wrote:
> On Wed, 2004-08-25 at 22:54, Jeremy Higdon wrote:
> > I believe that 02/04/01 should be treated like a Busy status.  The
> > semantics are slightly different, but the action taken by the
> > initiator is the same: wait a bit and then retry.
> 
> Well, that's dangerous.  BUSY is assumed always to be a transient
> condition, so it doesn't count against the retries, so if this thing
> never comes back, we'd loop forever there.

Hmm.  I think an exponential backoff would be better.

In any case, the 02/04/01 is also a transient condition.  It means
that the device is in the process of becoming read, but is not ready yet.

> The other thing about BUSY handling is that, for a device with no
> outstanding commands like this, we retry based on I/O pressure, so even
> if I increment the retry count time waited would depend on how much I/O
> pressure the system had.

The amount of time you wait to retry is based on I/O pressure?
The amount of time that it will take before the device is ready is
not based on I/O pressure.

> > I have seen this key/asc/asq before and had to handle it that way.
> > I believe the device in question was a disk drive that had been
> > powered on recently.  Disks set to have a variable spinup delay
> > (based on ID, so that not all disks in a 16-drive box power up at
> > the same time and overstress a power supply) can return this code
> > up to a couple of minutes after power on.
> 
> But that's a start of day thing, which would be handled by sd's TUR
> code.

True.  However, in the future, I might expect to see more of this
behavior, as drives are spun down for power conservation.  Probably
more on small systems than on big ones.

jeremy

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

[Douglas Gilbert]

Jeremy Higdon wrote:
> On Thu, Aug 26, 2004 at 11:38:08AM -0400, James Bottomley wrote:
> 
>>On Wed, 2004-08-25 at 22:54, Jeremy Higdon wrote:
>>
>>>I believe that 02/04/01 should be treated like a Busy status.  The
>>>semantics are slightly different, but the action taken by the
>>>initiator is the same: wait a bit and then retry.
>>
>>Well, that's dangerous.  BUSY is assumed always to be a transient
>>condition, so it doesn't count against the retries, so if this thing
>>never comes back, we'd loop forever there.
> 
> 
> Hmm.  I think an exponential backoff would be better.
> 
> In any case, the 02/04/01 is also a transient condition.  It means
> that the device is in the process of becoming read, but is not ready yet.
> 
> 
>>The other thing about BUSY handling is that, for a device with no
>>outstanding commands like this, we retry based on I/O pressure, so even
>>if I increment the retry count time waited would depend on how much I/O
>>pressure the system had.
> 
> 
> The amount of time you wait to retry is based on I/O pressure?
> The amount of time that it will take before the device is ready is
> not based on I/O pressure.
> 
> 
>>>I have seen this key/asc/asq before and had to handle it that way.
>>>I believe the device in question was a disk drive that had been
>>>powered on recently.  Disks set to have a variable spinup delay
>>>(based on ID, so that not all disks in a 16-drive box power up at
>>>the same time and overstress a power supply) can return this code
>>>up to a couple of minutes after power on.
>>
>>But that's a start of day thing, which would be handled by sd's TUR
>>code.
> 
> 
> True.  However, in the future, I might expect to see more of this
> behavior, as drives are spun down for power conservation.  Probably
> more on small systems than on big ones.

Jeremy,
I have read that SAS disks will need spinning up. Also SATA
disks in a SAS domain will be held somewhere in their
initialization state machine so they don't spin up either.
It both cases active intervention from an application server
(e.g. linux scsi subsystem) will be required.

New infrastructure supporting a "power condition" state machine
has been added recently to SPC-3 and SBC-2. For disks I think
this is an attempt to merge the way SATA and SAS disks (and
perhaps recent u320 disks) will work in this area. There is
a new Power Condition mode page. See SPC-3 section 5.9 and
SBC-2 section 4.14 .

Doug Gilbert

Re: PATCH: (as355) Fix test for valid sense data present

[Alan Stern]

James:

Allow me to call your attention to this submitted patch:

http://marc.theaimsgroup.com/?l=linux-scsi&m=109156117217822&w=2

It hasn't been applied anywhere that I've looked.  Is there any problem 
with it?

Alan Stern

Re: PATCH: (as355) Fix test for valid sense data present

[James Bottomley]

On Thu, 2004-08-26 at 11:55, Alan Stern wrote:
> It hasn't been applied anywhere that I've looked.  Is there any problem 
> with it?

Well, it doesn't look quite right.

You haven't modified the SCSI_SENSE_VALID() macro, so DRIVER_SENSE
doesn't get set for the extra conditions you're checking for.

Even if you do fix it, You'll cause us to treat deferred sense
conditions as errors, which would be wrong.

What's the actual problem you're trying to fix?

James

Re: PATCH: (as355) Fix test for valid sense data present

[Alan Stern]

On 26 Aug 2004, James Bottomley wrote:

> Well, it doesn't look quite right.
> 
> You haven't modified the SCSI_SENSE_VALID() macro, so DRIVER_SENSE
> doesn't get set for the extra conditions you're checking for.

I admit that all the ramifications aren't clear to me.  However, the
SCSI_SENSE_VALID macro already masks with 0x70.  The places the patch
changed were masking with 0x7f.  How come two different masks are being 
used in various places?

> Even if you do fix it, You'll cause us to treat deferred sense
> conditions as errors, which would be wrong.
> 
> What's the actual problem you're trying to fix?

No problems have come up in actual use.  I wrote the patch in response to 
the message below, from Douglas Gilbert (this was part of an interchange 
commenting on some proposed additions to the 
Documentation/scsi/scsi_mid_low_api.txt document -- see the section 
about Autosense).  Was he incorrect?

Alan Stern


-------------------------------------------------------------------------

> This looks quite good.  Only a few things struck me:
> 
> 	The test given for valid data in the sense_buffer isn't correct.
> 	The actual test used is ((cmd->sense_buffer[0] & 0x7f) == 0x70).
> 	This is mentioned in a couple of places in the document.

If that comparison is in linux code then the comparison
is wrong! The comparison that is correct is bits 4, 5 and 6
all being set. So we don't care about bit 7 and the bottom
two bits can be 0x0, 0x1, 0x2 or 0x3. The fact that linux
can't handle sense buffer "descriptor" format is an issue
that needs to be addressed soon (but is unlikely to be an
issue for usb-storage devices for some time).

Re: PATCH: (as355) Fix test for valid sense data present

[James Bottomley]

On Thu, 2004-08-26 at 12:59, Alan Stern wrote:
> No problems have come up in actual use.  I wrote the patch in response to 
> the message below, from Douglas Gilbert (this was part of an interchange 
> commenting on some proposed additions to the 
> Documentation/scsi/scsi_mid_low_api.txt document -- see the section 
> about Autosense).  Was he incorrect?

I suspect that's because you've never seen any of the new types in
practice.

0x70 is really the only sense type we process correctly: Fixed Format. 
0x72 is the newer Descriptor Format.  0x71 and 0x73 are the Fixed and
Descriptor format deferred sense conditions.

We really only get deferred errors if the device has a cache that is set
to writeback, so we just hope never to see them...

I thought Doug had a proposal for unifying our view of Fixed vs
Descriptor sense formats?

James

Re: PATCH: (as355) Fix test for valid sense data present

[Alan Stern]

Regarding the question of whether to test for valid sense data by masking 
sense_buffer[0] against 0x70 or 0x7f (some places do it one way, some 
places do it the other):


On 26 Aug 2004, James Bottomley wrote:

> On Thu, 2004-08-26 at 12:59, Alan Stern wrote:
> > No problems have come up in actual use.  I wrote the patch in response to 
> > the message below, from Douglas Gilbert (this was part of an interchange 
> > commenting on some proposed additions to the 
> > Documentation/scsi/scsi_mid_low_api.txt document -- see the section 
> > about Autosense).  Was he incorrect?
> 
> I suspect that's because you've never seen any of the new types in
> practice.
> 
> 0x70 is really the only sense type we process correctly: Fixed Format. 
> 0x72 is the newer Descriptor Format.  0x71 and 0x73 are the Fixed and
> Descriptor format deferred sense conditions.
> 
> We really only get deferred errors if the device has a cache that is set
> to writeback, so we just hope never to see them...
> 
> I thought Doug had a proposal for unifying our view of Fixed vs
> Descriptor sense formats?

I have no idea.  My only intention was to bring the matter to the
attention of people who understand the issues better than I do.  Maybe
Doug can comment on this.

Alan Stern

Re: PATCH: (as355) Fix test for valid sense data present

[Douglas Gilbert]

James Bottomley wrote:
> On Thu, 2004-08-26 at 12:59, Alan Stern wrote:
> 
>>No problems have come up in actual use.  I wrote the patch in response to 
>>the message below, from Douglas Gilbert (this was part of an interchange 
>>commenting on some proposed additions to the 
>>Documentation/scsi/scsi_mid_low_api.txt document -- see the section 
>>about Autosense).  Was he incorrect?
> 
> 
> I suspect that's because you've never seen any of the new types in
> practice.
> 
> 0x70 is really the only sense type we process correctly: Fixed Format. 
> 0x72 is the newer Descriptor Format.  0x71 and 0x73 are the Fixed and
> Descriptor format deferred sense conditions.
> 
> We really only get deferred errors if the device has a cache that is set
> to writeback, so we just hope never to see them...
> 
> I thought Doug had a proposal for unifying our view of Fixed vs
> Descriptor sense formats?

James,
Yes. I'll present it as a patch shortly.

With respect to deferred errors, we should not just ignore
them. At the very least they should be logged.

Doug Gilbert

Proposal for fixing READ_CAPACITY

[Alan Stern]

James:

A number of USB mass storage devices return the wrong value for READ 
CAPACITY -- that is, they report the total number of blocks rather than 
the highest available block number.  As a result the kernel thinks they 
have one more block than they really do.

This didn't cause too much trouble under 2.4, but now distributions are
shipping kernels with support for partitioning schemes or filesystem
layouts that store important information in the last block.  Obviously
this is a recipe for trouble.

For some time there has been a routine in the usb-storage driver to reduce 
by one the value returned by READ CAPACITY (if the device has a
corresponding blacklist flag set).  That's not a good place for a couple 
of reasons:

	Doing it in the low-level driver prevents any program from
	seeing what the device actually does report.

	It's not a transport issue in the first place, so it shouldn't
	be handled by the transport driver.

On the whole, it would be much better (and simpler!) to correct these
mistakes in sd.c's sd_read_capacity() routine.  (I haven't encountered any 
CD-type devices that make this mistake.)  One obvious approach is to
use another SCSI blacklist flag for devices needing this fixup.  A
trickier but possibly better approach is to automatically try reading the
last block when the device is probed, and reduce the capacity by 1 if the 
read fails.

The advantage is that nobody has to maintain any blacklist entries.  The 
disadvantage is that this involves deliberately asking the device to do 
something which may cause a nasty error.  Some USB devices go into a very 
confused state when asked to read past the end of the medium.  A bus reset 
might set them straight again -- or it might not; I haven't ever tried it.

Anyway, what's your reaction to all this?  Should the workaround be moved 
from usb-storage to sd?  If yes, which approach should be used?

Alan Stern

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

[Luben Tuikov]

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.

		Luben

> Instead what happens is that all the retries get exhausted in a fraction
> of a second, which isn't long enough for any device to spin up.  The
> drivers then proceed blindly with whatever else they want to do, which
> generally incurs its own set of errors.
> 
> This problem seems to be particularly bad for USB DVD drives.  One user
> was able to work around it by manually loading the usb-storage driver 20
> to 30 seconds after plugging the drive into the computer.  Obviously it
> would be much better to have the system do the right thing in the first
> place.
> 
> I don't know enough about the SCSI core to change it properly.  Can
> someone please help?
> 
> Alan Stern
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Nathan Bryant]

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?

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

[Luben Tuikov]

> 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. (?)

Yes, something like that.

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

"Head Of Queue", cf., E.g. SAM-3r13, section 8.
 
> 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?

What would happen when you have SSU with IMMED=0 pending at the device
server and you send another task with say SIMPLE task attribute? ;-)
 
> 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?

Not sure I completely understand the questions, but I don't think
SCSI Core keeps an image of the deivice server's queues.  It may
keep a state (send/don't send) given recently sent commands, but
not as delicatly as a device server.

		Luben

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

[Brian King]

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

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

[Pat LaVarre]

 > > > the mid-layer assumes an operational device
 > > > won't spontaneously spin down,
 > ...
 > What other conditions produce something like this?

Spontaneous park and then spontaneous spin down occur with some devices 
if the host neglects to read or write thru the cache from the disc for 
a long time, like whole seconds.

This policy reduces noise, power, and media wear.  Guarantees a gentle 
park.  Etc.  Same device design rationale as ATA HDD power management.  
Not disputed in the device world, I hear.

 > 02/04/01 = Not Ready, ...
 > becoming ready.
 > ...
 > retries ... exhausted in ... a second, ...

I vote we distinguish:

a) the spin-up implied by insert or power on,
b) the spin down implied by eject, and
c) other spin up and spin down.

 > work around ... by [modprobe] after plugging the drive in...

Our host should not rapidly retry and give up on any of these, sure.

 > disable disconnects ...
 > the bus would be blocked
 > while waiting for START STOP UNIT ...

SCSI over USB disables disconnects always, I know.

I hear SCSI over IDE in practice disables disconnects almost always, 
though t13.org publishes a theory of more capable devices.

 > > 02/04/01 should be treated like a Busy status.
 > ...
 > a) the spin-up implied by insert or power on,

Many devices use x 2 04 01 to mean a spin-up implied by insert or power 
on.

I hear x 2 04 01 had a pre-Windows history of meaning please rapidly 
retry, but Windows support was so poor - including rapidly counted 
retries - that those other uses of x 2 04 01 have migrate out of PC 
peripheral device designs.

 > b) the spin down implied by eject, and

Many PDT x00 devices use x 2 04 00 to mean the spin down implied by 
eject, many PDT x05 devices use x 2 3A.

 > > > the mid-layer assumes an operational device
 > > > won't spontaneously spin down,
 > > ...
 > > the 02/04/02 handling code
 > ...
 > c) other spin up and spin down.

I see x 0 and x 2 04 00 and x 2 04 02 reported to mean a spontaneous 
spin down.  I hear x 0 works well in Windows only if the auto spin up 
completes in a few seconds.

Pat LaVarre

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

[Pat LaVarre]

P.S.

> > > 02/04/01 should be treated like a Busy status.
> > ...
> > a) the spin-up implied by insert or power on,
>
> Many devices use x 2 04 01 to mean a spin-up implied by insert or 
> power on.
>
> I hear x 2 04 01 had a pre-Windows history of meaning please rapidly 
> retry, but Windows support was so poor - including rapidly counted 
> retries - that those other uses of x 2 04 01 have migrate out of PC 
> peripheral device designs.

I should also mention a practice I remember seeing and deprecating.

I've seen devices use x 2 04 01 to mean the host rudely sent a second 
command while a device with no command queue was still completing an 
"immediate" command or a disconnected command.  That's x 2 04 01 
meaning "busy" in the sense of resource conflict: hello, the heads are 
busy elsewhere, hello, there is only one arm.

Me, I argue that the host half of x 2 04 01 is such an ad hoc mess 
across platforms that any PC peripheral device should instead choose to 
delay its response to such a command.  Wait for the conflicting command 
to complete, only then begin the new command, and let the host worry 
about the worst case of the second command taking as long to complete 
as two commands in sequence.

Pat LaVarre