Bug 129449 - SCSI host order for same-hardware HBAs changes arbitrarily
SCSI host order for same-hardware HBAs changes arbitrarily
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-08-09 07:16 EDT by David Zambonini
Modified: 2015-01-04 17:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 01:25:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
SCSI initialisation (2.27 KB, text/plain)
2004-08-09 07:58 EDT, David Zambonini
no flags Details
lspci -vx (2.6.6-1.435.2.3smp) (6.10 KB, text/plain)
2004-08-09 08:37 EDT, David Zambonini
no flags Details
lspci -vx (2.6.7-1.494.2.2smp) (6.09 KB, text/plain)
2004-08-09 08:38 EDT, David Zambonini
no flags Details

  None (edit)
Description David Zambonini 2004-08-09 07:16:52 EDT
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):

How reproducible:

Steps to Reproduce:


Additional info:
Comment 1 Arjan van de Ven 2004-08-09 07:19:19 EDT
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
Comment 2 David Zambonini 2004-08-09 07:58:41 EDT
Created attachment 102510 [details]
SCSI initialisation

Relevant SCSI details from dmesg, whole can be supplied if required.
Comment 3 David Zambonini 2004-08-09 08:08:28 EDT
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
alternative ordering.

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.
Comment 4 Arjan van de Ven 2004-08-09 08:24:58 EDT
can you attach lspci -vx from both kernels ?
Comment 5 Arjan van de Ven 2004-08-09 08:26:34 EDT
are you sure you're not upgrading from an smp to a UP or vice versa
kernel ?
Comment 6 David Zambonini 2004-08-09 08:37:51 EDT
Created attachment 102511 [details]
lspci -vx (2.6.6-1.435.2.3smp)
Comment 7 David Zambonini 2004-08-09 08:38:51 EDT
Created attachment 102512 [details]
lspci -vx (2.6.7-1.494.2.2smp)
Comment 8 David Zambonini 2004-08-09 08:39:54 EDT
Yes, sure - both are smp, not booting into UP kernel.
Comment 9 Dave Jones 2005-04-16 01:25:50 EDT
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.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.