[Bugme-new] [Bug 10583] New: x86 PCI dmi_check_system() quirk checks not being run
bugme-daemon at bugzilla.kernel.org
bugme-daemon at bugzilla.kernel.org
Thu May 1 07:01:12 PDT 2008
http://bugzilla.kernel.org/show_bug.cgi?id=10583
Summary: x86 PCI dmi_check_system() quirk checks not being run
Product: Platform Specific/Hardware
Version: 2.5
KernelVersion: 2.6.25
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: x86-64
AssignedTo: platform_x86_64 at kernel-bugs.osdl.org
ReportedBy: Matt_Domsch at dell.com
CC: linux-bugs at dell.com
Latest working kernel version: unknown
Earliest failing kernel version: unknown
Distribution: Fedora 8
Hardware Environment: Dell PowerEdge 1955
Software Environment: Fedora 8
Problem Description:
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. dmi_check_system(pciprobe_dmi_table) is not getting run
anymore on x86.
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(pciprobe_dmi_table), which is how all the DMI-based quirks are
discovered and used.
The solution will involve moving the dmi_check_system(pciprobe_dmi_table) call
out of pci_legacy_init() and into somewhere that is executed regardless of
pcibios_scanned having been run. Perhaps inside of or ahead of
pci_acpi_init().
I'm not sure when this broke.
Fedora 8 gold kernel 2.6.23.1-42.fc8 and and all intermediate kernels up until
Fedora rawhide kernel 2.6.25-8.fc9.x86_64 also fail.
Steps to Reproduce:
1. install Fedora 8 with above kernel on a system listed in
pciprobe_dmi_table[] such as a Dell PowerEdge 1955.
2. boot. 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.
Filed in Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=444791
Comment #3 From Dave Jones (davej at redhat.com) on 2008-04-30 14:01 EST
[reply]
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 From Matt Domsch (matt_domsch at dell.com) on 2008-04-30 22:39 EST
[reply]
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 i386/x86-64 merger, I can't tell very well.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the Bugme-new
mailing list