From owner-freebsd-scsi Fri Jun 11 13: 3:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A25114CB0 for ; Fri, 11 Jun 1999 13:03:55 -0700 (PDT) (envelope-from steveb@iserver.com) Received: by gatekeeper.iserver.com; Fri, 11 Jun 1999 14:03:54 -0600 (MDT) Received: from unknown(192.168.1.7) by gatekeeper.iserver.com via smap (V3.1.1) id xma027129; Fri, 11 Jun 99 14:03:43 -0600 Received: from iserver.com (glacier.orem.iserver.com [192.168.1.111]) by orca.orem.iserver.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.5) id OAA03315; Fri, 11 Jun 1999 14:03:37 -0600 (MDT) Message-ID: <37616C26.7A482F12@iserver.com> Date: Fri, 11 Jun 1999 14:05:58 -0600 From: Steve Bishop X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time References: <199906111726.LAA50058@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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