Bug 1662 - Missing PCI devices in ACPI mode; _BBN 0 - Asus PR-DLS/ServerWorks CMIC-LE
Summary: Missing PCI devices in ACPI mode; _BBN 0 - Asus PR-DLS/ServerWorks CMIC-LE
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Len Brown
URL:
Keywords:
: 1127 1585 1674 1741 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-09 14:34 UTC by Andrew Walrond
Modified: 2004-11-03 15:25 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.0-test11
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Dmesg -s40000 output (20.40 KB, text/plain)
2003-12-09 14:36 UTC, Andrew Walrond
Details
/proc/interrupts (690 bytes, text/plain)
2003-12-09 14:37 UTC, Andrew Walrond
Details
acpidmp output (85.30 KB, text/plain)
2003-12-09 14:38 UTC, Andrew Walrond
Details
dmidecode output (14.90 KB, text/plain)
2003-12-09 14:38 UTC, Andrew Walrond
Details
kernel config file (18.50 KB, text/plain)
2003-12-09 14:39 UTC, Andrew Walrond
Details
lspci output when booted with acpi (722 bytes, text/plain)
2003-12-09 14:40 UTC, Andrew Walrond
Details
lspci output when booted with pci=noacpi (966 bytes, text/plain)
2003-12-09 14:41 UTC, Andrew Walrond
Details
work around patch for this issue (900 bytes, patch)
2003-12-09 18:45 UTC, Shaohua
Details | Diff
workaround patch (887 bytes, patch)
2003-12-09 19:03 UTC, Shaohua
Details | Diff
proposed patch (9.68 KB, patch)
2004-04-06 23:31 UTC, Shaohua
Details | Diff
updated patch (10.21 KB, patch)
2004-04-14 22:19 UTC, Shaohua
Details | Diff
2.6.5 patch (8.47 KB, patch)
2004-04-21 22:23 UTC, Len Brown
Details | Diff
dmesg and lspci output (12.06 KB, text/plain)
2004-05-05 16:26 UTC, Nicol
Details
2.6.6 debug patch to use _UID if _BBN 0 (1.07 KB, patch)
2004-05-27 00:02 UTC, Len Brown
Details | Diff
debug patch use _CRS (2.11 KB, patch)
2004-05-27 03:05 UTC, Shaohua
Details | Diff
Output of dmesg with David's patch (30.01 KB, text/plain)
2004-06-03 07:32 UTC, Andreas Haumer
Details
Output of lspci -v with David's patch (4.04 KB, text/plain)
2004-06-03 07:35 UTC, Andreas Haumer
Details
Output of cat /proc/interrupts with David's patch (824 bytes, text/plain)
2004-06-03 07:37 UTC, Andreas Haumer
Details
Asus PR-DLS dmesg with David's patch (1.02 KB, text/plain)
2004-06-03 15:10 UTC, Andrew Walrond
Details
PR_DLS (last one was lspci) dmesg output with Davids patch (14.81 KB, text/plain)
2004-06-03 15:11 UTC, Andrew Walrond
Details
proposed final patch (1.81 KB, patch)
2004-06-09 21:29 UTC, Shaohua
Details | Diff

Description Andrew Walrond 2003-12-09 14:34:00 UTC
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)
Comment 1 Andrew Walrond 2003-12-09 14:36:35 UTC
Created attachment 1642 [details]
Dmesg -s40000 output
Comment 2 Andrew Walrond 2003-12-09 14:37:31 UTC
Created attachment 1643 [details]
/proc/interrupts
Comment 3 Andrew Walrond 2003-12-09 14:38:11 UTC
Created attachment 1644 [details]
acpidmp output
Comment 4 Andrew Walrond 2003-12-09 14:38:44 UTC
Created attachment 1645 [details]
dmidecode output
Comment 5 Andrew Walrond 2003-12-09 14:39:22 UTC
Created attachment 1646 [details]
kernel config file
Comment 6 Andrew Walrond 2003-12-09 14:40:27 UTC
Created attachment 1647 [details]
lspci output when booted with acpi
Comment 7 Andrew Walrond 2003-12-09 14:41:11 UTC
Created attachment 1648 [details]
lspci output when booted with pci=noacpi
Comment 8 Shaohua 2003-12-09 17:50:33 UTC
your dsdt is a little wield. bridge's bus number is incorrect in your DSDT. 
can this box run winxp? many thanks.
Comment 9 Shaohua 2003-12-09 18:45:32 UTC
Created attachment 1649 [details]
work around patch for this issue

