Date: Sun, 12 Oct 1997 00:15:56 -0600 (MDT) From: Kenneth Merry <ken@plutotech.com> To: se@FreeBSD.ORG (Stefan Esser) Cc: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr Message-ID: <199710120615.AAA18578@pluto.plutotech.com> In-Reply-To: <19971011091605.32335@mi.uni-koeln.de> from Stefan Esser at "Oct 11, 97 09:16:05 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser wrote...
> On 1997-10-10 21:23 +0200, J Wunsch <j@uriah.heep.sax.de> wrote:
> > Re-read the freebsd-scsi archives... and then either disable tagged
> > command queuing (``options FAILSAFE''), or alternatively remove all
> > calls to scsi_start_unit() in /sys/scsi/sd.c.
> >
> > Btw., i think we are safe to make the latter change anyway. As i've
> > already mentioned in a private mail to Justin, i've recently proven
> > that the calls to scsi_start_unit() are completely useless and don't
> > work. (I had taken down a disk manually, and later tried to
> > implicitly start it by opening it again.) Thus, by removing these
> > calls, we won't break anything that's not already broken.
> >
> > Anybody objecting?
>
> I'm all for the removal of the scsi_start_unit() calls.
>
> The start unit command should instead be issued from the
> recovery code in the generic SCSI layer, IMHO, whenever
> the return status from the SCSI card driver indicates a
> drive has (been) stopped in an attempt to recover from
> that situation.
FWIW, that's what the new CAM SCSI code does. The da (i.e. sd)
driver does a read capacity upon open. If the read capacity returns with
0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error
recovery code issues a start unit command to the drive.
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.
Ken
--
Kenneth Merry
ken@plutotech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710120615.AAA18578>