From: "Ewan D. Milne" <emilne@redhat.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: SCSI development list <linux-scsi@vger.kernel.org>,
GeekGirl1 <my.e.mail1@verizon.net>
Subject: Re: Need help with handling failed ATA pass-through command and sense data
Date: Thu, 18 May 2017 16:01:00 -0400 [thread overview]
Message-ID: <1495137660.3629.44.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1705181322570.1619-100000@iolanthe.rowland.org>
On Thu, 2017-05-18 at 13:37 -0400, Alan Stern wrote:
>
> I had completely forgotten about this code. :-(
>
> Looks like you put your finger on the source of the problem. So if the
> device sends back essentially empty sense data (SK = No Sense, ASC =
> ASCQ = 0), but the USB transport indicates command failure, how should
> we inform the SCSI core in a way that won't cause infinite retries or
> obnoxious log messages?
>
> Should we be doing a better job of detecting empty sense data -- that
> is, do we need to check for non-empty ATA status?
>
> Or has the SCSI core improved so that it no longer does infinite
> retries (see commit f1a0743bc0e7 "USB: storage: When a device returns
> no sense data, call it a Hardware Error" and Bugzilla entry #14118),
> meaning that this code can be removed entirely?
>
> Alan Stern
We added:
commit ee60b2c52ec8ecdcbcd2f85cc117b525f649441f
Author: Eiichi Tsukata <eiichi.tsukata.xh@hitachi.com>
Date: Tue Feb 11 14:29:52 2014 +0900
[SCSI] Add timeout to avoid infinite command retry
but this may not give you the behavior you want, because it bounds
the execution time to (# of retries + 1) * timeout. So if you get
an immediate error return it could still take a while for this code
to give up retrying, i.e. it does not have the same properties as
your commit f1a0743bc0e7.
I suppose you could decode the ATA Status Return sense data descriptor
but I don't know how good the compliance is among all the ATA devices.
Table 177 in section 1.2.2.8 of SAT-4 r06 seems to say that most of
the fields in the sense data are unspecified for ATA PASS-THROUGH
commands, so this probably explains why you see nothing else useful.
Perhaps the logging should be delegated to the USB or ATA code for
these commands, since they are not really part of SCSI?
I have seen a case of a Fibre Channel array returning all zeroes
in the sense data, but this was because it was malfunctioning.
-Ewan
next prev parent reply other threads:[~2017-05-18 20:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 14:35 Need help with handling failed ATA pass-through command and sense data Alan Stern
2017-05-18 15:34 ` Ewan D. Milne
2017-05-18 16:48 ` Ewan D. Milne
2017-05-18 17:37 ` Alan Stern
2017-05-18 20:01 ` Ewan D. Milne [this message]
2017-05-23 18:34 ` Alan Stern
2017-05-24 3:13 ` mail1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1495137660.3629.44.camel@localhost.localdomain \
--to=emilne@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=my.e.mail1@verizon.net \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox