The is described as the following:
When the AC cable is plugged in then sometimes Ubuntu claims that the AC cable is unplugged and the laptop lid light is by result of this dampen.
And sometimes on battery with AC cable unplugged then Ubuntu claims that the AC cable is plugged in.

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.

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.

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.

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.

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.

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 ;)

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.

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.

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.

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.

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!

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.

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)

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.

> 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
?

> 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, seehttp://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.

> 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'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)

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.