Bug 5853
Description
Ron Murray
2006-01-08 14:02:39 UTC
Created attachment 6970 [details]
Output of dmidecode
Created attachment 6971 [details]
Output of acpidump
>>Checking 'hlt' instruction... OK.
>> ACPI-0284: *** Info: Table [DSDT] replaced by host OS
Please re-test without overriding DSDT.
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" Created attachment 7739 [details]
dmesg output (Acer 4062LMi, no custom DSDT)
Created attachment 7740 [details]
acpidump log (Acer 4062LMi, no custom DSDT)
Created attachment 7741 [details]
lspci -v (Acer 4062LMi, no custom DSDT), probably useless
Created attachment 7742 [details]
dmidecode output (Acer 4062LMi, no custom DSDT)
Also confirmed here, on Ubuntu Dapper + Acer Aspire 5670. When the lid is closed, /proc/acpi/event generates LID events endlessly! 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 Created attachment 8755 [details]
dmesg -s6400 on a TravelMate 4062LMi
Created attachment 8756 [details]
/proc/interrupts on TravelMate 4062LMi
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 ;) Created attachment 8825 [details]
Acer Aspire 1692 WLMi DDR2
I've got the same problem with an Acer Aspire 1962
Created attachment 8835 [details] Acer Aspire 1652 WLMi Buggy here too for bug 5853 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. 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" ... Created attachment 8938 [details]
dmesg -s40000
Created attachment 8939 [details]
dmidecode
Created attachment 8940 [details]
lspci -vv
Created attachment 8941 [details]
cat /proc/interrupts
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. Same symtomps with kernel 2.6.18.2 on Acer TravelMate 2482NWXMi. Stopping acpid has no effect as the interrupts are continously generated and the CPU load remains 100%. 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. To confirm I also have this problem on a Acer Travelmate 8104. the LID causes repeating ACPI events. Buggy Acers :/ Created attachment 10720 [details]
output of /var/log/acpid for an aspire 5672
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. Created attachment 10721 [details]
/proc/interrupts for aspire 5672
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"? 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. 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 yes, acpi_irq=low is not intended to be used with "noapic" -- just use "noapic" all by itself. 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. What can we do to progress this further ? 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. 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.
bug reviewed. Rui to write a debug patch for GPE cleanup to see if it works.. 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. Created attachment 12875 [details]
dmesg -c after closing lid for a few seconds (debug on)
Flelix, can you post your acpidump? your dmesg doesn't match with previous acpidump. 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.
Created attachment 12877 [details]
acpidump from acer travelmate 3022 wtmi
Created attachment 12878 [details]
dmesg -c after closing lid for a few seconds (debug on, patched)
Hmm, it seems that we keep on receiving ec GPE events. could you please boot with ec_intr=0? Created attachment 12913 [details]
dmesg -c after closing lid for a few seconds (debug on, patched, ec_intr=0)
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. :) Created attachment 12975 [details]
same as before but with button loaded
i didn't load button to get rid of acpid log spam :x
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.
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. Created attachment 13411 [details]
patch: disable ec gpe while handling ec events
Oops, that one is quite old, please try this one. :)
Created attachment 13412 [details]
dmesg -c after closing lid for a few seconds (debug on, patched, ec_intr=0, button loaded)
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. is there any difference if you remove the boot option "ec_intr=0"? no difference in acpid's output. it still receives 3 events for each action. >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. Created attachment 13418 [details]
acpid's log after closing lid for a few seconds (debug on, patched, button loaded)
Created attachment 13419 [details]
dmesg -c after closing lid for a few seconds (debug on, patched, button loaded)
Created attachment 13420 [details]
acpid's log after closing lid for a few seconds (debug on, button loaded)
Created attachment 13421 [details]
dmesg -c after closing lid for a few seconds (debug on, button loaded)
Hi, Felix please check if there is any BIOS update for your laptop. 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. Hmm, good news to me. :) I'll close this bug and mark it as UNREPRODUCIBLE. Please reopen it if the interrupt storm occurs again. 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. Hi, Jool Will you please open a new bug about your laptop? Please attach the output of dmesg , lspci -vvxxx and acpidump. Thanks. 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. 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.. 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) I have opened a new bug as suggested for my laptop model here http://bugzilla.kernel.org/show_bug.cgi?id=10485 |