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 > > > > devices on a scsi controller? I'm actually trying to do this on an > > > > OpenBSD 2.6 (sparc) machine, but I know there are some people > > > > that really know SCSI well on this list... > > > > > > man camcontrol > > > > > > and then: > > > > > > camcontrol rescan <bus#> > > > > > > Works just fine. > > > > 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. > > > > First attempt after having switched the box on and booted for the first > > time: > > > > <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) > > > > Second attempt after having rebooted the machine: > > > > <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) > > > > Problem is that the order of da# devices after first boot + scanbus 1 is > > different from order after second boot + scanbus 1. > > 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 ... 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, only > > if some devices, that are too long for responding to SCSI commands used > > for the probe, (probably INQUIRY) disconnect the BUS during the scan. But > > if this happens, or if some devices are reporting transient problems, then > > order of devices cannot be guaranteed on successive (reboots) + (re)scan > > of BUS. > > > > In my opinion, an option that will allow to request a sequential BUS > > (re)scan would be useful, not only for me. > > 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 things hardwired. > If you want things to turn up in the same place every time, I would suggest > 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). 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. Gérard. 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>