Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Mar 2002 16:19:19 -0700
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        Thomas Quinot <thomas@cuivre.fr.eu.org>
Cc:        freebsd-scsi@FreeBSD.ORG
Subject:   Re: ATAPI/CAM boot-time hang
Message-ID:  <20020309161919.A59137@panzer.kdm.org>
In-Reply-To: <20020309001232.A96693@melusine.cuivre.fr.eu.org>; from thomas@cuivre.fr.eu.org on Sat, Mar 09, 2002 at 12:12:32AM %2B0100
References:  <20020309001232.A96693@melusine.cuivre.fr.eu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, Mar 09, 2002 at 00:12:32 +0100, Thomas Quinot wrote:
> Some users of the ATAPI/CAM patches (available from
> http://www.cuivre.fr.eu.org/~thomas/atapicam/) have let me know that
> using the patch would hang their machine at boot time.
> 
> >From first investigation, it was determined that there was a problem
> with the inquiry commands that are performed during the CAM probe,
> and that disabling the PROBE_FULL_INQUIRY phase altogether resolved
> the problem for these users.
> 
> Analysis of debug traces from the ATAPI/CAM code seems to indicate
> that, for these users, one of the ATAPI devices always responds
> with a UNIT ATTENTION condition to the 'full' INQUIRY CDB. In that
> case, the retry_count for the ccb is never decremented (per the
> following code in scsi_interpret_sense:
>                 case SSD_KEY_UNIT_ATTENTION:
> [...]
>                         if ((sense_flags & SF_RETRY_UA) != 0) {
>                                 /* don't decrement retry count */
>                                 error = ERESTART;
>                                 print_sense = FALSE;
> and so the kernel loops forever trying to send INQUIRY commands.

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.

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.
They aren't cleared by an inquiry, but then they aren't supposed to be
reported in response to an inquiry.

It's possible in -current that we might actually decrement the count for a
unit attention, depending on what ASC/ASCQ are returned.

> There are now several options to address this issue:
>   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;
>   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);
>   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.

>   4. other solution?
> 
> I'd like others' opinion on this problem...

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.

In -current, bootverbose (-v) should be sufficient to show the information.
In -stable, change the 'print_sense = FALSE;' to 'print_sense = TRUE;' in
the if statement you quoted above.

Ken
-- 
Kenneth Merry
ken@kdm.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?20020309161919.A59137>