Friday, October 10, 2008

Missing Battery Information

In the last few days (or should i say weeks), i encountered strange problems on my laptop. I enabled the battery monitor on my KDE and i loaded battery modules, but after few hours of working with it, i lost the information about the battery. I asked ID-Slackware community but nobody experienced this. At first, i thought it was only happening on my system, but in fact, it's not. Everybody else has reported this on this and this (and probably more). It happened after i used 2.6.26.x kernels.

The solution is already on the latest Stable kernel, 2.6.26.6 after reading commit from Intel developer, Zhao Yakui. Here's the commit info:
commit e6908f26e33567ebd565fad04096537a5853fec0
Author: Zhao Yakui
Date: Tue Sep 23 13:38:13 2008 +0800

ACPI: Avoid bogus EC timeout when EC is in Polling mode

commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream

When EC is in Polling mode, OS will check the EC status continually by using
the following source code:
clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
while (time_before(jiffies, delay)) {
if (acpi_ec_check_status(ec, event))
return 0;
msleep(1);
}
But msleep is realized by the function of schedule_timeout. At the same time
although one process is already waken up by some events, it won't be scheduled
immediately. So maybe there exists the following phenomena:
a. The current jiffies is already after the predefined jiffies.
But before timeout happens, OS has no chance to check the EC
status again.
b. If preemptible schedule is enabled, maybe preempt schedule will happen
before checking loop. When the process is resumed again, maybe
timeout already happens, which means that OS has no chance to check
the EC status.

In such case maybe EC status is already what OS expects when timeout happens.
But OS has no chance to check the EC status and regards it as AE_TIME.

So it will be more appropriate that OS will try to check the EC status again
when timeout happens. If the EC status is what we expect, it won't be regarded
as timeout. Only when the EC status is not what we expect, it will be regarded
as timeout, which means that EC controller can't give a response in time.

http://bugzilla.kernel.org/show_bug.cgi?id=9823
http://bugzilla.kernel.org/show_bug.cgi?id=11141

Signed-off-by: Zhao Yakui
Signed-off-by: Zhang Rui
Signed-off-by: Andi Kleen
Signed-off-by: Greg Kroah-Hartman


Guess what? It's only two line of patches big grin

---
drivers/acpi/ec.c | 2 ++
1 file changed, 2 insertions(+)

Index: linux-2.6/drivers/acpi/ec.c
===================================================================
--- linux-2.6.orig/drivers/acpi/ec.c
+++ linux-2.6/drivers/acpi/ec.c
@@ -196,6 +196,8 @@ static int acpi_ec_wait(struct acpi_ec *
return 0;
msleep(1);
}
+ if (acpi_ec_check_status(ec,event))
+ return 0;
}
pr_err(PREFIX "acpi_ec_wait timeout, status = 0x%2.2x, event = %s\n",
acpi_ec_read_status(ec),


For those who had problems with battery information, i suggest you to upgrade to this version or just go straight to 2.6.27 which has just been released by Linus and let's hope you will find the cure for your problem. I haven't upgrade yet, since it just came out, but i will upgrade to check whether the solution is fixing my problem or not.

It's one of the advantage of reading Kernel changelog, even though i don't understand the rest of the changelog big grin.