Asus PR-DLS Dual Xeon (P4) motherboard 2.6.0-test11 kernel with acpi configured. If I boot normally, the e1000 device is not recognised. If I boot with pci=noacpi, the e1000 is recognised ( but e100/e1000 are assigned opposite ethx compared to 2.4) lspci in both cases gives these devices 00:00.0 Host bridge: ServerWorks CMIC-LE (rev 13) 00:00.1 Host bridge: ServerWorks CMIC-LE 00:00.2 Host bridge: ServerWorks: Unknown device 0000 00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10) 00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) 00:0f.3 Host bridge: ServerWorks GCLE Host Bridge 00:10.0 Host bridge: ServerWorks: Unknown device 0101 (rev 03) 00:10.2 Host bridge: ServerWorks: Unknown device 0101 (rev 03) 00:11.0 Host bridge: ServerWorks: Unknown device 0101 (rev 03) 00:11.2 Host bridge: ServerWorks: Unknown device 0101 (rev 03) But these extra devices only appear when booting with pci=noacpi. Net access to a machine can also be arranged if it would help 02:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 (rev 07) 02:04.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 (rev 07) 03:02.0 Ethernet controller: Intel Corp. 82544GC Gigabit Ethernet Controller (LOM) (rev 02) If I can give any further info, let me know. As a seperate issue, with pci=noacpi, both the net interfaces are recognised, but in reverse order to 2.4 kernel (eth0 <=> eth1)
Created attachment 1642 [details] Dmesg -s40000 output
Created attachment 1643 [details] /proc/interrupts
Created attachment 1644 [details] acpidmp output
Created attachment 1645 [details] dmidecode output
Created attachment 1646 [details] kernel config file
Created attachment 1647 [details] lspci output when booted with acpi
Created attachment 1648 [details] lspci output when booted with pci=noacpi
your dsdt is a little wield. bridge's bus number is incorrect in your DSDT. can this box run winxp? many thanks.
Created attachment 1649 [details] work around patch for this issue please try this patch, thanks
Created attachment 1650 [details] workaround patch please try this one.
sorry, this patch is wrong. it can't get root bridge's bus number. your DSDT must provide correct _BBN, otherwise, in full ACPI mode, ACPI will get wrong bus number. I recommend you upgrade your BIOS.
Hi Shaohua WinXP runs fine on this machine Before posting the bug, I upgraded the machine to the latest bios from Asus website (Was ver 1009, now 1010), but the problem remains
There is a bios option described like this in the manual: Sparse PCI Host Bus The field allows you to reserve the bus number for the PCI slots. Configuration Options: [Disabled] [2 BUS] [3 BUS] [4 BUS] Could changing this from its current (disabled) value help?
as I said, your BIOS assigned wrong root bridge bus number for ACPI. so just try to change the BIOS setting, maybe it's useful.
OK, I tried all the bios options and it made no difference. Where do we proceed from here? Will a workaround be formulated, or will the bios simply be blacklisted? This is the latest bios version available. How does windows handle it? Would it perhaps just scan for buses between 0 and last_bus? If this will _not_ be worked-around, It should be reported to Asus. I am happy to do that, but would require some help formulating the email as I have no expertise in either acpi or pci. Since this is their top-of-the-range 1u rackable dual xeon server, I'm sure they'd be willing to help.
*** Bug 1127 has been marked as a duplicate of this bug. ***
*** Bug 1741 has been marked as a duplicate of this bug. ***
Good thing you're booting off IDE -- looks like the symbios SCSI on bus2 would not be found by Linux/ACPI, just like the e1000 on bus3 is not found. Do pci=noacpi and acpi=off give the same results for lspci and /proc/interrupts on these boxes? I had thought that we needed to fix pci=noacpi, but maybe I'm mistaken. It might be possible to detect the issue and enter "pci=noacpi" mode automatically. The "Sparse PCI Host Bus" feature sure looks suspicious. The fact that the _BBN's are all defined as zero -- Name (_BBN, 0x00) -- is just too weird. There must be some sort of run-time mechanism to set them properly. I don't suppose that the acpidmp output changes when you use those different BIOS CMOS settings? thanks, -Len
Hi Len, Indeed, it won't boot from onboard scsi with acpi. I generally use these mobos as diskless netbooted blades, but used an IDE drive for this troubleshooting. I'll run the tests you suggest and post results here tomorrow.
Created attachment 2531 [details] proposed patch please try this patch with 'pci=noacpi', it should fix your problem. The patch forbid ACPI scan PCI bus.
*** Bug 1585 has been marked as a duplicate of this bug. ***
patch looks good, but we need to see if on a system with multiple _BBN 0 that we either invoke it automatically (w/o blacklist) or at least warn the user that they should reboot with pci=noacpi. thanks, -Len
Created attachment 2594 [details] updated patch ok, the updated patch. and I don't think we have a easy method to automatically runtimely fall back to use 'pci=noacpi' when _BBN is error. The patch just notify user the _BBN is wrong.
Created attachment 2641 [details] 2.6.5 patch Applied Shaohua's patch to 2.6.5, and added automatic pci=noacpi dmi_scan entry for the Asus system this bug was filed against. Please let me know if it recognizes that system properly.
Created attachment 2801 [details] dmesg and lspci output I think I have a system which is also affected by this bug. When I don't use pci=noacpi I don't see the network cards in lspci. # lspci (with pci=noacpi) 0000:00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32) 0000:00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge 0000:00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 0000:00:0f.0 ISA bridge: ServerWorks CSB6 South Bridge (rev a0) 0000:00:0f.1 IDE interface: ServerWorks CSB6 RAID/IDE Controller (rev a0) 0000:00:0f.2 USB Controller: ServerWorks CSB6 OHCI USB Controller (rev 05) 0000:00:0f.3 Host bridge: ServerWorks GCLE-2 Host Bridge 0000:00:10.0 Host bridge: ServerWorks: Unknown device 0110 (rev 12) 0000:00:10.2 Host bridge: ServerWorks: Unknown device 0110 (rev 12) 0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 02) 0000:02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 02) Much more info in the attached file.
shipped in 2.6.6, and on top of 2.4.27-pre2 -- closing. However, I'm not pleased that pci=noacpi is required on these platforms. Perhaps we'll find a way to automatically handle _BBN 0 in the future.
Looking at the DSDT.... Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00) Name (_UID, 0x01) Name (_BBN, 0x00) ... Device (PCI1) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00110000) Name (_UID, 0x02) Name (_BBN, 0x00) ... Device (PCI2) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00110002) Name (_UID, 0x03) Name (_BBN, 0x00) ... Device (PCI3) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00100000) Name (_UID, 0x04) Name (_BBN, 0x00) ... Device (PCI4) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00100002) Name (_UID, 0x05) Name (_BBN, 0x00) Clearly the _ADR and _UID's are trying to tell us something, even if _BBN can't.
Created attachment 2986 [details] 2.6.6 debug patch to use _UID if _BBN 0 Please test this debug patch. When a PCI bus has _BBN 0, this patch will examine if it has a _UID and use that for the _BBN. Please attach any difference between dmesg and lspci before/after. Note that "acpi=strict" can disable this patch.
Created attachment 2987 [details] debug patch use _CRS And please try this patch also, it uses the return value from root bridge's _CRS method. Thanks.
*** Bug 1674 has been marked as a duplicate of this bug. ***
David Shaohua, if both patches work, i prefer yours over mine.
okay, so it took us 6-months to get here, but can anybody with a system like this test the proposed fixes? Unless it is proven to fix this issue, I can not check a fix into the kernel.
I'll test the patches today and report back
Today I tested both patches (#2986 and #2987) together with linux-2.4.27pre5 on our Asus AP1700-S5 server (Asus PR-DLS533 motherboard, see bugzilla bug id 1741) With Len's patch #2986 only, when booting without any kernel parameter the system loads the Fusion MTP driver, the driver finds the controller hardware (which it does not without the patch), but the driver can not initialize neither the controller nor the attached SCSI devices. IRQ problem? Booting with "acpi=strict", the Fusion MPT driver does not get loaded because it can't find the controller hardware. Booting with "pci=noacpi" works as usual. With David's patch #2987 only, when booting without any kernel parameter everything works: the Fusion MPT driver finds the controller and is able to initialize the hardware. The system boots just fine! :-) I will attach the some infos about the system running with this patch shortly I did not test both patches together (is this supposed to work anyway?)
Created attachment 3050 [details] Output of dmesg with David's patch This is the output of "dmesg -s 40000" on an Asus AP1700-S5 server running linux-2.4.27pre5 patched with patch #2987
Created attachment 3051 [details] Output of lspci -v with David's patch This is the output of "lspci -v" on an Asus AP1700-S5 server running linux-2.4.27pre5 patched with patch #2987
Created attachment 3052 [details] Output of cat /proc/interrupts with David's patch This is the output of "cat /proc/interrupts" on an Asus AP1700-S5 server running linux-2.4.27pre5 patched with patch #2987
Thanks for verifying that David's patch works. This is good news, as his patch (calling _CRS) should make sense always, while my patch (evaluating _UID of PCI bus) was just a quick hack based on a particuar DSDT for one system.
I can also confirm that David's patch works on an Asus PR-DLS dual HT Xeon. All pci devices are detected without any kernel parameters. Dmesg output and lspci attached. Good work.
Created attachment 3058 [details] Asus PR-DLS dmesg with David's patch
Created attachment 3059 [details] PR_DLS (last one was lspci) dmesg output with Davids patch
Created attachment 3124 [details] proposed final patch Just a small change.
shipped in 2.4.27 and 2.6.8.1 -- closing.