Under Gutsy on System76 Darter, battery state information is often incorrect.

Bug #139701 reported by Michael D. Stemle, Jr.
32
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Stefan Bader
linux-source-2.6.22 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Sporadically throughout the day I'll notice eratic behavior from the power-management software under Kubuntu (and I've noticed the same issue on GNOME as well as KDE). Per the advice of #ubuntu-kernel folks, I looked into /proc/acpi/battery and found that the battery is showing information that does not seem correct. I've also noticed that in syslog (soon to be attached) there is a keycode error message that I'm getting whenever I unplug and plug in the A/C adapter.

Other things I've noticed that may or may not be related is that coming back from suspension does not seem to work--it did work before--and the temperature that is also in /proc/acpi seems to bounce back and forth between a temperature that sounds about right, and a temperature that doesn't seem very right at all.

I have noticed that this bug seems relatively similiar to bug #129388 and bug #116185. I do not know which version of the kernel started this problem, it has been consistent since I got the machine and upgraded it to gutsy (around very late August).

I'm attaching several files per the requirements of the Kernel Bug Team, and also some advice from folks in #ubuntu-kernel.

Tags: cft-2.6.27
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :
Revision history for this message
Michael D. Stemle, Jr. (manchicken) wrote :

I know that this is a lot of information, and I hope it's useful. I am more than willing to try things out, and I can provide any more information that you need. Thanks.

Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Greg Grossmeier (greg.grossmeier) wrote :

