Bug 444791 - Dell PowerEdge 1955 DMI match to enable pci=bfsort fails
Dell PowerEdge 1955 DMI match to enable pci=bfsort fails
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-04-30 12:24 EDT by Matt Domsch
Modified: 2008-06-06 03:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-06 03:45:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 10583 None None None Never

  None (edit)
Description Matt Domsch 2008-04-30 12:24:09 EDT
Description of problem:
DMI matching to auto-enable pci=bfsort is not working.  pci=bfsort is not being
enabled automatically, leading to onboard NICs being assigned names "backwards"
from expectations.

I'm not sure when this broke.  It has been working in RHEL5.

Version-Release number of selected component (if applicable):
PowerEdge 1955, BIOS version 1.4.2

How reproducible:

Steps to Reproduce:
1. install Fedora 8 with above kernel
2. dmesg | grep bfsort  should yield something
Actual results:
no results, ethernet NICs named backwards

Expected results:
dmesg shows bfsort getting enabled, ethernet NICs named properly.

Additional info:
Comment 1 Matt Domsch 2008-04-30 12:40:19 EDT
rawhide 2.6.25-8.fc9.x86_64 also fails.
Comment 2 Matt Domsch 2008-04-30 12:47:18 EDT
Fedora 8 gold kernel also fails.  bugger.
Comment 3 Dave Jones 2008-04-30 14:01:59 EDT
if you boot with initcall_debug, does pci_legacy_init get called ?

I wonder if we changed the default PCI probing type so that we're not preferring
PCI BIOS on that system any more.
Comment 4 Matt Domsch 2008-04-30 22:39:51 EDT
pci_legacy_init() gets called, but exits immediately.

Calling initcall 0xffffffff81487af9: pci_acpi_init+0x0/0xae()
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
initcall 0xffffffff81487af9: pci_acpi_init+0x0/0xae() returned 0.
initcall 0xffffffff81487af9 ran for 0 msecs: pci_acpi_init+0x0/0xae()
Calling initcall 0xffffffff81487ba7: pci_legacy_init+0x0/0xf8()
initcall 0xffffffff81487ba7: pci_legacy_init+0x0/0xf8() returned 0.
initcall 0xffffffff81487ba7 ran for 0 msecs: pci_legacy_init+0x0/0xf8()

pci_acpi_init() ran and set pcibios_scanned++.
pci_legacy_init() then ran, saw pcibios_scanned > 0, and returned.
If it hadn't returned, it would have called pcibios_scan_root(), which calls
dmi_check_system(), which is how all the DMI-based quirks are discovered and used.

So we'll need to get dmi_check_system() executed regardless of if it's
pci_acpi_init() or pci_legacy_init() that's really used.

This may have broken before the merger, I can't tell very well.
Comment 5 Matt Domsch 2008-05-01 15:55:32 EDT
found it.
commit 08f1c192c3c32797068bfe97738babb3295bbf42
Author: Muli Ben-Yehuda <muli@il.ibm.com>
Date:   Sun Jul 22 00:23:39 2007 +0300

    x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata

    This patch introduces struct pci_sysdata to x86 and x86-64, and
    converts the existing two users (NUMA, Calgary) to use it.

    This lays the groundwork for having other users of sysdata, such as
    the PCI domains work.

    The Calgary bits are tested, the NUMA bits just look ok.

    Signed-off-by: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/arch/i386/pci/acpi.c b/arch/i386/pci/acpi.c
index b33aea8..bc8a44b 100644
--- a/arch/i386/pci/acpi.c
+++ b/arch/i386/pci/acpi.c
@@ -8,20 +8,42 @@
 struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_device *device, int
domain, int busnum)
        struct pci_bus *bus;
+       struct pci_sysdata *sd;
+       int pxm;
+       /* Allocate per-root-bus (not per bus) arch-specific data.
+        * TODO: leak; this memory is never freed.
+        * It's arguable whether it's worth the trouble to care.
+        */
+       sd = kzalloc(sizeof(*sd), GFP_KERNEL);
+       if (!sd) {
+               printk(KERN_ERR "PCI: OOM, not probing PCI bus %02x\n", busnum);
+               return NULL;
+       }
        if (domain != 0) {
                printk(KERN_WARNING "PCI: Multiple domains not supported\n");
+               kfree(sd);
                return NULL;

-       bus = pcibios_scan_root(busnum);

This last line, removing the call of pcibios_scan_root(), is what will cause
this, as pcibios_scan_root() is what calls dmi_check_system().

I reported this in kernel.org bz.
Comment 6 Chuck Ebbert 2008-05-23 03:52:04 EDT
Fixed in
Comment 7 Fedora Update System 2008-05-23 03:52:33 EDT
kernel- has been submitted as an update for Fedora 8
Comment 8 Fedora Update System 2008-05-28 22:41:35 EDT
kernel- has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-4484
Comment 9 Fedora Update System 2008-06-06 03:45:14 EDT
kernel- has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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