Re: Question about Request Sense case in scsi_lib.c

[Douglas Gilbert <dougg@torque.net>]

James Bottomley wrote:
> On Tue, 2004-10-12 at 11:59, Dave Olien wrote:
> 
>>Thanks for the feedback.  Yes, Automatic volume transfer is on, and I
>>was expecting there'd be poor performance as a result.  I just
>>didn't expect to get IO errors.  The odd thing is that the "bus reset"
>>leads to the SCSI request being requeued.  But every once in a while,
>>the requeue fails with errors and the request is failed.  I'll look at
>>these cases a little more closely, try to understand why the requeues fail.
> 
> 
> Hang on a minute ... if you're ping pong'ing the drives using AVT, those
> transfers take time to achieve.  The device is probably returning UNIT
> ATTENTION, NOT_READY while the transfer is in progress.  This is
> probably the source of the requeue.

UNIT ATTENTION and NOT READY are both sense keys so a
device can't yield both on one command. However you may be
on the right track as there is an ever increasing number of
reasons a device could issue a UNIT ATTENTION. [See SPC-3
rev 21 and I believe these ASC codes (and all their associated
ASCQ codes) occur with a sense key of UNIT ATTENTION:
0x28, 0x29, 0x2a, 0x3f, 0x5b/0x1 and 0x5d.]

Unlikely in this case but a sense key of UNIT ATTENTION
(or perhaps RECOVERED ERROR)  with an additional sense
of "Hardware impending failure, seek error rate too high"
may slip by without even a log entry.

> As for the error, I still don't understand that, but it looks like
> something went wrong in setting up or tearing down the dma mapping, so
> that it was incorrectly described when this happened a second time.

I hope to address the code in the scsi_io_completion() error/warning
processing paths with the descriptor_sense cleanup. There seems to
be a missing scsi_print_sense() call on the UNIT ATTENTION path.

Dave, does your log show a bus error (ASC/ASCQ=0x29/0x2) has occurred?

Doug Gilbert