This is what happened:
I had
Controller PCI Slot IRQ Device BIOS Linux
========== ======== === ====== ==== =====
Adaptec 2940UW 10 11
IBM DCAS C: (0x80) /dev/sda
Adaptec 2940U 11 10
other devices (CD-ROMs and Tapes)
I then added a DEC DSP3160 to the Adaptec 2940U and the system
mutated into
Controller PCI Slot IRQ Device BIOS Linux
========== ======== === ====== ==== =====
Adaptec 2940UW 10 11
IBM DCAS C: (0x80) /dev/sdb
Adaptec 2940U 11 10
DEC DSP D: (0x81) /dev/sda
other devices (CD-ROMs and Tapes)
which not only fucked up my fstab, but also confused LILO.
I had a closer look at /drivers/scsi/aic7xxx.c:aic7xxx_detect()
and found that this function has a controller discovery strategy
that differs from the one the Bios uses (assuming the Bios scans
the PCI slots in PCI slot number order).
aic7xxx_detect() has a table aic7xxx_pci_devices[] that lists
all aic7xxx devices known to the driver, oldest/smallest first.
The drivers walks through this table and asks the PCI Bios for a
device of this type. If this device isn't found, the driver
asks for the next "better" device type. Thus, a 2940U is always
found before a 2940UW and any disk on the U controller is always
sorted before any disk on the UW controller.
Since the approach is different, Bios disk numbers and Linux
disk numbers do not match.
I hacked around my particular problem by inverting the sorting
order of aic7xxx_pci_devices[]. But I suspect that the real
solution to the problem is to swap the inner and the outer loop:
The driver should probe the first PCI slot first for a matching
Adaptec controller, then proceed to the next PCI slot in slot
order. This would ensure that controllers are found in the same
order as the Bios finds them.
Kristian
-- Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu