From owner-freebsd-scsi Tue Mar 7 3: 7:58 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5]) by hub.freebsd.org (Postfix) with ESMTP id B1D4D37BB4D; Tue, 7 Mar 2000 03:07:06 -0800 (PST) (envelope-from n_hibma@calcaphon.com) Received: from henny.webweaving.org (dhcp36.calcaphon.com [10.0.1.36]) by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id LAA04856; Tue, 7 Mar 2000 11:05:28 GMT (envelope-from n_hibma@calcaphon.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id KAA01073; Tue, 7 Mar 2000 10:53:12 GMT (envelope-from n_hibma@calcaphon.com) Date: Tue, 7 Mar 2000 10:53:12 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: "Kenneth D. Merry" Cc: Mike Smith , mjacob@feral.com, FreeBSD SCSI Mailing List , BLACKSON Jim Subject: Re: first INQUIRY goes round in circles (fwd) In-Reply-To: <20000306203217.A80256@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What I don't understand is why the drive does not clear the Unit Attention after REQUEST SENSE has been sent. The solution to all this Jim pointed out was to not request sense after INQUIRY. This I can live with as it is a valid solution. If INQUIRY fails, the data stage of the USB transfer will fail and you have another indicator that things went wrong. Thanks for the help. Nick > > After having another look at what CAM does, the following strikes me as > > odd. In the case of SF_RETRY_UA being set, the command is retried > > _without_ decrementing the retry_count. Can anyone enlighten me as to > > why that is being done this way? > > > > It's the cause of the infinite retry of the initial INQUIRY command. > > A unit attenion is not supposed to be returned in response to an inquiry. > But your drive is returning a unit attention error. Here's the relevant > section from the SCSI-2 spec: > > ======================================================================== > The INQUIRY command shall return CHECK CONDITION status only when the > target cannot return the requested INQUIRY data. > > NOTE 64 The INQUIRY data should be returned even though the peripheral > device may not be ready for other commands. > > If an INQUIRY command is received from an initiator with a pending unit > attention condition (i.e. before the target reports CHECK CONDITION > status), the target shall perform the INQUIRY command and shall not > clear the unit attention condition (see 7.9). > ======================================================================== > > So there are two components: > > - the target should *only* return an error if it cannot return the > inquiry data. > > - any unit attention condition should not be cleared by an inquiry [*] > > But any other command should generate the check condition which would then > clear the unit attention state. > > So in most cases, a unit attention will be cleared after the first command, > so the "infinite" number of retries only ends up being 1. > > You're running into this problem because you've got a broken driver that > reports an error in response to an inquiry. > > [*] Unit attention handling is actually a little more complicated than I've > described, due to contingent allegiance conditions. Don't ask me to > explain that, since I don't have a good understanding of it. :) It's > explained in the SCSI specs. -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message