Kernel Bug Tracker – Bug 1026
ACPI and Local APIC don't work together on Presario 2540EA
Last modified: 2004-08-13 19:39:06 UTC
Hardware Environment: Compaq Presario 2540EA (lspci appended)
Software Environment: Gentoo Linux x86
Problem Description: If I boot with APIC and ACPI, computer freezes after
printing ACPI version. If I boot appending acpi=off, the computer boots (dmesg
appended). If I deselect apic, and boot, the computer also boots.
Steps to reproduce:
.config and dmesg appended
Created attachment 604 [details]
lspci -v of my computer
Created attachment 605 [details]
grep -v "^#" of the .config with APIC and ACPI that doesn't boot
Created attachment 606 [details]
Dmesg of the above config appendinf acpi=off
Created attachment 607 [details]
Config with noapic
Created attachment 608 [details]
Dmesg of the config with no apic(607)
Please attach acpidmp. Thanks a lot!
Created attachment 874 [details]
output of acpidmp
OK. As for linux-2.6.0-test5, I get:
Sep 11 18:53:06 isene kernel: No local APIC present or hardware disabled
with both ACPI and APIC on. So it seems it works for me.
> No local APIC present or hardware disabled
Can you attach the full dmesg and /proc/interrupts of a recent kernel booted w/ no cmdline flags?
This is behaving as if your system is (now) DMI blacklisted to set "nolapic".
If you attach the output from dmidecode, that would tell us.
Or perhaps the lapic enable code
knows something about your system it didn't know in the past.
Probably if you use cmdline option "lapic", it will over-ride this and
you can see if the system still fails with the LAPIC enabled.
The dmesg for acpi=off case were full of errors, so it might be that enabling
the LAPIC on this box is simply a bad idea, and if ACPI is enabled it gets worse.
dmesg with acpi enabled, show an issue too:
> ACPI: No IRQ known for interrupt pin A of device 0000:00:10.0
This device is IDE
> 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa)
which the AML shows is on LNK5. But ide0 seems to find itself
on irq14 correctly anyway. Unclear why LNK5 fails.
Please verify that you're running the latest BIOS on the system.
>Can you attach the full dmesg and /proc/interrupts of a recent kernel booted
>w/ no cmdline flags?
Attached. Also attached config.gz.
I've discovered a few "sleeping function" in test9 that used not to appear.
Maybe should I post to LKML?
>If you attach the output from dmidecode, that would tell us.
>Probably if you use cmdline option "lapic", it will over-ride this and
>you can see if the system still fails with the LAPIC enabled.
Yes. With lapic in cmdline, it freezes at boot. Last lines are
ACPI: Subsystem revision 20031002
ACPI:IRQ 9 was Edge TRiggered, setting to Level Triggered
>dmesg with acpi enabled, show an issue too:
>> ACPI: No IRQ known for interrupt pin A of device 0000:00:10.0
>This device is IDE
>> 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa)
>which the AML shows is on LNK5. But ide0 seems to find itself
>on irq14 correctly anyway. Unclear why LNK5 fails.
Yes. I saw the message, and I was considering to fill a bug. But as IDE works,
and google on similar problems doesn't conclude anything, I thought it wasn't
important. Now I see it is.
>Please verify that you're running the latest BIOS on the system.
I promise to not buy another Compaq if they fail to provide a BIOS update that
not requires, not even MS-DOS, but WindowsXP: Updating the BIOS have been a bit
changelling. BIOS Version is now KH.F.13
Created attachment 1446 [details]
Dmesg with linux-2.6-test9
Created attachment 1447 [details]
/proc/interrupts of test9
Created attachment 1448 [details]
/proc/config.gz of test9
Created attachment 1449 [details]
I don't know if it's OK. If you need anything else, please say it.
With linux-2.6-test10, more or less the same problems (no apic or hardware
disabled and No IRQ known, but not sleeping function).
If you need, just ask.
The default for cpu family 15 (P4) changed from enabling lapic by default,
to requiring the "lapic" command line option:
static int __init detect_init_APIC (void)
if (boot_cpu_data.x86 == 6 ||
- boot_cpu_data.x86 == 15 ||
+ (boot_cpu_data.x86 == 15 && (cpu_has_apic || enable_local_apic > 0)) ||
(boot_cpu_data.x86 == 5 && cpu_has_apic))
So that explains why the change in default behaviour.
This default is independent of ACPI.
So I guess the question is why the LAPIC works with acpi=off,
but doesn't work with ACPI enabled, yes?
Can you verify that the latest 2.6.0 with "acpi=off" and "lapic" works okay?
Can you attach the dmesg and /proc/interrupts from that experiment?
Do ACPI events, such as power button, work in that configuration?
> With lapic in cmdline, it freezes at boot. Last lines are
> ACPI: Subsystem revision 20031002
> ACPI:IRQ 9 was Edge TRiggered, setting to Level Triggered
Please apply the following patch to the latest 2.6.0:
and boot with cmdline options "lapic" and "acpi_pic_sci=edge" to see if perhaps
we're having trouble because of the ELCR access for IRQ9. If it works, please
test ACPI events and attach dmesg and /proc/interrupts.
If it fails, please report where, and then boot the same kernel with "nolapic"
and attach the dmesg -- as some of the failures we saw in your -test9 dmesg
output should be gone now.
Re: IDE interrupt. I've seen this on several systems, and I'm not worrying about it now
since in all cases I've seen IDE works.
Is this identical to
Both have similar symptoms. 1774 is now resolved, it seems.
Quick test yesterday:
http://bugzilla.kernel.org/attachment.cgi?id=1927&action=view and lapic in
cmdline on top of linux 2.6.1 + acpi-20031203-2.6.1.diff.gz boots apparentely
1.-Didn't see /proc/interrupts. Don't know if it's OK
2.-Compiling says something like "Warning: Implicit declaration of function..."
3.-From what I remember, IDE problem seemed to still be present. If it's true
I'll fill another bug.
4.-Didn't test another problem I had been seeing, while booting with batteries.
If the problem is still present, I'll fill another bug.
I hope to make confirmation and give details this weekend.
Thanks Gonzalo for verifying the fix in bug 1269 fixes addresses the problem.
closing as a duplicate.
*** This bug has been marked as a duplicate of 1269 ***