Date: Fri, 2 Jul 1999 21:31:57 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: jgreco@ns.sol.net (Joe Greco) Cc: scsi@freebsd.org Subject: Re: FreeBSD panics with Mylex DAC960SX Message-ID: <199907030331.VAA58017@panzer.kdm.org> In-Reply-To: <199907030327.WAA22102@aurora.sol.net> from Joe Greco at "Jul 2, 1999 10:27:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Greco wrote... > > 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. If you apply the patch I attached to my last message, you should get the same behavior from your older code, and avoid making the 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. ;-) You're welcome. It should work okay, but make sure you test it out of course. :) > > 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. I agree. Ken -- Kenneth Merry ken@plutotech.com 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?199907030331.VAA58017>