Date: Tue, 8 Feb 2000 21:17:21 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, George Morgan <gemorga2@vt.edu>, freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <Pine.LNX.3.95.1000208204507.367A-100000@localhost> In-Reply-To: <20000207143833.A24212@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <bus#> > > >=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 > > <Quantum XP32150W L912> at scbus1 target 0 lun 0 (da3,pass4) > > <QUANTUM XP32275W LXY4> at scbus1 target 1 lun 0 (da2,pass3) > > <IBM DDRS-34560W S71D> at scbus1 target 4 lun 0 (da5,pass6) > > <QUANTUM XP32275W LXY4> at scbus1 target 5 lun 0 (da4,pass5) > >=20 > > Second attempt after having rebooted the machine: > >=20 > > <Quantum XP32150W L912> at scbus1 target 0 lun 0 (da4,pass5) > > <QUANTUM XP32275W LXY4> at scbus1 target 1 lun 0 (da3,pass4) > > <IBM DDRS-34560W S71D> at scbus1 target 4 lun 0 (da2,pass3) > > <QUANTUM XP32275W LXY4> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000208204507.367A-100000>