From owner-freebsd-scsi Sun Oct 12 17:22:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00756 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 17:22:52 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00739; Sun, 12 Oct 1997 17:21:42 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id SAA06431; Sun, 12 Oct 1997 18:21:41 -0600 (MDT) From: Kenneth Merry Message-Id: <199710130021.SAA06431@pluto.plutotech.com> Subject: Re: Trouble with dump on ncr In-Reply-To: <19971012094426.47163@mi.uni-koeln.de> from Stefan Esser at "Oct 12, 97 09:44:26 am" To: se@freebsd.org (Stefan Esser) Date: Sun, 12 Oct 1997 18:21:41 -0600 (MDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser wrote... > On 1997-10-12 00:15 -0600, Kenneth Merry wrote: > > One interesting thing about that, though.. Apparantly not all > > drives return 0x04,0x02 when they aren't spun up. I ran into some Quantum > > Fireball ST (Stratus) drives that return 0x04,0x0b when they aren't spun > > up. Strange, 'eh? That sense code qualifier isn't in the SCSI specs (not > > even SCSI-3), and it isn't in Quantum's documentation on the drive. > > Well, I guess it is save to just exclude those > ASCQ values for ASC 0x04 that indicate a simple > motor start command is not sufficient (0x04/0x03 > surely does not ask for a START STOP UNIT command :) > > How about "issue a start unit command for ASC 0x04 > and ASCQ equal 0x02 or greater-equal 0x09. Can't > see how that could cause problems ... Actually, that's just what I did to fix the problem, at least temporarily. The check (in cam_periph_error()) now looks like: else if (asc == 0x04 && ((ascq == 0x02) || (ascq > 0x08)) && save_ccb != NULL && ccb->ccb_h.retry_count > 0) { That probably isn't the best thing to do, though. What if another vendor returns the exact same sense code, but it means something else? In light of that, I'm planning to add a sense code quirk table, so that we can adequately deal with strange sense codes like 0x04,0x0b. The sense code quirk table will have suggested action flags, opcodes or something like that, to tell the error recovery code what to do in the case of a particular sense code for that particular vendor/model/etc. Ken -- Kenneth Merry ken@plutotech.com