Bug 1985
| Summary: | pci=noacpi needed for PIC mode -- Dell Inspiron 5150 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Jason Bouzane (jabouzane) |
| Component: | Config-Interrupts | Assignee: | Len Brown (lenb) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | acpi-bugzilla, bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
test dmi_scan patch to disable lapic blacklist when IOAPIC
dmesg output without the IOAPIC patch |
||
|
Description
Jason Bouzane
2004-01-31 14:03:07 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. 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. |