Date: Mon, 3 Jan 2000 22:19:08 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Gerard Roudier <groudier@club-internet.fr> Cc: Bernd Walter <ticso@cicely.de>, freebsd-scsi@FreeBSD.ORG Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000103221908.A10024@panzer.kdm.org> In-Reply-To: <Pine.LNX.3.95.1000104001636.332A-100000@localhost>; from groudier@club-internet.fr on Tue, Jan 04, 2000 at 12:39:08AM %2B0100 References: <20000102233944.B87267@cicely8.cicely.de> <Pine.LNX.3.95.1000104001636.332A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 04, 2000 at 00:39:08 +0100, Gerard Roudier wrote: > On Sun, 2 Jan 2000, Bernd Walter wrote: > > On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > > > On Sun, 2 Jan 2000, Bernd Walter wrote: > > > The XPT takes decision of starting the device unit based on the sense > > > information returned by the device. The device (da6) should return CHECK > > > CONDITION status on TUR (test unit ready command) and then provide the > > > corresponding sense information on a subsequent REQUEST SENSE command. The > > > REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if a > > > CHECK CONDITION status is returned. > > > > > > It would be interesting to know how drive da6 responds to a TUR. You may > > > use the following command and report result: > > > > > > camcontrol tur da6 -v > > > > > bash-2.03# camcontrol tur -u 6 -n da > > Unit is not ready > > I was expecting the whole sense data or at least asc/ascq values. There > are numerous way to be not ready for a device and only one is documented by > SCSI as suggesting a start command to be sent by the initiator. > Values are ASC=4, ASCQ=2 > ASC=4 means 'not ready', ASCQ value tells about the reason or suggests the > next action to apply. ASCQ=2 when ASC=4 suggest initializing command to be > sent to the device. > > If your device does not return these values, then quirked it should be, in > my opinion. Yes, it should be quirked if it doesn't return the usual values. There is already one precedent for this, and a second I've had sitting in my tree for a good while. > 'man camcontrol' talk about the -v option used with tur subcommand to > display sense data in case of CHECK CONDITION. Could you give a try with > the -v option and report result. Yep, we can't really determine anything about the cause of the problem without sense information. > > Anyway if you think it has nothing to do with your driver and it's not worth > > to think about the reason - I can live with it as it's only a camcontrol > > command in /etc/rc . I just worried it might happen on other drives too. > > By the way, some devices seem already quirked in scsi_all.c for CAM to > send them a start command appropriately. :) Quantum decided to return a vendor-specific ASC/ASCQ with their Fireball ST drives when they aren't spun up. I'm not sure why, but this is just another example of Quantum's "skill" when it comes to writing firmware. Ken -- Kenneth Merry ken@kdm.org 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?20000103221908.A10024>