Description Ron Murray 2006-01-08 14:02:39 UTC
Comment 1 Ron Murray 2006-01-08 14:08:25 UTC
Created attachment 6970 [details] Output of dmidecode
Comment 2 Ron Murray 2006-01-08 14:09:22 UTC
Created attachment 6971 [details] Output of acpidump
Comment 3 Luming Yu 2006-02-07 01:07:58 UTC
>>Checking 'hlt' instruction... OK. >> ACPI-0284: *** Info: Table [DSDT] replaced by host OS Please re-test without overriding DSDT.
Comment 4 Gilles PI 2006-04-02 03:10:22 UTC
I have the same problem on an Acer TravelMate 4062LMi on Ubuntu Dapper, using or not a custom DSDT. acpid log : [Sun Apr 2 11:59:56 2006] received event "button/lid LID 00000080 0000002f" [Sun Apr 2 11:59:56 2006] notifying client 4014[114:114] [Sun Apr 2 11:59:56 2006] completed event "button/lid LID 00000080 0000002f" [Sun Apr 2 11:59:56 2006] received event "button/lid LID 00000080 00000030" [Sun Apr 2 11:59:56 2006] notifying client 4014[114:114] [Sun Apr 2 11:59:56 2006] completed event "button/lid LID 00000080 00000030" [Sun Apr 2 11:59:56 2006] received event "button/lid LID 00000080 00000031" [Sun Apr 2 11:59:56 2006] notifying client 4014[114:114] [Sun Apr 2 11:59:56 2006] completed event "button/lid LID 00000080 00000031" [Sun Apr 2 11:59:58 2006] received event "button/lid LID 00000080 00000032"
Comment 5 Gilles PI 2006-04-02 03:11:39 UTC
Created attachment 7739 [details] dmesg output (Acer 4062LMi, no custom DSDT)
Comment 6 Gilles PI 2006-04-02 03:12:36 UTC
Created attachment 7740 [details] acpidump log (Acer 4062LMi, no custom DSDT)
Comment 7 Gilles PI 2006-04-02 03:13:37 UTC
Created attachment 7741 [details] lspci -v (Acer 4062LMi, no custom DSDT), probably useless
Comment 8 Gilles PI 2006-04-02 03:14:20 UTC
Created attachment 7742 [details] dmidecode output (Acer 4062LMi, no custom DSDT)
Comment 9 John Dong 2006-05-07 18:48:53 UTC
Also confirmed here, on Ubuntu Dapper + Acer Aspire 5670. When the lid is closed, /proc/acpi/event generates LID events endlessly!
Comment 10 Len Brown 2006-08-10 01:05:46 UTC
for each failing machine, please attach the complete output of dmesg -s64000 and paste /proc/interrupts. Also, please kill acpid, and verify that each button press results in a single increment to the acpi line in /proc/interrupts
Comment 11 Gilles PI 2006-08-10 15:28:28 UTC
Created attachment 8755 [details] dmesg -s6400 on a TravelMate 4062LMi
Comment 12 Gilles PI 2006-08-10 15:29:23 UTC
Created attachment 8756 [details] /proc/interrupts on TravelMate 4062LMi
Comment 13 Gilles PI 2006-08-10 15:37:35 UTC
gilles@colibri:~$ sudo killall acpid gilles@colibri:~$ cat /proc/interrupts CPU0 0: 69714450 IO-APIC-edge timer 1: 404177 IO-APIC-edge i8042 8: 14 IO-APIC-edge rtc 9: 4135157 IO-APIC-level acpi 12: 14485127 IO-APIC-edge i8042 14: 5483332 IO-APIC-edge ide0 169: 8479724 IO-APIC-level ipw2200 177: 18559512 IO-APIC-level uhci_hcd:usb4, HDA Intel, i915@pci:0000:00:02.0, eth1 185: 3490 IO-APIC-level uhci_hcd:usb3, yenta 225: 2 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5 233: 0 IO-APIC-level uhci_hcd:usb2 NMI: 0 LOC: 69714261 ERR: 0 MIS: 0 --- Closing the lid, reopening it : --- gilles@colibri:~$ cat /proc/interrupts CPU0 0: 69718173 IO-APIC-edge timer 1: 404203 IO-APIC-edge i8042 8: 14 IO-APIC-edge rtc 9: 4135663 IO-APIC-level acpi 12: 14485127 IO-APIC-edge i8042 14: 5483598 IO-APIC-edge ide0 169: 8480112 IO-APIC-level ipw2200 177: 18560210 IO-APIC-level uhci_hcd:usb4, HDA Intel, i915@pci:0000:00:02.0, eth1 185: 3490 IO-APIC-level uhci_hcd:usb3, yenta 225: 2 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5 233: 0 IO-APIC-level uhci_hcd:usb2 NMI: 0 LOC: 69717984 ERR: 0 MIS: 0 gilles@colibri:~$ Not sure what you meant by "a single increment", so I gave all the output ;)
Comment 14 Andrea Franco 2006-08-18 03:57:03 UTC
Created attachment 8825 [details] Acer Aspire 1692 WLMi DDR2 I've got the same problem with an Acer Aspire 1962
Comment 15 Andrea Franceschini 2006-08-19 13:18:55 UTC
Created attachment 8835 [details] Acer Aspire 1652 WLMi Buggy here too for bug 5853
Comment 16 R. Bosch 2006-08-24 14:35:50 UTC
Same problem with a Acer travelMate 3000 (3002WTMi) Tested both with and without custom DSDT. OS: Gentoo Linux Kernel: suspend2-sources-2.6.17-r4 Acpid: 1.0.4-r3 tried 'cat /proc/acpi/event' and run a script like this: date >> temp sleep 1s date >> temp dd if=/proc/acpi/event count=512 >> temp sleep 1s echo >> temp date >> temp dd if=/proc/acpi/event count=512 >> temp Push the button to simuate a closing lid and then release. If you used a script like above read temp. Apearently acpid can't keep up. As long as the lid-button is pressed, a counter keeps running. Is this software or harware? Acpid might need to make sure a sertain situation takes longer than a ms before asuming a stable state. In worst case, polling :( my 2 cents.
Comment 17 Stephan Dale 2006-09-04 15:17:19 UTC
Also on Acer Travelmate 8104WLMi running 2.6.17-gentoo-r4 or 2.6.17-gentoo-r9. Output of /var/log/acpid: ... [Mon Sep 4 17:32:43 2006] received event "button/lid LID 00000080 00000089" [Mon Sep 4 17:32:43 2006] completed event "button/lid LID 00000080 00000089" [Mon Sep 4 17:32:43 2006] received event "button/lid LID 00000080 0000008a" [Mon Sep 4 17:32:43 2006] completed event "button/lid LID 00000080 0000008a" [Mon Sep 4 17:32:43 2006] received event "button/lid LID 00000080 0000008b" [Mon Sep 4 17:32:43 2006] completed event "button/lid LID 00000080 0000008b" ...
Comment 18 Stephan Dale 2006-09-04 15:18:42 UTC
Created attachment 8938 [details] dmesg -s40000
Comment 19 Stephan Dale 2006-09-04 15:19:40 UTC
Created attachment 8939 [details] dmidecode
Comment 20 Stephan Dale 2006-09-04 15:20:16 UTC
Created attachment 8940 [details] lspci -vv
Comment 21 Stephan Dale 2006-09-04 15:20:44 UTC
Created attachment 8941 [details] cat /proc/interrupts
Comment 22 Stephan Dale 2006-09-04 15:23:01 UTC
Forgot to mention, I'm using acpid-1.0.4-r3. 100% CPU usage can be avoided by removing all events/actions that are triggered from the lid event. However, the "received event" and "completed event" messages are still continuously written to the logs while the lid is closed.
Comment 23 Virgil Bucoci 2006-11-18 09:59:59 UTC
Same symtomps with kernel 184.108.40.206 on Acer TravelMate 2482NWXMi. Stopping acpid has no effect as the interrupts are continously generated and the CPU load remains 100%.
Comment 24 Patrick de Pinguin 2007-01-16 02:09:33 UTC
What is the status of this bug? Is there a fix yet? We are now a year later, and I still experience the same on an Acer Aspire 5672. Thanks.
Comment 25 Jools Wills 2007-02-25 12:05:26 UTC
To confirm I also have this problem on a Acer Travelmate 8104. the LID causes repeating ACPI events. Buggy Acers :/
Comment 26 Patrick de Pinguin 2007-03-12 09:24:44 UTC
Created attachment 10720 [details] output of /var/log/acpid for an aspire 5672
Comment 27 Patrick de Pinguin 2007-03-12 09:27:38 UTC
I attached my /var/log/acpid output. This is for an Acer Aspire 5672. Is there anyone from the kernel developers actually looking into this bug, or is there any information available on this? I am using a 2.6.20 kernel and the bug is still present.
Comment 28 Patrick de Pinguin 2007-03-12 09:32:40 UTC
Created attachment 10721 [details] /proc/interrupts for aspire 5672
Comment 29 Len Brown 2007-03-13 00:47:40 UTC
All of these Acers seem to have: IOAPIC mode ACPI non-shared on IRQ9 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (though a few of the dmesg didn't go back far enough to tell) They all had a huge number of acpi interrupts even before the lid was closed. what hapens with "acpi_sci=low"? if the storm goes away, see if a single power button press results in a single increment to the acpi line in /proc/interrupts, or if we disable them all by doing this. what happens with "noapic"?
Comment 30 Patrick de Pinguin 2007-03-13 02:42:03 UTC
With acpi_pci=low, the only messages in /var/log/acpid when closing the lid, and then resuming from standby are: [Tue Mar 13 10:29:47 2007] received event "ac_adapter ACAD 00000080 00000000" [Tue Mar 13 10:29:47 2007] notifying client 4238[0:0] [Tue Mar 13 10:29:47 2007] notifying client 6403[102:441] [Tue Mar 13 10:29:47 2007] notifying client 7390[0:0] [Tue Mar 13 10:29:47 2007] client has disconnected [Tue Mar 13 10:29:47 2007] executing action "/etc/acpi/default.sh ac_adapter ACAD 00000080 00000000" [Tue Mar 13 10:29:47 2007] BEGIN HANDLER MESSAGES [Tue Mar 13 10:29:47 2007] END HANDLER MESSAGES [Tue Mar 13 10:29:47 2007] action exited with status 0 [Tue Mar 13 10:29:47 2007] executing action "/etc/acpi/ati-powermode.sh" [Tue Mar 13 10:29:47 2007] BEGIN HANDLER MESSAGES Lid Open This seems normal (however, there seems to be no event about closing the lid...). The bootup with this kernel parameter went more slowly, and during the beginning I saw a message about a PCI Quirk, which caused the boot process to sit there for a while. I cannot find this in a log. I will try to write it down next time. For the "acpi line" in /proc/interrupts, I suppose you mean this line, right? 9: 16828 91 IO-APIC-fasteoi acpi (two CPU's). When pressing the power button, none of these two numbers increases. (Note that you should using AC while doing this test, because otherwise the count gets increased all the time due to battery events). I will try noapic later today. Let me know if you need more info.
Comment 31 Patrick de Pinguin 2007-03-13 04:30:57 UTC
After a second thought, the pci quirk message was there before as well. It was just more apparent now since the boot paused on that screen. While going on standby worked with acpi_sci=low, it crashed my computer with noapic. Therefore I could not check the acpi messages. Is anyone else experiencing the same? Has this information helped you in any way? Thanks for looking into this, Thomas
Comment 32 Len Brown 2007-03-13 22:49:08 UTC
yes, acpi_irq=low is not intended to be used with "noapic" -- just use "noapic" all by itself.
Comment 33 Felix Bechstein 2007-06-06 02:54:50 UTC
booting with noapic changes nothing on my Acer TravelMate 3022 WTMi. booting with acpi_sci=low does: 1. booting is very slow 2. pressing the lid button does not make any interrupt 3. pressing other acpi button does not make any interrupt 4. kde hangs during battery-check-update so. its unusable for me.
Comment 34 Jools Wills 2007-07-07 03:28:21 UTC
What can we do to progress this further ?
Comment 35 Juho-Mikko Pellinen 2007-07-11 05:15:13 UTC
I have had this on my computer ( Acer Travelmate 4041Wlmi ) also for the whole time I have had it. This is not critical, but irritating when someone accidentally closes the lid. I wish I could do something for this, because otherwise my computer is supported perfectly in Linux.
Comment 36 Juho-Mikko Pellinen 2007-07-11 05:22:48 UTC
Created attachment 11999 [details] dmesg, interrupts and grub kernel boot-line in single file Ok. Here is my dmesg, /proc/interrupts and kernel boot-line.
Comment 37 Fu Michael 2007-09-19 01:24:56 UTC
bug reviewed. Rui to write a debug patch for GPE cleanup to see if it works..
Comment 38 Zhang Rui 2007-09-20 00:22:43 UTC
Hi, Please try: echo 0x04 >/sys/module/acpi/parameters/debug_layer echo 0xffffffff > /sys/module/acpi/paramters/debug_level dmesg -c close the lid for a few seconds and attach the dmesg output.
Comment 39 Felix Bechstein 2007-09-20 01:00:05 UTC
Created attachment 12875 [details] dmesg -c after closing lid for a few seconds (debug on)
Comment 40 Shaohua 2007-09-20 02:20:16 UTC
Flelix, can you post your acpidump? your dmesg doesn't match with previous acpidump.
Comment 41 Zhang Rui 2007-09-20 02:44:05 UTC
Created attachment 12876 [details] debug patch Hi,Felix, First please attach the acpidump output as Shaohua said, and then please apply this debug patch and do the same test again. you can echo 0x8800001f >/sys/module/acpi/parameters/debug_level instead of 0xffffffff.
Comment 42 Felix Bechstein 2007-09-20 02:44:37 UTC
Created attachment 12877 [details] acpidump from acer travelmate 3022 wtmi
Comment 43 Felix Bechstein 2007-09-20 04:09:51 UTC
Created attachment 12878 [details] dmesg -c after closing lid for a few seconds (debug on, patched)
Comment 44 Zhang Rui 2007-09-21 00:31:46 UTC
Hmm, it seems that we keep on receiving ec GPE events. could you please boot with ec_intr=0?
Comment 45 Felix Bechstein 2007-09-23 23:09:22 UTC
Created attachment 12913 [details] dmesg -c after closing lid for a few seconds (debug on, patched, ec_intr=0)
Comment 46 Zhang Rui 2007-09-26 23:01:24 UTC
Hi, Felix, Thanks for you information. Nothing interesting so far. :( Please make sure the ACPI button driver is compiled and loaded as there is no notify handler for lid events from your dmesg output. This is probably an ec related issue, add Alexey in the loop. :)
Comment 47 Felix Bechstein 2007-09-27 22:16:17 UTC
Created attachment 12975 [details] same as before but with button loaded i didn't load button to get rid of acpid log spam :x
Comment 48 Zhang Rui 2007-11-05 18:50:42 UTC
Created attachment 13409 [details] disable ec gpe while executing ec gpe handler This patch disables the ec gpe while handling the ec events. Please try this patch.
Comment 49 Felix Bechstein 2007-11-05 23:17:20 UTC
i can't compile: CC drivers/acpi/ec.o drivers/acpi/ec.c: In function ‘acpi_ec_gpe_handler’: drivers/acpi/ec.c:485: error: ‘struct acpi_ec’ has no member named ‘common’ drivers/acpi/ec.c:497: error: ‘struct acpi_ec’ has no member named ‘common’ kernel is patched with latest gentoo, tuxonice patches and the two patches from above.
Comment 50 Zhang Rui 2007-11-05 23:26:05 UTC
Created attachment 13411 [details] patch: disable ec gpe while handling ec events Oops, that one is quite old, please try this one. :)
Comment 51 Felix Bechstein 2007-11-06 00:05:20 UTC
Created attachment 13412 [details] dmesg -c after closing lid for a few seconds (debug on, patched, ec_intr=0, button loaded)
Comment 52 Felix Bechstein 2007-11-06 00:08:59 UTC
with this patch the acpid got 2-3 events for closing the lid, and 2-3 for opening it again. but this might be a hardware problem.
Comment 53 Zhang Rui 2007-11-06 00:09:54 UTC
is there any difference if you remove the boot option "ec_intr=0"?
Comment 54 Felix Bechstein 2007-11-06 00:33:49 UTC
no difference in acpid's output. it still receives 3 events for each action.
Comment 55 Zhang Rui 2007-11-06 00:44:55 UTC
>with this patch the acpid got 2-3 events for closing the lid is this different without the patch in comment#50 applied? hmmm, could you please send the dmesg after closing lid for a few seconds (debug on, patched, button loaded)? and please attach the acpid log as well, both with and without the patch in comment#50 if they are different.
Comment 56 Felix Bechstein 2007-11-06 01:52:36 UTC
Created attachment 13418 [details] acpid's log after closing lid for a few seconds (debug on, patched, button loaded)
Comment 57 Felix Bechstein 2007-11-06 01:53:08 UTC
Created attachment 13419 [details] dmesg -c after closing lid for a few seconds (debug on, patched, button loaded)
Comment 58 Felix Bechstein 2007-11-06 02:21:18 UTC
Created attachment 13420 [details] acpid's log after closing lid for a few seconds (debug on, button loaded)
Comment 59 Felix Bechstein 2007-11-06 02:22:18 UTC
Created attachment 13421 [details] dmesg -c after closing lid for a few seconds (debug on, button loaded)
Comment 60 ykzhao 2007-12-18 22:36:54 UTC
Hi, Felix please check if there is any BIOS update for your laptop.
Comment 61 Felix Bechstein 2007-12-18 23:13:31 UTC
i did an update 1 or 2 month ago. (there is no new one) i am not sure why, but everything seems to be ok now. i can close the lid without interrupt storm. it seems to be fired only trice.
Comment 62 Zhang Rui 2007-12-18 23:23:03 UTC
Hmm, good news to me. :) I'll close this bug and mark it as UNREPRODUCIBLE. Please reopen it if the interrupt storm occurs again.
Comment 63 Jools Wills 2007-12-20 09:46:06 UTC
I still have this problem, despite upgrading the bios to the latest version a few weeks ago. My laptop is a travelmate 8104. As soon as I press the lid button, I get constant acpi interrupts.
Comment 64 ykzhao 2007-12-20 16:55:38 UTC
Hi, Jool Will you please open a new bug about your laptop? Please attach the output of dmesg , lspci -vvxxx and acpidump. Thanks.
Comment 65 Zhang Rui 2007-12-20 17:13:14 UTC
Jools, please open another bug and attach all the debug information there, include the dmesg, lspci -vvxxx, acpidump and do the following test: echo 0x04 >/sys/module/acpi/parameters/debug_layer echo 0x8800001f > /sys/module/acpi/paramters/debug_level dmesg -c close the lid for a few seconds and attach the dmesg output.
Comment 66 Christoph Kindl 2008-03-18 16:00:11 UTC
Hi, I had exactly the same problem with my Acer Aspire 1694WLMi (with acpid and laptop-mode-tools installed on my ARCH Linux). This was caused by the laptop-mode-tools, which installed some events files and action scripts under /etc/acpi/events and /etc/acpi/actions for the acpid. These scripts or the event files caused some kind of feedback, they were started again and again. I removed these scripts and the problem was gone. Maybe your problem is also caused by any action script for acpid..
Comment 67 Jools Wills 2008-04-19 07:53:03 UTC
Whether or not the acpid is running, the acpi events are triggered/interrupts created. stop acpid and run "sudo cat /proc/acpi/event" and close the lid/press the lid button for a few seconds and you will see multiple lines of output whereas it should be one event for lid closed and one for lid open (not continuous events)
Comment 68 Jools Wills 2008-04-19 07:53:37 UTC
I have opened a new bug as suggested for my laptop model here http://bugzilla.kernel.org/show_bug.cgi?id=10485