Red Hat Bugzilla – Bug 129449
SCSI host order for same-hardware HBAs changes arbitrarily
Last modified: 2015-01-04 17:08:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.2)
Description of problem:
We have a server with two Esclade 8506-8 HBAs - after upgrading the
kernel from 2.6.6-x to 2.6.7-x the host ordering unexpectedly changed,
leading to failure mounting all parts of the filesystem not labelled,
for example swap, due to a change in device names. We've returned to
2.6.6-x for the time being, however there appears to be no guarentee
that this will not happen again for any given update even within the
same minor version, since the host ordering appears to be set by IRQ.
Although a method exists to set the host order for HBAs based on
driver (alias scsi_hostadapter1 module1, alias scsi_hostadapter2
module2 etc.), this cannot be used when the hardware is identical or
similar thus requiring the same module. This is not specific to any
one driver since the initialisation order is set in the SCSI mid level.
Expected result: Either some way to explicitly set host order for
same-hardware HBAs, or host order set by a fixed value, such as
initialisation ordered by bus location.
I realise that something similar to this has been gone through already
for the general case of differing HBAs, with the consensus appearing
to be that module load order should not be fixed.
I'm open to suggestions....
Version-Release number of selected component (if applicable):
Steps to Reproduce:
normally PCI bus order determines the "within the same driver" order.
PCI bus order comes from the firmware (eg bios), so if you switch
from/to acpi or upgrade your bios this might change.
Still using mount-by-label is strongly recommended
Created attachment 102510 [details]
Relevant SCSI details from dmesg, whole can be supplied if required.
I've verified and regenerated the initrd for both kernels from
identical modprobe.conf. BIOS was not altered between boots, ACPI is
active on both, stock kernel arguments (ro root=LABEL=/) - can
reproduce that 2.6.6-x gives one ordering, 2.6.7-x gives an
There is a difference in reported IRQ - chipset is a ServerWorks CSB6.
mount-by-label obviously does not work for swap partitions, the
alternative, devlabel, is only initialized after swap activation? I'm
unsure if the device change affects LVM physical volume groups.
can you attach lspci -vx from both kernels ?
are you sure you're not upgrading from an smp to a UP or vice versa
Created attachment 102511 [details]
lspci -vx (2.6.6-1.435.2.3smp)
Created attachment 102512 [details]
lspci -vx (2.6.7-1.494.2.2smp)
Yes, sure - both are smp, not booting into UP kernel.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.