From owner-freebsd-scsi Tue Jul 6 10:52:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id BA8B614D33 for ; Tue, 6 Jul 1999 10:52:56 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-149.skylink.it [194.185.55.149]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id TAA32686; Tue, 6 Jul 1999 19:52:32 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id TAA00343; Tue, 6 Jul 1999 19:48:32 +0200 (CEST) Date: Tue, 6 Jul 1999 19:48:32 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset In-Reply-To: <199907061713.LAA68449@narnia.plutotech.com> 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 > This stuff should really go to the SCSI list. I read that list much more > frequently than this one. Good idea. > The hard coded reset delay in there is quite crude. You should just > call xpt_freeze_devq() for that device and then release the queue ... > It also looks like all umass I/O is blocking/polling. Since this can occur > from a SWI, this is pretty bad to do. Is there no alternative? You are looking at the wrong version of the driver (the version in CURRENT is rapidly becoming obsolete). Please have a look at: http://www.etla.net/~n_hibma/usb/umass.c.new This version uses a state machine triggered by callbacks from finished USB transfers. > from a timeout handler. In general, the peripheral drivers will wait > until after a bus settle delay anyway, but the only way to ensure this > delay is to freeze the queue. 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. > 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. > 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! And nothing else. Braindead, but that's the spec for you. Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message