Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jun 1999 11:26:14 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        steveb@iserver.com (Steve Bishop)
Cc:        jedgar@fxp.org (Chris D. Faulhaber), freebsd-scsi@FreeBSD.ORG
Subject:   Re: scsi probe at boot time
Message-ID:  <199906111726.LAA50058@panzer.plutotech.com>
In-Reply-To: <37614186.383B1A01@iserver.com> from Steve Bishop at "Jun 11, 1999 11:04:07 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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?199906111726.LAA50058>