Bug 1985 - pci=noacpi needed for PIC mode -- Dell Inspiron 5150
Summary: pci=noacpi needed for PIC mode -- Dell Inspiron 5150
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-31 14:03 UTC by Jason Bouzane
Modified: 2007-03-05 17:13 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.1
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
test dmi_scan patch to disable lapic blacklist when IOAPIC (446 bytes, patch)
2004-04-23 22:01 UTC, Len Brown
Details | Diff
dmesg output without the IOAPIC patch (14.58 KB, text/plain)
2004-05-01 21:17 UTC, Jason Bouzane
Details

Description Jason Bouzane 2004-01-31 14:03:07 UTC
Distribution: Mandrake 9.2 
Hardware Environment: Dell Inspiron 5150 (Laptop) 
Software Environment: 
Problem Description: pci=noacpi required to use pci devices 
 
Steps to reproduce: 
 
I have a Dell Inspiron 5150 and when I boot it under 2.6 with ACPI enabled, 
I can't use some of the devices in my laptop. If pass pci=noacpi to the  
kernel on boot, everything works fine but all the IRQs are routed through  
the PIC rather than the APIC. This isn't a problem for me and I'm quite  
happy with things as they are, but I thought I should notify the proper  
authorities, so to speak. 
 
OK, so here's longer description. I'm using 2.6.1 and the laptop has Intel  
bridges pretty much everywhere. Here's the output from lspci under 2.6.1  
with pci=noacpi: 
 
00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) 
00:00.1 System peripheral: Intel Corp.: Unknown device 3584 (rev 02) 
00:00.3 System peripheral: Intel Corp.: Unknown device 3585 (rev 02) 
00:01.0 PCI bridge: Intel Corp.: Unknown device 3581 (rev 02) 
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 01) 
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 01) 
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01) 
00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 01) 
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81) 
00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) 
00:1f.1 IDE interface: Intel Corp. 82801DBM Ultra ATA Storage Controller (rev 
01) 
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio Controller 
(rev 01) 
00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem Controller (rev 01) 
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0324 (rev 
a1) 
02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) 
02:04.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller 
(rev 02) 
02:04.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller 
 
The processor is a Mobile Pentium 4 3.06,  
 
Every device in the list is mapped to IRQ 11. 
 
When I boot without the pci=noacpi flag, the Broadcom 4401 network card will 
not acquire a dhcp address using dhclient or dhcpcd with the experimental 
b44 driver or the Broadcom provided bcm4400 driver. ifconfig claims that 
packets have been sent and that the card is configured on IRQ 17. 
 
Also, my usb mouse doesn't work and neither does my sound card, even though, 
like the network card, the drivers are loaded and are bound to the proper 
devices. 
 
At this point, I would like to stress that when I tried this I had no modules  
loaded. Everything I need is built into the kernel. However, later, I tried 
loading the binary only nvidia driver (yes, I know), and that failed too 
(but works fine with pci=noacpi). I know you probably don't care about 
binary only kernel modules, but I thought it might be a helpful data point 
nonetheless. 
 
There are also some interesting notes in the dmesg boot log about the APIC 
controller on this laptop. Here are the entries: 
 
With pci=noacpi: 
 
Dell Inspiron with broken BIOS detected. Refusing to enable the local APIC. 
ACPI: RSDP (v000 DELL                                      ) @ 0x000fdea0 
ACPI: RSDT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000061) @ 0x1fff0000 
ACPI: FADT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000061) @ 0x1fff0400 
ACPI: MADT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000047) @ 0x1fff0c00 
ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000 
ACPI: Local APIC address 0xfee00000 
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) 
Processor #0 15:2 APIC version 20 
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) 
ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x1] lint[0x1]) 
ACPI: LAPIC_NMI (acpi_id[0x01] polarity[0x1] trigger[0x1] lint[0x1]) 
[1] 
... 
[2] 
ACPI: Subsystem revision 20031002 
ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd 
ACPI: Interpreter enabled 
ACPI: Using PIC for interrupt routing 
ACPI: PCI Root Bridge [PCI0] (00:00) 
PCI: Probing PCI hardware (bus 00) 
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 
[3] 
... 
[4] 
... 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) 
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) 
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) 
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) 
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) 
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] 
... 
[5] 
PCI: Probing PCI hardware 
PCI: Discovered primary peer bus 08 [IRQ] 
PCI: Using IRQ router PIIX/ICH [8086/24cc] at 0000:00:1f.0 
PCI: IRQ 0 for device 0000:00:1f.1 doesn't match PIRQ mask - try 
pci=usepirqmask 
PCI: Found IRQ 11 for device 0000:00:1f.1 
PCI: Sharing IRQ 11 with 0000:00:1d.2 
PCI: IRQ 0 for device 0000:02:04.0 doesn't match PIRQ mask - try 
pci=usepirqmask 
PCI: Found IRQ 11 for device 0000:02:04.0 
PCI: Sharing IRQ 11 with 0000:00:1d.0 
PCI: Sharing IRQ 11 with 0000:02:04.1 
[6] 
 
