Kernel detects battery management wrong (MSI PR200 / System76)

dmesg file when laptop booted with AC plugged in.

here is the /proc/acpi/battery/BAT1/state when the ACPI is acting up weird

Though I don't know it's because kernel detects it wrong, I have the same problem on an MSI PR200 (Intel Santa Rosa 965PM). Power Manager of KDE reports AC plugged/unplugged repeatedly.

Same problem using gusty on a msi gx700 laptop.
I'm currently working on the battery and acpi reports a charging state :

vinx@vinx-laptop:~$ more /proc/acpi/battery/BAT1/state
present: yes
capacity state: ok
charging state: charging
present rate: 1526 mA
remaining capacity: 40710 mAh
present voltage: 52522 mV

It's the same for the gnome battery icon.

If i plug the AC cable, my screen randomly changes from "charging state" to "battery state" and comes back to "charging state". (The luminosity gets lower). It's very annoying.

I can give more informations if needed.

I have the same problem running gutsy on an MSI PR600 laptop.

I ran some scripts/tools to monitor hal (lshal -m), acpi (acpi -Vs) and changes to the contents of '/proc/acpi/battery/BAT1/*'. It appears that the '/proc/acpi/battery/BAT1/*' information fairly regularly gets written incorrectly, such that the periodic check of this information by hal gets incorrect information and makes it available to the rest of the system (e.g. the gnome power manager). I see the same thing even when no battery is present (just ac power). I've attached the output of this monitoring that illustrates what I've seen. An explanation of the output is at the header of each file.

