From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ewan D. Milne" Subject: Re: Need help with handling failed ATA pass-through command and sense data Date: Thu, 18 May 2017 16:01:00 -0400 Message-ID: <1495137660.3629.44.camel@localhost.localdomain> References: Reply-To: emilne@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41026 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753845AbdERUBB (ORCPT ); Thu, 18 May 2017 16:01:01 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Alan Stern Cc: SCSI development list , GeekGirl1 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 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