From owner-freebsd-scsi Fri Jun 11 10:26:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF9414FCC; Fri, 11 Jun 1999 10:26:24 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA50058; Fri, 11 Jun 1999 11:26:15 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906111726.LAA50058@panzer.plutotech.com> Subject: Re: scsi probe at boot time In-Reply-To: <37614186.383B1A01@iserver.com> from Steve Bishop at "Jun 11, 1999 11:04:07 am" To: steveb@iserver.com (Steve Bishop) Date: Fri, 11 Jun 1999 11:26:14 -0600 (MDT) Cc: jedgar@fxp.org (Chris D. Faulhaber), freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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 | 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