please try this patch, thanks
Comment 10 Shaohua 2003-12-09 19:03:16 UTC
Created attachment 1650 [details]
workaround patch

please try this one.
Comment 11 Shaohua 2003-12-09 23:25:03 UTC
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.
Comment 12 Andrew Walrond 2003-12-10 00:11:42 UTC
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 
 
Comment 13 Andrew Walrond 2003-12-10 00:34:35 UTC
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? 
Comment 14 Shaohua 2003-12-10 16:59:06 UTC
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. 
Comment 15 Andrew Walrond 2003-12-11 05:48:37 UTC
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. 
Comment 16 Len Brown 2004-01-08 18:10:42 UTC
*** Bug 1127 has been marked as a duplicate of this bug. ***
Comment 17 Shaohua 2004-01-08 18:37:49 UTC
*** Bug 1741 has been marked as a duplicate of this bug. ***
Comment 18 Len Brown 2004-01-18 10:44:12 UTC
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 
 
Comment 19 Andrew Walrond 2004-01-18 11:42:26 UTC
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. 
Comment 20 Shaohua 2004-04-06 23:31:14 UTC
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.
Comment 21 Len Brown 2004-04-12 22:38:44 UTC
*** Bug 1585 has been marked as a duplicate of this bug. ***
Comment 22 Len Brown 2004-04-14 19:41:12 UTC
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
Comment 23 Shaohua 2004-04-14 22:19:45 UTC
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.
Comment 24 Len Brown 2004-04-21 22:23:36 UTC
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.
Comment 25 Nicol 2004-05-05 16:26:34 UTC
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.
Comment 26 Len Brown 2004-05-11 23:31:18 UTC
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. 
Comment 27 Len Brown 2004-05-26 13:41:00 UTC
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. 
 
Comment 28 Len Brown 2004-05-27 00:02:07 UTC
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.
Comment 29 Shaohua 2004-05-27 03:05:38 UTC
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.
Comment 30 Len Brown 2004-05-27 23:33:34 UTC
*** Bug 1674 has been marked as a duplicate of this bug. ***
Comment 31 Len Brown 2004-05-28 21:48:13 UTC
David Shaohua, 
if both patches work, i prefer yours over mine. 
 
Comment 32 Len Brown 2004-06-02 21:24:14 UTC
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. 
 
Comment 33 Andrew Walrond 2004-06-03 00:38:08 UTC
I'll test the patches today and report back 
 
Comment 34 Andreas Haumer 2004-06-03 07:18:37 UTC
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?)
Comment 35 Andreas Haumer 2004-06-03 07:32:35 UTC
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
Comment 36 Andreas Haumer 2004-06-03 07:35:27 UTC
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
Comment 37 Andreas Haumer 2004-06-03 07:37:32 UTC
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
Comment 38 Len Brown 2004-06-03 12:24:09 UTC
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. 
 
Comment 39 Andrew Walrond 2004-06-03 15:06:24 UTC
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. 
Comment 40 Andrew Walrond 2004-06-03 15:10:10 UTC
Created attachment 3058 [details]
Asus PR-DLS dmesg with David's patch
Comment 41 Andrew Walrond 2004-06-03 15:11:16 UTC
Created attachment 3059 [details]
PR_DLS (last one was lspci) dmesg output with Davids patch
Comment 42 Shaohua 2004-06-09 21:29:31 UTC
Created attachment 3124 [details]
proposed final patch

Just a small change.
Comment 43 Len Brown 2004-11-03 15:25:35 UTC
shipped in 2.4.27 and 2.6.8.1 -- closing.

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