Bug 10583

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@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@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.