Date: Tue, 6 Jul 1999 19:48:32 +0200 (CEST) From: Nick Hibma <hibma@skylink.it> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset Message-ID: <Pine.BSF.3.96.990706193850.296C-100000@heidi.plazza.it> In-Reply-To: <199907061713.LAA68449@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990706193850.296C-100000>