From owner-freebsd-scsi Tue Jul 6 17:29:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id D111514F55 for ; Tue, 6 Jul 1999 17:29:09 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id SAA01024; Tue, 6 Jul 1999 18:29:10 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907070029.SAA01024@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Hibma Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset In-reply-to: Your message of "Tue, 06 Jul 1999 19:48:32 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 18:29:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Reset does not only occur after a bus reset but more often, after phase >errors and other transient errors that might occur on the drive. So I >need to have a proper mechanism after a reset after an error. Sure. >> All ccbs that have an error status set should cause the device >> queue to be frozen and the CAM_DEV_QFRZN flag should be set in >> the cam status field of the CCB. If you don't freeze the queue, >> the peripheral driver cannot perform error recovery in a consistant >> way. > >umass uses one tagged opening. This matters little. The peripheral driver still expects that when an error occurs the queue will be frozen (unless the devices sets the queue freeze disable bit, but this is handled by the XPT for you). If you don't freeze the queue, the order in which the transaction is re-queued or the queue is frozen for error recovery by the peripheral driver, etc. will change the outcome. >> It also appears that this driver has a very limited error code >> vocabulary. Is that because the transport or device gives little >> information about errors? > >Yes. I'm not even sure whether Sense can be reliably retrieved. See >www.usb.org -> Developers home page -> class documents -> Bulk-Only mass >storage. They return: > > - Command in Command Block Wrapper (SCSI/ATA/etc.) succeeded > - Command failed > - Phase Error > - D'uh! So no SCSI status? That's pretty lame. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message