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
I have mostly gotton round this by adding the line:
#define ACPI_ENABLE_OBJECT_CACHE 1
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
To debug further, could you test
hm, a few people have reported this. Is it
still happening in 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 18.104.22.168?
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 ***