Date: Fri, 2 Jul 1999 22:27:19 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: ken@plutotech.com (Kenneth D. Merry) Cc: scsi@freebsd.org Subject: Re: FreeBSD panics with Mylex DAC960SX Message-ID: <199907030327.WAA22102@aurora.sol.net> In-Reply-To: <199907021731.LAA51596@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 2, 1999 11:31: 0 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907030327.WAA22102>