I wasn't able to determine what was writing the (incorrect) information to the '/proc/acpi/battery/BAT1/*' files, so I'm posting what I know in the hope that it will help someone with more knowledge track down the problem.

Thanks to System76 I've now got access to one of these PR200 laptops and I'll try to do some debugging.

I'd like to say that I experience the same problem on a MSI-1719 (PX700) laptop (Intel C2D, Santa Rosa chipset) and 64 bit version of Gutsy. Gnome power manager history shows multiple AC adapter connects and disconnects, wrong/undetected battery state and charge. The associated screen flicker, as it dims and brightens repeatedly is very annoying.

Is there anything that can be to be done to help you fix this?

Same problem with the same platform (MSI GX700, Intel Core 2 Duo, Santa Rosa).
Here is a screen shot of the battery history in gnome power manager.
Can provide more informations. Tell me what !

Vinx, that's exactly how mine looks, too. What BIOS version do you have? (I saw an upgraded BIOS version on MSI's website, I wonder if that could help with this problem)

I have found that if I don't use the Fn + brightness up and Fn + brightness down keys to set screen brightness I can prevent the g-p-m from constantly re-setting the brightness. I set my screen brightness to 100% in g-p-m when connected to AC, 0% change when on battery and uncheck the "dim screen when inactive". That way, g-p-m is still unable to detect the correct battery charge but at least it doesn't interfere with regular use of the computer.

My bios seems to be upgraded only for XP, which is not my case : (Vista was provided with my laptop)
http://global.msi.com.tw/index.php?func=downloaddetail&type=bios&maincat_no=135&prod_no=1227

My brightness changes even if i don't use the Fn brightness keys. Very annoying while playing a full screen game, because the game looses the focus. I need to use "Alt+tab" to come back to the game.

My workaround is to kill gnome-power-management !

same laptop here, and same workaround killing gnome-power-manager :/

I have added an attachment that shows the g-p-m setting I use. On the left is the AC- adapter window, on the right is the battery window. With these settings and LCD brightness set to 100 percent (use the gnome brightness applet with the slider moved all the way up/your Fn keys), g-p-m will not try to change the screen brightness and won't steal mouse focus from full screen games.

This may be related: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129388

and this, too https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116185

Attached log of "gnome-power-manager --verbose --no-daemon" when the bug occurs (the AC adapter was unplugged all the time, yet the messages show repeated AC off( Setting on-ac: 0) and on ( Setting on-ac: 1)).

I also found another error in dmesg, it only shows sporadically, but it probably has something to do with the battery, too.

[ 1423.685959] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 1423.685966] ACPI: EC: read timeout, command = 128
[ 1423.685971] ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
[ 1423.685981] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]
[ 1423.685992] ACPI Error (psparse-0551): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.UPBS] (Node ffff81007ce5fbc0), AE_TIME
[ 1423.686041] ACPI Error (psparse-0551): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._BST] (Node ffff81007ce5fb40), AE_TIME
[ 1423.686080] ACPI Exception (battery-0206): AE_TIME, Evaluating _BST [20070126]
[ 1680.616615] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 1680.616628] ACPI: EC: read timeout, command = 128
[ 1680.616637] ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
[ 1680.616655] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]
[ 1680.616673] ACPI Error (psparse-0551): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.UPBS] (Node ffff81007ce5fbc0), AE_TIME
[ 1680.616763] ACPI Error (psparse-0551): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._BST] (Node ffff81007ce5fb40), AE_TIME
[ 1680.616840] ACPI Exception (battery-0206): AE_TIME, Evaluating _BST [20070126]

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

laptop acts normal when turned on with AC power, but it starts to act weird after a certain point of time anyway.

attached is my power history.
note that the graph continues to grow, but each time it switches to "battery power", the line suddenly drops. when AC power is recognised again, the line smoothens itself. this might be another bug, or maybe i just don't understand the graph ;)

output of dmesg

output of dmidecode

output of sudo lspci -vvnn

output of uname -a

output of cat /proc/version_signature

Hardware: MSI PR200 (MS-1221)
Link: http://global.msi.com.tw/index.php?func=proddesc&prod_no=1322&maincat_no=135
Bug exists with fully updated 7.10 and latest BIOS

I also have a pr200 and using ec_intr=0 as a boot option solves the problem.

A System76 model that has this problem is the "Darter", model daru2. based on the MSI-1221.

See also
 https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/139701
 Under Gutsy on System76 Darter, battery state information is often incorrect.
The dup: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/130739
   Power Mangement Issues on daru2

and the forums discussion at
 http://ubuntuforums.org/showthread.php?t=609722&page=6

It seems I have the same bug on a MSI EX600-023.
The brightness changes randomly. This bug doesn't occur if the battery was unplugged at boot time but comes back when I plug it in. If I unplug the battery when the computer is on the bug remains. Moreover, the battery is not managed well. For exemple the energy is displayed as low even if the battery as been plugged in for hours.

I have an other bug concerning brightness but I'm not sure it is linked, as it is still present when the battery has been unplugged since computer start. Just ignore this part if you consider it irrelevant. If I decrease the brightness it doesn't regularily lower with with each notch down. Instead it decreases a lot, then increases to a value that is a little lower to the original one, then decreases a lot again, then increases a little, and so on. And the same thing goes when I increase the brightness from the minimum to the maximum.

I'm running Gutsy but all those bugs are still present in Hardy.

install the System76 drivers. This solved the strange behaviour of the brightness. boot with ec_intr=0 to solve the battery issue.

Brighten changing bug appears to be fixed with Ubuntu Hardy beta. I'm still checking the battery applet G-P-M for its accuracy.

Follow-up: I haven't experienced the sporadic and annoying brightness bug since Hardy beta (64 bit), but unreliable power readings through GPM still remain. In fact, the laptop erroneously shut down on me in the middle of working due to a faulty reading--battery was actually just charged.

Booting with the kernel parameter EC_INTR=0 should fix it.

Fix doesn't work on Hardy beta 64-bit with kernel 2.6.24-15. Same wacky battery meter readings.

----- Original Message ----
From: impact <email address hidden>
To: <email address hidden>
Sent: Wednesday, April 9, 2008 3:30:13 AM
Subject: [Bug 147560] Re: Kernel detects battery management wrong (MSI PR200 / System76)

Booting with the kernel parameter EC_INTR=0 should fix it.

--
Kernel detects battery management wrong (MSI PR200 / System76)
https://bugs.launchpad.net/bugs/147560
You received this bug notification because you are a direct subscriber
of the bug.

Tom at System76 support mentioned that the bug may be related to dynticks enabled in the 2.6.24 and later kernels. I've experienced the computer shutting down with no warning several times due to the faulty battery reading and GPM. Luckily, this computer has only been used for testing.

Same flakey battery readings on Kubuntu Remix 8.04 64-bit beta.

Problem still exists on Ubunty Hardy 64-bit RC...damn the battery meter and acpi on this notebook! Everything else works so well!

This battery indicator problem does not appear present on Fedora 9 preview. I guess my most likely course of action is to disable gnome power manager for Hardy 8.04. Any other ideas?

Same problem here... (on a MSI S271, amd64)

Gnome battery readings are all over the place, but /proc/acpi/battery/BAT1/state seems to report the correct values. Any chance a fix for this will make it into hardy still?

not sure this is related, but whenever I plug an external screen on my laptop. It messes up the brightness of my laptop screen, and sometimes, it takes a while for me to recover from it :/ . my laptop is an ASUS U5F-series. Also all my 'Fn' strokes arent recognized by the OS, so I have to reboot and do my changes while it's loading the bios.

Oh by the way, I am running ubuntu 8.04.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

Hopefully solved, according to http://bugzilla.kernel.org/show_bug.cgi?id=9823 the patch is in 2.6.27 upstream now. Can't wait to test it.

Based on my limited use of Intrepid Alpha 4 on my MSI-PR200, the battery meter has been accurate. However, I'll keep an eye on it just to be sure. Thanks!!!

will we see the fix in a ubuntu-provided kernel anytime soon?

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.

suppose that i want to test the linux-image-* package.

where can i get it? it's not in any of my repositories.

I just downloaded from here http://kernel.ubuntu.com/pub/next/2.6.27-rc2/hardy/ , and the damn standby still doesn't work!

awww, too bad :e/
this bug is about battery management, though. does that work?

I haven't tested this personally but according to this post http://ubuntuforums.org/showthread.php?t=772722&page=4#post5687181 , it is fixed.

guys, what did you do!

REGRESSION, screaming from the top of my lungs. latest 2.6.27-7 kernel in Intrepid breaks battery management again.

dmesg says:
[ 0.721788] ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f32f438) [EmbeddedControl] [20080609]
[ 0.721802] ACPI Error (exfldio-0291): Region EmbeddedControl(3) has no handler [20080609]
[ 0.721817] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f330e20), AE_NOT_EXIST
[ 0.721969] ACPI Error (uteval-0232): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f330e20), AE_NOT_EXIST
[ 0.727164] ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f32f438) [EmbeddedControl] [20080609]
[ 0.727178] ACPI Error (exfldio-0291): Region EmbeddedControl(3) has no handler [20080609]
[ 0.727192] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f330e20), AE_NOT_EXIST
[ 0.727341] ACPI Error (uteval-0232): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff88007f330e20), AE_NOT_EXIST

and /proc/acpi/battery says:
matejcik@limetka:/proc/acpi/battery$ ls -l
celkem 0
dr-xr-xr-x 2 root root 0 2008-10-13 15:23 BAT1
matejcik@limetka:/proc/acpi/battery$ ls -l BAT1/
celkem 0
-rw-r--r-- 1 root root 0 2008-10-13 15:23 alarm
-r--r--r-- 1 root root 0 2008-10-13 15:23 info
-r--r--r-- 1 root root 0 2008-10-13 15:23 state
matejcik@limetka:/proc/acpi/battery$ cat BAT1/*
present: no
present: no
present: no

interestingly, after a BIOS upgrade, it works fine again

might just have been a fluke

Hi matejcik,

1. What laptop model exactly do you have ?
2. What was the exact bios version before the upgarde ?
3. What is the exact bios you currently have (after upgrading) ?

Thanks,

Idan.

1. MSI PR200 YA (Lime Green variant) without preloaded OS

2. don't know, sorry, I didn't check. It was the preloaded BIOS version. (bought the machine in December 07)

3. BIOS build A1221IMS, Ver3.43, 04/08/2008
EC build 1221EMS2 Ver3.12, 11/27/2007
i.e. the latest BIOS available for download from MSI's site

The errors posted above are still there, but now it also reports that it found a battery and everything works as it should.
(the errors are there even with the older kernel, so i guess that they were there the whole time)
I did start the laptop two or three times with the old BIOS, and the battery was consistently reported missing. (unlike the original report, battery was not detected at all) However, i did not try to boot with 2.6.27-6 kernel, which was working fine before. I just didn't think about testing it more thoroughly, i didn't expect the bug to go away with a BIOS upgrade ;e)

Hi,

Hi, why did you choose the 3.43 over 1.43 ?

I did some reasearch and found that 1.43 version enables SATA support
(that's why it's for Vista and supporting OS's, XP doesn't do that out of
the box). Note that the 1.43 bios causes the wireless button to have only 2
modes, [BT+WLAN] ON or OFF, no mixed more.

Have you tried it ?

Idan.

On Mon, Oct 13, 2008 at 7:50 PM, matejcik <email address hidden> wrote:

> 1. MSI PR200 YA (Lime Green variant) without preloaded OS
>
> 2. don't know, sorry, I didn't check. It was the preloaded BIOS version.
> (bought the machine in December 07)
>
> 3. BIOS build A1221IMS, Ver3.43, 04/08/2008
> EC build 1221EMS2 Ver3.12, 11/27/2007
> i.e. the latest BIOS available for download from MSI's site
>
> The errors posted above are still there, but now it also reports that it
> found a battery and everything works as it should.
> (the errors are there even with the older kernel, so i guess that they were
> there the whole time)
> I did start the laptop two or three times with the old BIOS, and the
> battery was consistently reported missing. (unlike the original report,
> battery was not detected at all) However, i did not try to boot with
> 2.6.27-6 kernel, which was working fine before. I just didn't think about
> testing it more thoroughly, i didn't expect the bug to go away with a BIOS
> upgrade ;e)
>
> --
> Kernel detects battery management wrong (MSI PR200 / System76)
> https://bugs.launchpad.net/bugs/147560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

i didn't do any deeper research, i just assumed that XP version would be "more compatible". and from what i've seen now, the SATA support seems to be the same.
I also liked the mixed switch on friend's PR200 White variant, that was one of the reasons for upgrading ;e) not that i care too much about this feature, it just seemed interesting, i might get tired of it.
(main reason was broken PXE booting in our company, i tried to update the BIOS hoping that it would fix the PXE boot (and it didn't))
i can certainly try it, but if the only difference is default setting for AHCI mode and BT/WLAN switch, then why do they differentiate?

A few months ago I asked MSI about the diffrence between 1.xx and 3.xx and
got this response:
" Bios V3.XX is for windows XP.Bios V1.xx is for windows Vista.The
differences between these two version BIOS are not only AHCI,but also
SLP(system lock preinstallation,and others.So I advise you to use the right
BIOS version. "

I really didn't understand what SLP is and what 'others' mean, but I guess
that if somone wants to use SATA, then 1.xx is the safer way (but that
doesn't belong to this bug).

About SLP - does anyone here know what that means ? or is it related to this
?

Thanks,
Idan.

On Tue, Oct 14, 2008 at 3:29 AM, matejcik <email address hidden> wrote:

> i didn't do any deeper research, i just assumed that XP version would be
> "more compatible". and from what i've seen now, the SATA support seems to be
> the same.
> I also liked the mixed switch on friend's PR200 White variant, that was one
> of the reasons for upgrading ;e) not that i care too much about this
> feature, it just seemed interesting, i might get tired of it.
> (main reason was broken PXE booting in our company, i tried to update the
> BIOS hoping that it would fix the PXE boot (and it didn't))
> i can certainly try it, but if the only difference is default setting for
> AHCI mode and BT/WLAN switch, then why do they differentiate?
>
> --
> Kernel detects battery management wrong (MSI PR200 / System76)
> https://bugs.launchpad.net/bugs/147560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

SLP seems to be good for windows auto-activation, see
http://en.wikipedia.org/wiki/System_Locked_Preinstallation
so it makes sense to choose the correct BIOS if you're using the preloaded
OS (which i am not).
About the "others" ... well, we will see. I was using the 1.xx BIOS before
(AHCI was on by default and wifi button was two-state), i'm using 3.xx now
and important functionality does not seem to differ.

On Tue, Oct 14, 2008 at 10:20, Idan Mashaal <email address hidden> wrote:

> A few months ago I asked MSI about the diffrence between 1.xx and 3.xx and
> got this response:
> " Bios V3.XX is for windows XP.Bios V1.xx is for windows Vista.The
> differences between these two version BIOS are not only AHCI,but also
> SLP(system lock preinstallation,and others.So I advise you to use the right
> BIOS version. "
>
> I really didn't understand what SLP is and what 'others' mean, but I guess
> that if somone wants to use SATA, then 1.xx is the safer way (but that
> doesn't belong to this bug).
>
> About SLP - does anyone here know what that means ? or is it related to
> this
> ?
>
> Thanks,
> Idan.
>
> On Tue, Oct 14, 2008 at 3:29 AM, matejcik <email address hidden> wrote:
>
> > i didn't do any deeper research, i just assumed that XP version would be
> > "more compatible". and from what i've seen now, the SATA support seems to
> be
> > the same.
> > I also liked the mixed switch on friend's PR200 White variant, that was
> one
> > of the reasons for upgrading ;e) not that i care too much about this
> > feature, it just seemed interesting, i might get tired of it.
> > (main reason was broken PXE booting in our company, i tried to update the
> > BIOS hoping that it would fix the PXE boot (and it didn't))
> > i can certainly try it, but if the only difference is default setting for
> > AHCI mode and BT/WLAN switch, then why do they differentiate?
> >
> > --
> > Kernel detects battery management wrong (MSI PR200 / System76)
> > https://bugs.launchpad.net/bugs/147560
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> Kernel detects battery management wrong (MSI PR200 / System76)
> https://bugs.launchpad.net/bugs/147560
> You received this bug notification because you are a direct subscriber
> of the bug.
>

okay, few days later i can confirm either a regression or a hardware failure on my part:
even with the updated bios, in some cases the battery status is not reported at all and the battery behaves like it's missing.
AC adapter detection works fine, and yes, the battery is indeed correctly plugged in :e)

at system start, the battery status is visible, but it disappears after a short time.
nothing of interest showing in kernel logs, except for what i posted above

i need to test 2.6.27-6 kernel to find out if it's not a hardware problem - but windows seemed to work with the battery just fine.

I can confirm that after an upgrade from Hardy to Intrepid just a few days ago the battery behaviour got worse. I am now on 2.6.27-7-generic SMP x86_64.

The battery and AC status seem to be detected correctly during boot, but after that the charge applet displays: "Battery state could not be read at this time", and also detects the AC state wrong.

This is on an MSI S271 (1058) with BIOS version 1.21. When booting the supplied Windows XP, battery status works perfectly.

confirmed, change between 2.6.27-6 and 2.6.27-7 breaks the battery reading

the new/old problem is maybe caused by the fix of this bug https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/270017

i've made an observation: the battery is only broken in some sessions.
i.e., even with 2.6.27-7, without poll mode, about 2/3 of the time the notebook starts and does not have problems reading battery status until turned off. in the remaining cases, the battery is "lost" shortly after starting and does not come back.
starting the machine on battery or AC power doesn't seem to have any effect on whether the battery can be read.

that leads me to a conclusion that the ACPI interrupt mode is not as broken as we originally thought. maybe some of the updates partially fixed the underlying issue and we won't be needing the poll mode, if only we can figure out how to fix it for good.
(also, it appears that the battery is always available when rebooting from windows)

Problem still exists with the latest updates & kernel with Intrepid.

Sometimes it displays the time to discharge but sometimes it gives an unknown. Quite annoying, will there be a fix for this?

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

This bug still persists in 8.10. The acpi=noirq kernel parameter "fixed" the symptoms, with 2.6.27-11 I still loose the correct battery status WITH the acpi=noirq kernel option, although it takes ~1-2 hours before it happens.

Because bug is closed, with a patch released and then broken, I have opened a new bug report: https://bugs.launchpad.net/ubuntu/+bug/323823

This bug is fixed in Jaunty, thanks.