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.
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.
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.
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.
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.
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.
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).
Created attachment 2768 [details] dmesg output without the IOAPIC patch
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
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.
any luck with 2.6.9?
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
With 2.6.11-rc2 "nolapic noapic" boot hangs on a 5150 w/ BIOS A38
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.
Jason, what is the status of this bug in recent kernels?
Please reopen this bug if it's still present with kernel 2.6.20.