Date: Tue, 8 Feb 2000 12:46:30 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Gerard Roudier <groudier@club-internet.fr> Cc: scsi@FreeBSD.org Subject: Re: Rescan for Devices... Message-ID: <200002081946.MAA44745@narnia.plutotech.com> In-Reply-To: <Pine.LNX.3.95.1000208204507.367A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> In my opinion, It is minimal convenience for a SCSI BUS scan to ensure > deterministic device ordering. And I would certainly agree with this. It is not too hard to do and will be done. Where's my PR? 8-) >> 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. The current behavior is a bug. Hardwiring may serve as a temporary work-around but that doesn't change the fact that there is a bug to fix. > 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. Another solution, assuming you have a deterministic method for doing this is to request a particular path-id from the XPT at the time of your attach. Even if the number you request is in use, the XPT should be able to use this information to order the controllers your driver controls in a consistent order relative to each other. I'm not sure that the "request a path-id" code works correctly right now, but it was written with the intent to provide this kind of ordering service at some point down the line. -- Justin 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?200002081946.MAA44745>