From owner-freebsd-scsi  Sun Oct 12 02:33:33 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA11176
          for freebsd-scsi-outgoing; Sun, 12 Oct 1997 02:33:33 -0700 (PDT)
          (envelope-from owner-freebsd-scsi)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA11109;
          Sun, 12 Oct 1997 02:32:24 -0700 (PDT)
          (envelope-from se@zpr.uni-koeln.de)
Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA02411
  (5.67b/IDA-1.5); Sun, 12 Oct 1997 11:32:22 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id JAA00743; Sun, 12 Oct 1997 09:44:27 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
 yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
 EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-Id: <19971012094426.47163@mi.uni-koeln.de>
Date: Sun, 12 Oct 1997 09:44:26 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Kenneth Merry <ken@plutotech.com>
Cc: scsi@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG>
Subject: Re: Trouble with dump on ncr
References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710120615.AAA18578@pluto.plutotech.com>; from Kenneth Merry on Sun, Oct 12, 1997 at 12:15:56AM -0600
Sender: owner-freebsd-scsi@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On 1997-10-12 00:15 -0600, Kenneth Merry <ken@plutotech.com> wrote:
> > 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.  

I downloaded that code, but did not have time 
to look into it in detail. It is unfortunate,
that many parts outside /sys have to me made
aware of the CAM driver, IMHO.

> 	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 ...

Regards, STefan