Skip to contentSkip to conversation

bnx2 probe order change from 2.6.21 -> 2.6.24

DISCUSSION Phil Oester 3 participants 6 messages Apr 10, 2008 – Apr 16, 2008

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Phil Oester

author
#0 lore raw

Apologies if this has been covered already, but I searched the archives and couldn't find anything.

I recently upgraded a Dell Poweredge 1950 from 2.6.21 to 2.6.24, and found that the onboard Broadcom NetXtreme II nics got probed in the reverse order.

2.6.21:

Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007)
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 16, node addr 0015c5eaef1c
ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth9: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f4000000, IRQ 16, node addr 0015c5eaef1e

2.6.24:

Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.6.9 (December 8, 2007)
ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f4000000, IRQ 16, node addr 00:15:c5:ea:ef:1e
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
udev: renamed network interface eth8 to eth9
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 16, node addr 00:15:c5:ea:ef:1c

Is this known/expected? Seems somewhat odd from both a MAC address perspective (1c < 1e) and a PCI bus order (04 < 08). Thoughts?

Phil

#1 lore raw
Quoted 4 lines · Phil Oester

I recently upgraded a Dell Poweredge 1950 from 2.6.21 to 2.6.24, and found
that the onboard Broadcom NetXtreme II nics got probed in the reverse order.

I know there is a difference in PCI probing order between 2.4 and 2.6 kernels on x86 machines, but I'm not aware of changes in these 2 recent 2.6 kernels you mentioned above. Various kernel parameters such as pci=nosort, pci=bfsort, pci=nobfsort can affect the order. Are you using any of these?

author
#2 lore raw
Quoted 11 lines · Michael Chan
Quoted 4 lines · Phil Oester

I recently upgraded a Dell Poweredge 1950 from 2.6.21 to 2.6.24, and found
that the onboard Broadcom NetXtreme II nics got probed in the reverse order.

I know there is a difference in PCI probing order between 2.4 and 2.6 kernels on x86 machines, but I'm not aware of changes in these 2 recent 2.6 kernels you mentioned above. Various kernel parameters such as pci=nosort, pci=bfsort, pci=nobfsort can affect the order. Are you using any of these?

No - nothing like that. And the e1000 devices in the box (eth0 - 7) are probing in the same order, which (perhaps incorrectly) leads me to believe it's not PCI related, but specific to bnx2.

Phil

#3 lore raw
Quoted 11 lines · Phil Oester
Quoted 5 lines · Michael Chan

I know there is a difference in PCI probing order between 2.4 and 2.6 kernels on x86 machines, but I'm not aware of changes in these 2 recent 2.6 kernels you mentioned above. Various kernel parameters such as pci=nosort, pci=bfsort, pci=nobfsort can affect the order. Are you using any of these?

No - nothing like that. And the e1000 devices in the box (eth0 - 7) are probing in the same order, which (perhaps incorrectly) leads me to believe it's not PCI related, but specific to bnx2.

The driver has no control over the ordering of these devices. The PCI layer scans the buses in the order it chooses and calls the driver's probe method for every matching device that it finds.

#4 lore raw
In reply to Phil Oester

Phil Oester <[email protected]> wrote [04.10.08]:

Quoted 24 lines

Apologies if this has been covered already, but I searched the archives and couldn't find anything.

I recently upgraded a Dell Poweredge 1950 from 2.6.21 to 2.6.24, and found that the onboard Broadcom NetXtreme II nics got probed in the reverse order.

2.6.21:

Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007)
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 16, node addr 0015c5eaef1c
ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth9: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f4000000, IRQ 16, node addr 0015c5eaef1e

2.6.24:

Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.6.9 (December 8, 2007)
ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 16
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f4000000, IRQ 16, node addr 00:15:c5:ea:ef:1e
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
udev: renamed network interface eth8 to eth9
eth8: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 16, node addr 00:15:c5:ea:ef:1c

Quoted 3 lines

Is this known/expected? Seems somewhat odd from both a MAC address perspective (1c < 1e) and a PCI bus order (04 < 08). Thoughts?

Hi

We ran into this issue as well when going from 2.6.20 to 2.6.23 on dell 1950/2950s.

If you check your dmesg output from your older kernel you should see

PCI: Dell PowerEdge 1950 detected, enabling pci=bfsort.

With the newer kernel the code path that triggers the above is removed if you have ACPI enabled in the kernel.

We have been using the following patch which re-adds the code path to the ACPI PCI code.

thanks
jim

arch/i386/pci/acpi.c 2008-02-21 16:27:19.000000000 -0800 renamed from arch/i386/pci/acpi.c 2008-02-10 22:06:32.000000000 -0800 +4 -0
diff -ur linux-2.6.23.16-orig/arch/i386/pci/acpi.c linux-2.6.23.16-inap3/arch/i386/pci/acpi.c
@@ -2,9 +2,12 @@
 #include <linux/acpi.h>
 #include <linux/init.h>
 #include <linux/irq.h>
+#include <linux/dmi.h>
 #include <asm/numa.h>
 #include "pci.h"
 
+extern struct dmi_system_id __devinitdata pciprobe_dmi_table[];
+
 struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_device *device, int domain, int busnum)
 {
        struct pci_bus *bus;

@@ -27,6 +30,7 @@
                return NULL;
        }
 
+       dmi_check_system(pciprobe_dmi_table);
        sd->node = -1;
 
        pxm = acpi_get_pxm(device->handle);
arch/i386/pci/common.c 2008-02-21 16:27:19.000000000 -0800 renamed from arch/i386/pci/common.c 2008-02-10 22:06:32.000000000 -0800 +1 -1
diff -ur linux-2.6.23.16-orig/arch/i386/pci/common.c linux-2.6.23.16-inap3/arch/i386/pci/common.c
@@ -145,7 +145,7 @@
 }
 #endif
 
-static struct dmi_system_id __devinitdata pciprobe_dmi_table[] = {
+struct dmi_system_id __devinitdata pciprobe_dmi_table[] = {
 #ifdef __i386__
 /*
author
#5 lore raw
Quoted 7 lines · Jim Westfall

Phil Oester <[email protected]> wrote [04.10.08]:

Quoted 2 lines

I recently upgraded a Dell Poweredge 1950 from 2.6.21 to 2.6.24, and found that the onboard Broadcom NetXtreme II nics got probed in the reverse order.

We ran into this issue as well when going from 2.6.20 to 2.6.23 on dell 1950/2950s.

Quoted 6 lines

If you check your dmesg output from your older kernel you should see

PCI: Dell PowerEdge 1950 detected, enabling pci=bfsort.

With the newer kernel the code path that triggers the above is removed if you have ACPI enabled in the kernel.

Thanks. This was caused by commit 08f1c192c3c32797068bfe97738babb3295bbf42 (x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata).

I've sent something along to the kernel list.

Phil