Without pci=noacpi: 
 
Where the [1] is in the noacpi, there is: 
 
ACPI: IOAPIC (id[0x01] address[0xfec00000] global_irq_base[0x0]) 
IOAPIC[0]: Assigned apic_id 1 
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, IRQ 0-23 
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0]) 
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3]) 
Enabling APIC mode:  Flat.  Using 1 I/O APICs 
Using ACPI (MADT) for SMP configuration information 
 
The second piece between [2] and [3] is different: 
 
ACPI: Subsystem revision 20031002 
IOAPIC[0]: Invalid reference to IRQ 0 
ACPI: Interpreter enabled 
ACPI: Using IOAPIC for interrupt routing 
ACPI: PCI Root Bridge [PCI0] (00:00) 
PCI: Probing PCI hardware (bus 00) 
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 
Transparent bridge - 0000:00:1e.0 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) 
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) 
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) 
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) 
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) 
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] 
 
At [4], there is: 
 
BIOS bug, local APIC #0 not detected!... 
 
And between [5] and [6], this appears: 
 
IOAPIC[0]: Set PCI routing entry (1-16 -> 0x39 -> IRQ 16 Mode:1 Active:1) 
00:00:1f[A] -> 1-16 -> IRQ 16 
IOAPIC[0]: Set PCI routing entry (1-17 -> 0x41 -> IRQ 17 Mode:1 Active:1) 
00:00:1f[B] -> 1-17 -> IRQ 17 
IOAPIC[0]: Set PCI routing entry (1-18 -> 0x49 -> IRQ 18 Mode:1 Active:1) 
00:00:1f[C] -> 1-18 -> IRQ 18 
IOAPIC[0]: Set PCI routing entry (1-19 -> 0x51 -> IRQ 19 Mode:1 Active:1) 
00:00:1f[D] -> 1-19 -> IRQ 19 
Pin 1-16 already programmed 
Pin 1-19 already programmed 
Pin 1-18 already programmed 
IOAPIC[0]: Set PCI routing entry (1-23 -> 0x59 -> IRQ 23 Mode:1 Active:1) 
00:00:1d[D] -> 1-23 -> IRQ 23 
Pin 1-16 already programmed 
Pin 1-17 already programmed 
IOAPIC[0]: Set PCI routing entry (1-20 -> 0x61 -> IRQ 20 Mode:1 Active:1) 
00:01:00[A] -> 1-20 -> IRQ 20 
Pin 1-16 already programmed 
Pin 1-16 already programmed 
Pin 1-18 already programmed 
Pin 1-19 already programmed 
Pin 1-17 already programmed 
PCI: Using ACPI for IRQ routing 
PCI: if you experience problems, try using option 'pci=noacpi' or even 
'acpi=off' 
 
Except for these differences, the files are pretty much identical except  
for IRQ numbering, which is between 16-23 for all devices on the PCI bus.  
This IRQ layout exactly matches that which windows uses, device per device. 
 
