Distribution: Debian Sid Hardware Environment: Asus w1000 Software Environment: Vanilla Kernel built by my own fair hand Problem Description: when running any app that polls for battery status my machine grinds to a halt. If run top it shows which ever battery app as using >20% cpu. I have mostly gotton round this by adding the line: #define ACPI_ENABLE_OBJECT_CACHE 1 in include/acpi.h But whatever acpi app I use still uses >3% cpu bandwidth. This didn't happen on kernels <2.6.8 My kernel config is here http://fsck.tv/conf-2.6.12 Steps to reproduce: Build kernel as normal (use my config) launch an acpi app such as wmacpi or wmbattery. Watch your system slow to a stop It even does this when you cat /proc/acpi/battery/BAT0/state in fact if you were to write a script to do this you could cripple the system
Please test 2.6.13-rc1-mm1
when running 2.6.13-rc1-mm1 acpi apps are unable to read the status of my battery if I try to cat /proc/acpi/battery/BAT0/state I get nothing, cat just hangs I have to kill with ^C I fact this happens if I try to cat anything inside /proc/acpi/battery/BAT0/
Forgot to say that although I cant actualy use the battery status anymore there is zero cpu useage by cat (even though it appears hung)
Just guess you have the similar problem like http://bugzilla.kernel.org/show_bug.cgi?id=4665 To debug further, could you test http://bugzilla.kernel.org/process_bug.cgi#c23
hm, a few people have reported this. Is it still happening in 2.6.13-rc4?
linux-2.6.13-rc4. acpi hangs on boot for 30 seconds. after battery condition is not readable. I don't know if this is due to a crash as acpi starts up etc Basicly its more broken on 2.6.13-rc4
Please test ec_polling patch at http://bugzilla.kernel.org/show_bug.cgi?id=4665 Note: boot kernel with ec_polling option
Lots of people have reported this problem. Do we expect that it's now fixed with the ec revert?
What do you see with 2.6.13-rc6 as compared to 2.6.12.1?
This should be fixed like bug 4665, which is ASUS L5D. Close it as duplicate. *** This bug has been marked as a duplicate of 4665 ***