From owner-freebsd-scsi Tue Feb 8 11:47:24 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by builder.freebsd.org (Postfix) with ESMTP id 54D924118 for ; Tue, 8 Feb 2000 11:47:13 -0800 (PST) Received: from localhost (ppp-173-226.villette.club-internet.fr [195.36.173.226]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA16199; Tue, 8 Feb 2000 20:47:49 +0100 (MET) Date: Tue, 8 Feb 2000 21:17:21 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: Wilko Bulte , George Morgan , freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... In-Reply-To: <20000207143833.A24212@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > > On Mon, 7 Feb 2000, Wilko Bulte wrote: > > > On Mon, Feb 07, 2000 at 10:12:57AM -0500, George Morgan wrote: > > > > Is there a way to use the *BSD command "scsi" to rescan for=20 > > > > devices on a scsi controller? I'm actually trying to do this on an= =20 > > > > OpenBSD 2.6 (sparc) machine, but I know there are some people=20 > > > > that really know SCSI well on this list... > > >=20 > > > man camcontrol > > >=20 > > > and then: > > >=20 > > > camcontrol rescan > > >=20 > > > Works just fine. > >=20 > > Not really for me, may-be since I donnot want to rescan the bus, but to > > just scan the bus for devices that haven't been seen by CAM at boot for > > some reason.=20 > >=20 > > First attempt after having switched the box on and booted for the first > > time: > >=20 > > at scbus1 target 0 lun 0 (da3,pass4) > > at scbus1 target 1 lun 0 (da2,pass3) > > at scbus1 target 4 lun 0 (da5,pass6) > > at scbus1 target 5 lun 0 (da4,pass5) > >=20 > > Second attempt after having rebooted the machine: > >=20 > > at scbus1 target 0 lun 0 (da4,pass5) > > at scbus1 target 1 lun 0 (da3,pass4) > > at scbus1 target 4 lun 0 (da2,pass3) > > at scbus1 target 5 lun 0 (da5,pass6) > >=20 > > Problem is that the order of da# devices after first boot + scanbus 1 i= s > > different from order after second boot + scanbus 1.=20 >=20 > Which devices appear during the boot, and which ones appear after the > rescan? It seems rather odd to me that your disks aren't showing up at > boot. Are they not powered on or something? I wrote `for some reason'. The main reason is due to driver testings and I may want to move BUSES among controllers for any other reason and still want to be able to boot by system without too much complexity. I also may want not to switch some devices on for the first boot, and so on ...=20 In my opinion, It is minimal convenience for a SCSI BUS scan to ensure deterministic device ordering. > > I guess the reasons given that xpt_scan_bus() is scanning targets > > (excepted the initiator obviously) in parallel. I would think that such= a > > concurrent target scanning can be faster than a sequential scanning, on= ly > > if some devices, that are too long for responding to SCSI commands used > > for the probe, (probably INQUIRY) disconnect the BUS during the scan. B= ut > > if this happens, or if some devices are reporting transient problems, t= hen > > order of devices cannot be guaranteed on successive (reboots) + (re)sca= n > > of BUS. > >=20 > > In my opinion, an option that will allow to request a sequential BUS > > (re)scan would be useful, not only for me.=20 >=20 > Devices are attached sequentially, unless you hard-wire them. If you > rescan the bus, though, the disks are given the first available device > number. I donnot want to have to deal with bunches of different kernels with=20 things hardwired. =20 > If you want things to turn up in the same place every time, I would sugge= st > hardwiring your disk device numbers to a specific bus/target/lun. This does not suit at all, since I may elect to move several BUSes. Under Linux, the PCI device scan is performed by low-level drivers and the drivers I maintain get the boot order from the NVRAM of a controller. I just have to change the boot order from NVRAM and everything gets transparent (I mean: all BUSES being numbered as I want them to be).=20 Under FreeBSD, this is not easily possible since the PCI devices scan is performed by a central resource. I have had to find another solution that consists in returning DEV_NOT_THERE to CAM for scsi devices that are flagged as NO SCAN AT BOOT in the NVRAM and to rescan some BUSES after boot. Note that doing a scan LUN per device solves the problem of scan BUS giving undeterministic device ordering, but it requires dozen of manual operations instead of just changing a couple of informations from the SDMS setup and a couple of camcontrol rescan #BUS commands after boot. =20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message