Most recent kernel where this bug did not occur: Distribution: Ubuntu Gutsy 7.10 Hardware Environment: IBM Thinkpad X40, ICH4, BIOS 2.08 Software Environment: Linux 2.6.24-rc1, acpid/acpi_listen 1.0.4 Problem Description: On my laptop (IBM Thinkpad X40 model 2371Y29, BIOS release 1UETD3WW 2.08), running an unpatched stock 2.6.24-rc1 kernel, powertop often shows a few (but relatively persistent) wake ups per second caused by ACPI, but acpi_listen doesn't see any event. It looks like this, in powertop: 17,0% ( 5,7) <interrupt> : acpi The number of interrupts per second can vary (usually between 1 to 8 per sec.), and sometimes powertop show no acpi interrupts at all during several seconds. acpi_listen(8) seems to be otherwise working well (ie. it catches all AC power plugs/unplugs). This happens also with kernels 2.6.23 and 2.6.22. I'm willing to test, please just ask what you want me to do. I can also provide a remote root shell on the laptop if we can exchange a password securely. I'll attach outputs of the following commands: "acpidump -b|gzip", "dmesg", "lsmod" "lspci -vvxx", "cat /proc/acpi/wakeup", "cat /proc/interrupts", "cp /proc/config.gz" Steps to reproduce:
Created attachment 13338 [details] Binary ACPI dump
Created attachment 13339 [details] Kernel config (plain 2.6.24-rc1)
Created attachment 13340 [details] dmesg (from a 2.6.24-rc1)
Created attachment 13341 [details] lsmod (2.6.24-rc1)
Created attachment 13342 [details] lspci -vvxx (running 2.6.24)
Created attachment 13343 [details] content of /proc/acpi/wakeup
Created attachment 13344 [details] content of /proc/interrupts
please set CONFIG_ACPI_DEBUG and rebuild your kernel, and then, echo 0xffff0004 > /sys/module/acpi/parameters/debug_layer echo 0x8000001f > /sys/module/acpi/parameters/debug_level and attach the dmesg output after receiving some acpi interrupts.
Created attachment 13359 [details] dmesg with CONFIG_ACPI_DEBUG and Zhang Rui's debug mask Here it is. I collected about one minute of acpi debug in dmesg while powertop was seeing about 0.7 to 1.1 acpi interrupts per second (not a lot at this time), and acpi_listen, started in an other shell, didn't display any event.
Created attachment 13380 [details] patch vs 2.6.21 to show acpi interrupt stats please watch /sys/firmware/acpi/interrupts/stats before and after the acpi events to see what is causing the interrupts. note, this is a 2.6.21 patch, i'll be forward porting it shortly, but if you've got a 2.6.21 kernel handy, you can use it as-is.
BTW. the output in comment #9 shows a bunch of battery activity. do the interrupt bursts go away if you rmmod the battery driver? is there something in the GUI that is polling the battery state?
Re comment #9: Hi, Benjamin, Sorry that the debug mask I told you didn't make sense, please try echo 0x04 > /sys/module/acpi/parameters/debug_layer echo 0x8800001f > /sys/module/acpi/parameters/debug_level instead. :)
Created attachment 13435 [details] dmesg with new suggested mask Hi, no problem with a patch for 2.6.21, this kernel exposes the same behavior. Here's what differs, in /sys/firmware/acpi/interrupts/stats after a few minutes (during which powertop still showed acpi activity but acpi_listen didn't), all other values stays at 0 : -gpe_total 1405 +gpe_total 2386 -gpe28 1405 +gpe28 2386 This "gpe28" grows at the same time as the "IO-APIC-fasteoi acpi" counter in /proc/interrupts (actually as the same value minus one). Yes the rogues interrupts vanished after I unloaded the battery module. And yes, they are triggered by some userland activity. Killing the usual suspects (gnome-power-manager and powertop) didn't stop those interrupts, but killing hal (0.5.9.1) did. Stracing hald showed that a simple "cat /proc/acpi/ac_adapter/AC/state" triggers two acpi interrupts (invisibles to acpi_listen), and increases subsequently my "gpe28" counter by two (when running Len's patch).
Created attachment 13436 [details] /sys/firmware/acpi/interrupts/stats before
Created attachment 13437 [details] /sys/firmware/acpi/interrupts/stats after some time and a few more interrupts
Hal keeps on polling the ACPI device status, thus triggers ACPI ec events. acpi_listen only captures the acpi notifications exported to user space, which is quite differnt from ACPI interrupts. You can trigger ACPI interrupts by manually poking the AC/battery proc I/F, right? Then I don't think this is a Linux/ACPI bug. Benjamin, can you resend the acpidump please? the one in comment #1 is broken.
Benjamin, please upload the acpidump output as requested in comment# 16. Please don't zip it, just attach the output as an attachment would be fine...
Created attachment 13615 [details] Plain text acpidump Sorry I was afaik for a week. Here is the requested dump. About comment #16 : Yes, I can trigger the same interrupts by hand, and yes it's triggered by userland activity. I'm not skilled and qualified to tell if it's a bug in Linux/ACPI, somewhere else, or not at all; I was just told by Len on IRC to report this behavior here (so we could better explore and understand what's happening: apparently we're done). Plus it's harmless. So feel free to close it (and/or to tell me if I should report something at hal's bt), sorry if I messed with your time. PS: Len's 2.6.21 "acpi interrupts stats" patch (in comment #10) worked well here. If you need a tester for a forward port, just ask.
Created attachment 13616 [details] Same, but binary (acpidump -b)