Most recent kernel where this bug did *NOT* occur: Distribution: Ubuntu 7.04 development packages Hardware Environment: Model: HP dv1240us 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:06.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) 01:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller 01:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller 01:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller 01:09.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller Software Environment: Problem Description: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message "The machine will now halt" the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. Steps to reproduce: Notice that the unplugged laptop power applet shows that the machine has AC power. Try closing lid to trigger a suspend. Suspend from the Quit menu. Unsuspend by pressing the laptop lid button and releasing. Shutdown the machine, noticing that the power doesn't turn off after halt.
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.