Same computer (verified by comparing lscpi -vvnn's, it is a System76 Darter version 2). Adding cat /proc/acpi/dsdt

This is still an issue in Hardy (2.6.24-3).

Revision history for this message
Greg Grossmeier (greg.grossmeier) wrote :

Changed package to linux-source-2.6.24

Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
reh4c (gene-hoffler) wrote :

Still an issue in Hardy 2.6.24-7 on this laptop--Darter 2 aka MSI-1221.

Revision history for this message
camellight (ceminino) wrote :

using ec_intr=0 as a boot option solves the problem.

Revision history for this message
Neal McBurnett (nealmcb) wrote :

To use ec_intr=0 regularly, add it to the end of your "defoptions" line in /boot/grub/menu.1st, so it survives kernel upgrades. Here is an example. Note that the "#" at the beginning of the line is needed.

 # defoptions=quiet splash ec_intr=0

You can check whether or not ec_intr was used during boot via
 dmesg | grep command

which will say something like this:

[ 0.000000] Kernel command line: root=UUID=0b61784e-aec2-4112-b9d7-f1b9b8ee8a52 ro quiet splash ec_intr=0

Revision history for this message
Thomas Aaron (tom-system76) wrote :

Confirmed by System76 in-house testing.
It fixes the problem in 64-bit Ubuntu, and some of our forum posts indicate that it works
for 32-bit Ubuntu as well.

We need more Hardy testing with this fix.

Gene, would you be so kind as to post your /boot/grub/menu.lst so that we can have a look at how your setting it up -- just to make sure...

Thank you.
Tom

Revision history for this message
Neal McBurnett (nealmcb) wrote :

I tried the ec_intr=0, as documented above with dmesg. Though I'm a bit nervous that I don't know how to check a running system to see if the command line "took" or not. Any tips?

It may have helped some, but I'm still seeing bad ACPI output.

Gutsy 32 bit, System76 Darter daru2, pretty up-to-date with updates....

Booted at about Feb 26 19:30 last night.

Ran this after boot:
( while true; do
    date; time acpi -V; sleep 300;
done ) 2>&1

Got normal results for about 6 hours, like this:
     Battery 1: charging, 90%, 00:17:50 until charged
     Thermal 1: ok, 60.0 degrees C
  AC Adapter 1: on-line

real 0m0.132s
user 0m0.000s
sys 0m0.028s

I watch the time output because the other big symptom for me has been very slow responses to the acpi command - e.g. 6 to 30 seconds.
That problem hasn't come back yet, even after doing a suspend resume.

Then I suddenly started getting odd results: sometimes says it was
off-line, missing Battery 1 data entirely, etc. like this.

 Wed Feb 27 01:42:22 MST 2008
     Battery 1: charged, 100%
     Thermal 1: ok, 52.0 degrees C
  AC Adapter 1: off-line

Wed Feb 27 01:47:22 MST 2008
     Thermal 1: ok, 210.0 degrees C
  AC Adapter 1: on-line

Wed Feb 27 02:17:22 MST 2008
     Battery 1: charging, 0%, 05:20:00 until charged
     Thermal 1: ok, 210.0 degrees C
  AC Adapter 1: on-line

And it is still doing that now....

I was asleep when the bad results started, and haven't run anything
cpu-intensive that I can think of.

I sometimes use this command to dump all the /proc/acpi files:

  more `find /proc/acpi -type f`

that output is attached

Revision history for this message
Thomas Aaron (tom-system76) wrote :

I doubt it makes a lot of difference, but just to be thorough, try putting the ec_intr=0 before "ro splash".
That's what is working for me. You also might want to consider moving to 64-bit, as this fix is definitely working
with it, and S1 suspend works in 64-bit as well.

Revision history for this message
Idan Mashaal (idanmashaal) wrote :

Hello,

I think this bug should be re-opened and investigated again, as there is a major regression with the Daru2 and Hardy (stable releae) as ACPI is very unstable, Suspend doesn't work.

What seems to solve the problems in Gutsy (kernel 2.6.22) seems to be gone in kernel 2.6.24, i.e. there is no ec_intr=0 flag.
I've tried the 'force_poll=1' kernel parameter but that didn't work...

There are a couple of posts on the System76 forum.

Please let me know what information you need.

Idan.

Revision history for this message
Carl Richell (carlrichell) wrote :

When the embedded controller is in interrupt mode battery indication is not reliable. In polling mode it works perfectly. ec_intr=0 sets the kernel to polling mode but it was removed.

References:

ec_intr was removed from the mainline kernel:

http://<email address hidden>/msg09437.html
http://kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fpatch-2.6.24.bz2;z=3301

kernel parameter "acpi=noirq" will fix the battery issues but it has the side effect of breaking the brightness control keys.

We need the kernel in "polling" mode to work correctly rather than "interrupt" mode. Some more info:

http://lkml.org/lkml/2007/5/10/81

force_poll=1 option is not in the Ubuntu kernel.

kernel ec.c driver can be modified to use polling mode without disturbing brightness keys: http://ubuntuforums.org/showpost.php?p=4843977&postcount=143 - Thanks to pavel_987 for this possible work around. This work around is probably specific to pc's that should be in polling mode.

» Offer to mentor someone fixing this bug

Revision history for this message
nuno.bett (nuno-bett) wrote :

"acpi=noirq" fixed my battery issues but killed the brightness control keys

MSI PR200 clone

Revision history for this message
Thomas Aaron (tom-system76) wrote :

Yes, that is the same symptoms we get.
No work-around for that one at this time. We are working on fixing the "big picture" acpi problems with this computer.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Stefan Bader (smb) wrote :

Is this issue still seen on the latest Jaunty beta?

Changed in linux (Ubuntu):
assignee: ubuntu-kernel-acpi → stefan-bader-canonical
Revision history for this message
Greg Grossmeier (greg.grossmeier) wrote :

The battery state information on this hardware is now accurately reported in Jaunty in interrupt mode.

greg@foucault:~$ dmesg | grep EC
[ 0.712625] ACPI: EC: Look up EC in DSDT
[ 0.720022] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 0.752217] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 0.752221] ACPI: EC: driver started in interrupt mode

Changed in linux-source-2.6.22 (Ubuntu):
status: Triaged → Fix Released
Changed in linux (Ubuntu):
status: Triaged → Fix Released
Curtis Hovey (sinzui)
Changed in linux-source-2.6.22 (Ubuntu):
assignee: Registry Administrators (registry) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.