From owner-freebsd-scsi  Fri Jul  2 20:27:29 1999
Delivered-To: freebsd-scsi@freebsd.org
Received: from aurora.sol.net (aurora.sol.net [206.55.65.76])
	by hub.freebsd.org (Postfix) with ESMTP id 6CBCB14C14
	for <scsi@freebsd.org>; Fri,  2 Jul 1999 20:27:22 -0700 (PDT)
	(envelope-from jgreco@aurora.sol.net)
Received: (from jgreco@localhost)
	by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id WAA22102;
	Fri, 2 Jul 1999 22:27:20 -0500 (CDT)
From: Joe Greco <jgreco@ns.sol.net>
Message-Id: <199907030327.WAA22102@aurora.sol.net>
Subject: Re: FreeBSD panics with Mylex DAC960SX
In-Reply-To: <199907021731.LAA51596@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 2, 1999 11:31: 0 am"
To: ken@plutotech.com (Kenneth D. Merry)
Date: Fri, 2 Jul 1999 22:27:19 -0500 (CDT)
Cc: scsi@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Yes and no.  I forgot that you were running 3.1-era code.  I made some
> changes before 3.2 went out (I can't remember when, but you could probably
> just look at the cvs logs for scsi_da.c and see) to make the da and cd
> drivers to make them attach in almost every case.  (the exception being
> when the drive returns a "logical unit not supported" error)
> 
> So, what I would expect to happen with 3.2 or 4.0 code would be that the da
> driver would attach, but you wouldn't be able to open it to fsck the drive
> until the drive is ready.

Seems quite reasonable.

If you don't mind waiting a week or so, I'll be able to test it on a 3.2R
box.  I just can't power cycle a machine in Chicago from here in Milwaukee,
so I've gotta make a road trip.

> Then, you might be able to do something like this in /etc/rc:
> 
> camcontrol tur -n da -u 1 >/dev/null 2>&1
> while [ "$?" != 0 ]
> do
> 	sleep 1
> 	camcontrol tur -n da -u 1 >/dev/null 2>&1
> done
> ...do fsck, etc...

I'll actually stick something like that in with the fsck code, which is
later in a /usr/local/etc/rc.* something-or-other.  The system is supposed
to bring itself up and then do whatever is needed to start its news
subsystem, since (among other things) I'd rather have it live on-net to
refuse connections while this is all going on.  Thanks for the specific
camcontrol incantation to check the thing...  I'm sure I'd have figured it
out eventually but I like having the correct solution.  ;-)

> We could also probably do something within the CAM error recovery code
> along the same lines, but I think it would probably end up being a kludge,
> and possibly not correct, at least within the current error recovery
> framework.

I'd actually rather _not_ see that, or at least have it be only an optional
behaviour of some sort.  I do think it is completely legitimate for the OS
to say that a drive isn't available, but it'd be a very bad thing (as far
as I am concerned) for the OS to get hung up waiting for a drive to become
ready.

... JG


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message