Bug 8283
Summary: | Duplicate MADT: no ACPI events if 2nd MADT used - HP dv1240us | ||
---|---|---|---|
Product: | ACPI | Reporter: | Miles Lane (miles.lane) |
Component: | Config-Tables | Assignee: | Len Brown (lenb) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, bunk |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.21-rc2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump output
lspci -vv output .config file dmesg messages from suspend/resume sctivity patch vs 2.6.21-rc5 to revert back to parsing 1st MADT |
Description
Miles Lane
2007-03-29 13:24:44 UTC
Created attachment 10990 [details]
acpidump output
Created attachment 10991 [details]
lspci -vv output
Hmm. I just reproduced these problems with vailla 2.6.21-rc5. I'll attach my .config file. I am now preparing to check 2.6.21-rc4. Sorry I missed this earlier in my previous 2.6.21-rc5 builds. It may be that I changed my configuration and that this is why I didn't see it before. Created attachment 10996 [details]
.config file
This is my .config file after being run through "make oldconfig" for
2.6.21-rc4.
Created attachment 10997 [details]
dmesg messages from suspend/resume sctivity
Here are the messages generated while suspending and resuming 2.6.21-rc4.
I have reproduced all the problems with 2.6.21-rc4. Hmm. Now I'll try
2.6.21-rc3. :-(
please reproduce with CONFIG_NO_HZ=n So far, Ihave managed to reproduce this all the way back to 2.6.21-rc2. I can only assume that I stumbled onto a new configuration that surfaces the problems. Anyhow, I am currently building with CONFIG_NO_HZ=n and the tree set back to 2.6.21-rc5-mm2. I'll report when finished. The problems still are there with CONFIG_NO_HZ=n Is this issue also present with kernel 2.6.20? The BIOS on this machine erroneously supplies two ACPI tables. This BIOS bug has been seen before, but on other systems using the 2nd table worked better than using the 1st. But on this system, the 2nd table is missing the ACPI SCI interrupt overrides, which is why you get zero ACPI interrupts. > cat MADT1.txt ACPI: APIC (v001 HP 09B8 0x06040000 PTL 0x00000050) @ 0x(nil) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: IOAPIC (id[0x01] address[0xfec00000] global_irq_base[0x0]) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Length 90 OK Checksum OK > cat MADT2.txt ACPI: APIC (v001 HP 09B8 0x06040000 PTL 0x00000000) @ 0x(nil) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: IOAPIC (id[0x01] address[0xfec00000] global_irq_base[0x0]) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Length 70 OK Created attachment 11000 [details]
patch vs 2.6.21-rc5 to revert back to parsing 1st MADT
Please verify that booting with "acpi_apic_instance=0"
fixes this issue.
Please verify that applying the attached patch and
using no cmdline parameters also fixes this issue.
It would also be a good sanity check to know if Windows
on this box is able to service ACPI events such as the
power button, as it would be hard proof that Windows doesn't
use the 2nd MADT, and neither should Linux.
Yes, booting with "acpi_apic_instance=0" fixed the problems. Likewise, you patch fixed the problems. I testing Windows XP Home (SP2) and found that it works perfectly. In fact, there are two outstanding issues with ACPI power management. I'll open a separate bug report for them. Just to give you a preview: 1. After a suspend, touching the synaptics mousepad does not wake the laptop up. This works as expected under Windows XP. 2. Only every other suspend attempt works. That is, after booting, the first time I close the lid, the machine suspends. The second time it fails. The third time it works and so on. Under Windows XP, every suspend attempt works. Thanks for the fix with the "two copies of the ACPI table" problem! patch in comment #11 is now in Linus' tree -- after 2.6.21-rc5-git6, so it should appear in 2.6.21-rc5-git7. |