Bug 9263
Summary: | APCI interrupts, but acpi_listen show nothing (Thinkpad X40) | ||
---|---|---|---|
Product: | ACPI | Reporter: | Benjamin Pineau (ben.pineau) |
Component: | Config-Interrupts | Assignee: | Zhang Rui (rui.zhang) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | low | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.24-rc1 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
Binary ACPI dump
Kernel config (plain 2.6.24-rc1) dmesg (from a 2.6.24-rc1) lsmod (2.6.24-rc1) lspci -vvxx (running 2.6.24) content of /proc/acpi/wakeup content of /proc/interrupts dmesg with CONFIG_ACPI_DEBUG and Zhang Rui's debug mask patch vs 2.6.21 to show acpi interrupt stats dmesg with new suggested mask /sys/firmware/acpi/interrupts/stats before /sys/firmware/acpi/interrupts/stats after some time and a few more interrupts Plain text acpidump Same, but binary (acpidump -b) |
Description
Benjamin Pineau
2007-10-30 09:32:26 UTC
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)
|