Skip site navigation (1)Skip section navigation (2)
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>