Date: Fri, 11 Jun 1999 14:05:58 -0600 From: Steve Bishop <steveb@iserver.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: "Chris D. Faulhaber" <jedgar@fxp.org>, freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time Message-ID: <37616C26.7A482F12@iserver.com> References: <199906111726.LAA50058@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nothing happens when I run the command "camcontrol reset 0" Everything's the same as before I ran the command. The changer still works and everything. -Steve "Kenneth D. Merry" wrote: > Steve Bishop wrote... > > "Chris D. Faulhaber" wrote: > > > > > In my previous life, I had to service many Spectra Logic changers...they > > > can be very picky with the system probing them while they are still > > > initializing. > > > > > > Is the changer initializing (arm moving, etc) when FreeBSD is booting? If > > > so, you may want to try using a <much> longer SCSI_DELAY in your kernel's > > > config and see what happens. Also, it should be ok if the scsi controller > > > resets the changer, scans the bus and does not see it since the OS will > > > scan the bus for itself (and not depend on the card's bios). > > > > > > ----- > > > Chris D. Faulhaber <jedgar@fxp.org> | All the true gurus I've met never > > > System/Network Administrator, | claimed they were one, and always > > > Reality Check Information, Inc. | pointed to someone better. > > > > The SCSI Controller (host adapter) resets the bus, and then scans it, and sees > > everything. It is the OS that locks up the changer with a bus reset, and then > > just sees the drives. The bus reset seems to lock the changer up immediately, so > > that as soon as the SCSI_DELAY period begins, it's already locked up. > > > > This, of course, points to this being a Spectralogic problem since the bus > > reset causes the changer to lock up regardless of whether it's the OS, or > > the SCSI controller. > > > > I don't remember seeing this problem with Solaris, but maybe it doesn't do > > a bus reset during boot. > > Generally, the reason for doing a bus reset at boot is to clear out any > previously negotiated transfer settings. > > I think there may be a way to boot your machine without resetting the bus > in question. Justin put in some logic in the transport layer to handle > negotiating transfer settings without resetting the bus beforehand. That > sort of thing would also be handy in a multiple-initiator environment. > > I think the only way to enable it currently for Adaptec controllers is to > enable target mode for the controller. Of course that currently disables > initiator mode, which you don't want to do. :) > > Anyway, if you really think the bus reset is the problem, you'll probably > need to talk to Justin (gibbs@FreeBSD.ORG) about it. You probably won't > get a response until he gets back from USENIX. > > It does sound like your changer may be kinda buggy, though. > > The fact that your changer works on rescan does make it sound like the bus > reset is causing the problems. What happens if you reset the bus with > camcontrol? > > camcontrol reset 0 > > (if the changer is on bus 0) > > 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?37616C26.7A482F12>