Bug#439462: linux-2.6: pci ordering issue
On Sat, Aug 25, 2007 at 01:22:37AM -0700, Matt Taggart wrote:
> Package: linux-2.6
> Version: 2.6.18.dfsg.1-13etch1
> Last September Matt Domsch <Matt_Domsch@dell.com> reported a problem where,
> due to the difference in the way the 2.4 and 2.6 kernels walk the PCI bus,
> on some systems drivers (mainly NIC drivers) were discovering and naming
> devices in different orders from 2.4 to 2.6. The problem, potential
> solutions, and proposed patch are at
> The patch changes the kernel pci sorting order to breadth-first for systems
> that are known to have their chassis ports(and documentation/remote
> management) labeled in that order. It does this by matching DMI strings for
> the systems. Matt Domsch later provided another two patches adding
> additional systems to the list
> Here's a minor related patch
> These patches were not in the 2.6.18 kernel that shipped with etch, but
> they are in the newer 2.6 kernels in lenny and sid. For the 17 different
> system types covered by these patches, people installing etch (or older 2.6
> kernels) will have their NICs potentially discovered in a different order
> than 2.4 kernels in sarge and 2.6 kernels in lenny and sid. There are a few
> different cases:
> 1) People fresh installing etch on these systems will be confused that the
> linux ordering doesn't match the vendor chassis/documentation/remote
> management labels.
> 2) People upgrading from 2.4 kernels (like in sarge) to etch will be
> confused when their NICs are reordered. If possible something should be
> added to the etch errata about this.
> 3) People upgrading from etch kernels to newer 2.6 kernels in lenny/sid
> will be confused when their NICs swap back and now suddenly match the
> chassis/docs/remote management labels. Something will need to be added to
> the lenny release notes about this.
> 4) People upgrading from sarge 2.4 kernels directly to lenny/sid 2.6
> kernels won't have a problem. But I'm not sure if that's a supported
> upgrade path, I think the recommendation is upgrading via etch.
> On frustrating thing is that the more people "X" that install broken etch
> on these systems, the more that A) have to deal with the confusion of
> having things bacwards and B) will have things changed the other direction
> when they upgrade to lenny. It is tempting to think about trying to include
> these patches in a stable kernel update to try and minimize X, but for the
> people that have already installed broken etch on these system "Y", they
> would be changed with a stable kernel update which is probably even more
> shocking. Because the systems affected are fairly new, I am guessing that X
> >> Y, but I'm not sure if that's enough to justify a stable kernel update.
> I guess the stable kernel release managers can decide that.
> I have access to several of the systems on the list and ran into this bug
> when installing etch on them, the results are sort of interesting:
> Proliant bl460c: two internal nics, swapped
> NIC1=eth1 NIC2=eth0
> Proliant bl465c: two internal nics, not swapped (routing was such that
> depth-first and breadth-first produced the same result)
> NIC1=eth0 NIC2=eth1
> Proliant bl480c: four internal nics, pairs swapped
> NIC1=eth2 NIC2=eth3 NIC3=eth0 NIC4=eth1
> I put "lspci -tvnn" output for the above at
> I have booted newer lenny/sid kernels on the above machines and confirmed
> that the patches fix the ordering. I'm willing to test other potential
> fixes if needed.
> I am filing this bug against a specific version of linux-2.6, but it
> affects all older 2.6 kernels and all newer 2.6 kernels up to the point the
> above patches made it into a debian kernel (the first patch was in upstream
> 2.6.19 at least).
this patch was never backported to the 2.6.18 kernel.
Since most systems should be upgraded to Etch by now I think we should just
close this bug. Do you agree?
(Also all NICs are covered the persistent-net-rules udev rule)