Finally, and perhaps this is the most useful piece of information, I ran a 
test where I added a printk line to the interrupt handler of the b44 driver 
and found that it never fires unless pci=noacpi is set.
Comment 1 Jason Bouzane 2004-02-02 21:22:29 UTC
Apologies for the original categorization of the bug. I misinterpreted the 
category/component to be the type of interaction with ACPI. :( 
 
Anyway, another thing to add to this is that the APIC controller seems to work 
properly under 2.4.22 with ACPI enabled. 
Comment 2 Jason Bouzane 2004-03-04 16:38:40 UTC
I did some more testing and I found out some interesting information, and I 
actually have it working now on 2.6.3. 
 
The problem arises from the Dell Inspiron's DMI being blacklisted, which causes 
the APIC controller to be disabled by the local_apic_kills_bios function in 
dmi_scan.c in /arch/i386/kernel. 
 
I originally found this by setting the enable_local_apic variable (in 
/arch/i386/kernel/apic.c) to 1, which bypassed the blacklisting. This seems to 
work alright on my computer so far, and sleeping is no less broken than before. 
I have the same sleep problem as reported in another bug with the i8042 
controller complaining about keylock being active on wakeup. However, this 
happens with and without the APIC controller enabled. 
Comment 3 Len Brown 2004-04-12 23:49:44 UTC
There are two problems here. 
 
1. DMI blacklist for older Dells disables your LAPIC, which disables your IOAPIC. 
You can re-enable it by booting with "lapic", which will bypass the blacklist. 
Perhaps we should have the blacklist disable LAPIC only when IOAPIC 
is not present... 
 
2. pci=noacpi required in PIC mode. 
Even though IOAPIC mode is preferred, this should still work, and 
is interesting because various distro install kernels are PIC-mode only. 
Can you test 2.6.5 and attach the full dmesg and /proc/interrupts? 
The cardbus bridge fix in that release may help here. 
 
 
 
Comment 4 Jason Bouzane 2004-04-13 15:53:34 UTC
As for problem one, perhaps it's enough to add model numbers to the Inspiron 
blacklist? IIRC, the one that is responsible for killing the LAPIC was a 
general one that matched all Inspirons. 
 
Problem two, I never really thought about, but it is a good point. I probably 
won't have time to rebuild the kernel for a couple of days. However, I tested 
this (by accident) on the last release candidate of 2.6.4 (rc3?), and it was 
still broken. 
Comment 5 Len Brown 2004-04-23 22:01:34 UTC
Created attachment 2680 [details]
test dmi_scan patch to disable lapic blacklist when IOAPIC

please test that the attached patch causes your laptop
to come up in IOAPIC mode w/o requiring "lapic" on the cmdline.
Comment 6 Jason Bouzane 2004-05-01 21:16:22 UTC
First, sorry for not replying in so long. I've been away for a while. 
 
Second, the patch doesn't work because you check for the IOAPIC before it is 
detected. What I mean is the call to dmi_scan_machine() happens before the 
call to acpi_boot_init(), so the check in the patch is always false. 
 
Third, I can confirm that it still requires pci=noacpi in 2.6.5. 
 
Fourth, I've got the dmesg output. I'll get you the /proc/interrupts tomorrow, 
but I can tell you that there will be no ACPI interrupts as they aren't 
received on the 5150 (see bug 1752). 
Comment 7 Jason Bouzane 2004-05-01 21:17:53 UTC
Created attachment 2768 [details]
dmesg output without the IOAPIC patch
Comment 8 Len Brown 2004-05-12 22:58:56 UTC
thanks for debugging my bad debug patch. 
 
To recap, when you disabled the dmi_scan entry or booted with 
"lapic", the system came up in IOAPIC mode and everything works, yes? 
 
So we're looking at why PIC mode doesn't work -- which is what the 
system boots into if the dmi_scan entry is left intact. 
 
Does the dmesg attached refer to that (default) configuration? 
 
unfortunately the dmesg doesn't go back far enough. 
please try dmesg -s64000, and if that doesn't go back to the start 
then re-build with, say CONFIG_LOG_BUF_SHIFT=16 
 
I think what is going on here is that this machine may be the only one that 
gets nolapic in dmi_scan, but also has an IOAPIC.  Looks like the "nolapic" 
in dmi_scan isn't exactly the same as booting "nolapic". 
Also, it appears that the ACPI IOAPIC parsing code honors "noapic", 
but doesn't know to skip IOAPIC parsing upon "nolapic". 
 
Please compare 
A. default boot (with full dmesg) 
B. boot with explicit "nolapic". 
C. boot with explicit "lapic noapic" 
 
thanks, 
-Len 
 
Comment 9 Len Brown 2004-11-04 01:59:30 UTC
the dmi-scan entry is gone in 2.6.9,
please verify that the system comes up in IOAPIC
mode without any cmdline parameters and works properly.

Then please test the PIC mode by booting with "noapic"
Note that PIC mode is still important, because some kernels
such as Red Hat's installer kernel don't have IOAPIC support.
Comment 10 Len Brown 2004-11-14 20:32:08 UTC
any luck with 2.6.9? 
Comment 11 Jason Bouzane 2004-12-30 01:28:45 UTC
Sorry about the wait. I was really busy up until Christmas, and didn't get home
until late.

Anyway, it works perfectly with 2.6.9 and 2.6.10. Thanks a lot. I can now start
with no kernel parameters and everything is detected perfectly. Interrupts are
as follows:

           CPU0
  0:  139245827    IO-APIC-edge  timer
  1:     114525    IO-APIC-edge  i8042
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:      72461    IO-APIC-edge  i8042
 14:        164    IO-APIC-edge  ide0
 15:     933560    IO-APIC-edge  ide1
169:     438843   IO-APIC-level  Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, eth0
177:          0   IO-APIC-level  eth1, uhci_hcd
185:    1038649   IO-APIC-level  ohci1394, uhci_hcd
193:        320   IO-APIC-level  ehci_hcd
201:    1933024   IO-APIC-level  uhci_hcd
209:    8526121   IO-APIC-level  nvidia
NMI:          0
LOC:  137489012
ERR:          0
MIS:          0

With the following command line:

# dmesg | grep -i command
Kernel command line: BOOT_IMAGE=2_6_10 ro root=1605
Comment 12 Len Brown 2005-01-30 23:27:49 UTC
With 2.6.11-rc2 "nolapic noapic" boot hangs on a 5150 w/ BIOS A38 
Comment 13 Jason Bouzane 2005-02-13 19:57:11 UTC
I haven't tried this configuration in a very long time. I will try it on 2.6.11
when it is finally released. However, is this a problem? The default boot
configuration works perfectly (I've currently got a 15 day uptime on my laptop
with a 2.6.10 kernel).

If you want me to investigate, I can try this out on several kernels and try to
figure out when it broke.
Comment 14 Adrian Bunk 2007-01-24 06:00:51 UTC
Jason, what is the status of this bug in recent kernels?
Comment 15 Adrian Bunk 2007-03-05 17:13:43 UTC
Please reopen this bug if it's still present with kernel 2.6.20.

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