Date: Tue, 8 Feb 2000 12:54:56 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Gerard Roudier <groudier@club-internet.fr> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, George Morgan <gemorga2@vt.edu>, freebsd-scsi@FreeBSD.ORG Subject: Re: Rescan for Devices... Message-ID: <20000208125456.A32007@panzer.kdm.org> In-Reply-To: <Pine.LNX.3.95.1000208204507.367A-100000@localhost>; from groudier@club-internet.fr on Tue, Feb 08, 2000 at 09:17:21PM %2B0100 References: <20000207143833.A24212@panzer.kdm.org> <Pine.LNX.3.95.1000208204507.367A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 08, 2000 at 21:17:21 +0100, Gerard Roudier wrote: > On Mon, 7 Feb 2000, Kenneth D. Merry wrote: > > On Mon, Feb 07, 2000 at 22:55:33 +0100, Gerard Roudier wrote: > > > 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 ... Ahh. > In my opinion, It is minimal convenience for a SCSI BUS scan to ensure > deterministic device ordering. I agree. > > 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. As I said in my mail (sent after this one), the behavior you've seen is a bug, and is on Justin's list of things to fix. Ideally, when you rescan a bus, things should be attached in ascending order, just as on boot. Ken -- Kenneth Merry ken@kdm.org 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?20000208125456.A32007>