Linux not adhering to BIOS Drive boot order?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · James Bottomley
One of the ways this could be solved would be to impose bus ordering on the detection sequence.
...
On Solaris and Irix, there is an auxillary file in /etc that maps the hardware path to a controller to a controller instance number. This lets you name a device based on the controller instance number, and to possibly move to a different physical slot it if needed.
Some examples:
Irix /etc/ioconfig.conf:
2 /hw/module/1/slot/io9/fibre_channel/pci/0/scsi_ctlr/0
This says that SCSI controller 2 is really a Fibre Channel controller in slot 9 (on an Origin 2000).
Solaris /etc/path_to_inst:
"/pci@4,4000/scsi@3" 0 "qla2200"
This says that the QLA2200 Fibre Channel controller in slot 3 of PCI bus 4,4000 is controller 0 (zero) for the qla2200 driver.
"/pci@4,4000/scsi@3/sd@0,3" 737 "sd"
This says that SCSI target 0 will be unit 737 for the sd driver. -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
[James Bottomley]
Quoted 3 lines
The fundamental problem that we all agree on is that SCSI devices are detected in the order that the mid-layer
hosts.cfile calls their detect routines.
That was yesterday. Today they are detected in the order they are linked into the kernel, cf. the Makefile. But yes, the problem is basically the same.
Quoted 2 lines
Further, for multiple cards of the same type, the detection order is up to the individual driver.
Yes. PCI-based drivers will most likely use bus order since the kernel provides facilities to do this easily. For a single driver driving multiple cards on multiple bus types, who knows.
Quoted 2 lines
One of the ways this could be solved would be to impose bus ordering on the detection sequence.
This would be rather an intrusive change, since it puts the burden on hosts.c to know what devices are where rather than on each driver.
A much less intrusive (?) variation: scsi_register() is given the device location in some form. It would then use insertion sort to add the new adapter to the list of known ones. Obviously this behavior should only apply until the end of the boot sequence -- modules always get put on the end of the list. The bus location would be a 32-bit number, perhaps, with the high 8 bits for bus type and the low 24 bits for further enumeration (for PCI: 8 bits each for bus, slot, and fn).
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Peter Samuelson
[James Bottomley]
Quoted 3 lines
The fundamental problem that we all agree on is that SCSI devices are detected in the order that the mid-layer
hosts.cfile calls their detect routines.That was yesterday. Today they are detected in the order they are linked into the kernel, cf. the
Makefile. But yes, the problem is basically the same.
Quoted 6 lines
Quoted 2 lines
Further, for multiple cards of the same type, the detection order is up to the individual driver.
Yes. PCI-based drivers will most likely use bus order since the kernel provides facilities to do this easily. For a single driver driving multiple cards on multiple bus types, who knows.
Multiple bus types... Compaq server with PCI and EISA, for example? IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a breadth-first scan; PCI busses first, then bridged devices on PCI, then internal non-PCI busses, then external busses.
Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge?
-- Ferret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines
Multiple bus types... Compaq server with PCI and EISA, for example? IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a breadth-first scan; PCI busses first, then bridged devices on PCI, then internal non-PCI busses, then external busses.
No, bridging is transparent to most drivers, so this doesn't necessarily make sense. The thing to do is just decree "drivers will be registered in *this* order..." and then list the busses in some arbitrary order, and specify some sub-scheme for enumerating drivers on each bus.
...Which still doesn't solve the problem of multiple device types on a single bus, for which I think my proposal (passing a meta-address of some sort into scsi_register() and similar, and letting it sort devices as they come in. (Until the end of the bootstrap, of course. Modules all go in at the end.)
Quoted 2 lines
Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge?
There are lots of non-PCI systems out there. And quite a few, I suspect, where PCI is bridged off the "native" bus rather than the other way 'round.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jan 18, 2001 at 09:59:06AM -0800, [email protected] wrote:
...
Quoted 11 lines
Quoted 3 lines
Yes. PCI-based drivers will most likely use bus order since the kernel provides facilities to do this easily. For a single driver driving multiple cards on multiple bus types, who knows.
Multiple bus types... Compaq server with PCI and EISA, for example? IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a breadth-first scan; PCI busses first, then bridged devices on PCI, then internal non-PCI busses, then external busses.
Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge?
Yes.
Oh, you propably won't meet them in PC world, but pick any UltraSPARC; PCI and SBUS are on parallel "hoses". ("hose" is term used at Alpha code for the IO-bus to
CPU/MEMORY bus interface, sort of "north bridge".)
Actually those UltraSPARC systems have core-bus called UPA, and IO-busses, like PCI and SBUS, are connected there...
Also these "big" systems often do come with multiple "hoses" of same type.
If you look carefully at intel things, there is this "FSB" which is the real core-bus, and IO-busses hang on it.
I have never myself seen big Digital Alpha system where IO- busses are anything but PCI, but there exists options to place there FutureBus+, PCI, VME, TurboChannel, and several other DEC proprietary things. With 43-45 bits of physical address space out of the processors, it is trivial to plug in multiple 32-bit address space busses.
In coherent view NUMA implementation of Linux, there possibly comes even the detail about which NUMA node the busses reside at.
Quoted 1 line
-- Ferret
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 37 lines · Matti Aarnio
On Thu, Jan 18, 2001 at 09:59:06AM -0800, [email protected] wrote:
...Quoted 11 lines
Quoted 3 lines
Yes. PCI-based drivers will most likely use bus order since the kernel provides facilities to do this easily. For a single driver driving multiple cards on multiple bus types, who knows.
Multiple bus types... Compaq server with PCI and EISA, for example? IIRC the EISA bus is bridged onto one of the PCI busses. Perhaps a breadth-first scan; PCI busses first, then bridged devices on PCI, then internal non-PCI busses, then external busses.
Are there any systems where a non-PCI bus is not connected through a PCI-foo bridge?
Yes.
Oh, you propably won't meet them in PC world, but pick any UltraSPARC; PCI and SBUS are on parallel "hoses". ("hose" is term used at Alpha code for the IO-bus to
CPU/MEMORY bus interface, sort of "north bridge".)
Actually those UltraSPARC systems have core-bus called UPA, and IO-busses, like PCI and SBUS, are connected there...Also these "big" systems often do come with multiple "hoses" of same type.
If you look carefully at intel things, there is this "FSB" which is the real core-bus, and IO-busses hang on it.
I have never myself seen big Digital Alpha system where IO- busses are anything but PCI, but there exists options to place there FutureBus+, PCI, VME, TurboChannel, and several other DEC proprietary things. With 43-45 bits of physical address space out of the processors, it is trivial to plug in multiple 32-bit address space busses.
Quoted 2 lines
In coherent view NUMA implementation of Linux, there possibly comes even the detail about which NUMA node the busses reside at.
I'm pretty sure the IBM PC-Server 700 (8 MCA-slots and 8 PCI-slots and a lot of other cool stuff) doesn't have the MCA-bus bridged onto the PCI-bus. Maybe the other way around. I'd be happy to get one of these machines to test this, but they seem to be a little hard to get by for free... :^)
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/