Date: Mon, 11 Mar 2002 10:50:32 +0100 From: Thomas Quinot <thomas@cuivre.fr.eu.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ATAPI/CAM boot-time hang Message-ID: <20020311105032.A32895@melusine.cuivre.fr.eu.org> In-Reply-To: <20020309161919.A59137@panzer.kdm.org>; from ken@kdm.org on Sat, Mar 09, 2002 at 04:19:19PM -0700 References: <20020309001232.A96693@melusine.cuivre.fr.eu.org> <20020309161919.A59137@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Le 2002-03-10, Kenneth D. Merry écrivait :
> That is illegal behavior (returning unit attention in response to an
> inquiry). An inquiry should only result in a check condition when the
> device can't fulfill the request. In this case, the device is sending back
> a unit attention, which has nothing to do with not being able to fulfill
> the request.
Plus, the ATAPI generic code immediately issues a REQUEST SENSE in such
a situation, which should clear the UA in any case.
> The reason we set the SF_RETRY_UA flag is because unit attentions are
> expected conditions, and will be cleared as soon as they are reported.
OK.
> They aren't cleared by an inquiry, but then they aren't supposed to be
> reported in response to an inquiry.
Agreed.
> It's possible in -current that we might actually decrement the count for a
> unit attention, depending on what ASC/ASCQ are returned.
We get 0x2e/0x00, which is unassigned in SPC, and assigned to
'INSUFFICIENT TIME FOR OPERATION' in SPC-2 and higher. This ASC/ASCQ is
specific to CD-ROM class devices, and in any case should be returned
only with a CHECK CONDITION sense key.
> > 1. consider that the device's behaviour is abnormal (ATAPI does
> > always perform autosense, so UNIT ATTENTION should be cleared
> > on the 2nd attempt) and create quirk entries for it;
From what I infer from the above it is likely that we need to introduce
these new quirk entries (CAM_QUIRK_NOFULLINQUIRY?) (or maybe
CAM_NEW_TRAN_CODE provides another way of working around such issues --
I have yet to have a closer look at it).
> > 2. decrement the retry count when receiving UNIT ATTENTION (but in
> > that case, the probe machinery should not consider failure of
> > full inquiry as an indication that the device has disappeared);
Since UA is supposed to be a transient condition, couldn't we clear
SF_RETRY_UA the first time we do a retry, so as to ensure that a
command which yields a (bogus) UA at every retry finally fails?
> > 3. get rid of the full inquiry altogether (anything besides
> > SHORT_INQUIRY_LENGTH is vendor-specific anyway -- do we actually
> > use it?)
> Take a look at the scsi_inquiry_data structure in scsi_all.h. There
> are fields used to indicate the ability to do QAS, DT clocking, etc. At
> least the DT clocking bit is used in the transport layer, and the ses(4)
> driver needs some of the extended data as well.
Ah, yes, I see the SPI stuff there in SPC2 (in what were reserved bits
in SPC), so the answer to my question above is 'yes we do use actually
use it'.
> Well, it would help to find out what ASC/ASCQ are actually getting returned
> from the device. We know what the sense key is, but it would be useful to
> find out what ASC/ASCQ are reported.
atapi_interrupt: result = 0x60
... cmd was 0x12, now doing autosense
-> here the ATAPI layer reports an UA (the high-order nibble of result
is a sense key) in response to our INQUIRY, and the atapi_interrupt
routine automatically schedules a REQUEST SENSE
atapi_interrupt: result = 0x60
-> here the unit has replied to the internally-generated REQUEST SENSE...
atapi_cb: hcb@0xc1edac40 status = 60: (sk = 06)
atapicam1s: cmd 03 - sk=06 asc=2e ascq=00
-> ... the xpt callback gets back control, and we see that we have
a sense key of 6 UNIT ATTENTION, and an ASC/ASCQ of 2e/00
INSUFFICIENT TIME FOR OPERATION. Bogus.
Thomas.
--
Thomas.Quinot@Cuivre.FR.EU.ORG
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020311105032.A32895>