Power manager mistakenly thinks my battery power is critically low, and hibernates -- MSI Wind U100

[Jonathan Reeve]

Binary package hint: gnome-power-manager

When I unplug my laptop, no matter how well my battery is charged (99%, 50%, 30%), I get a message saying "Laptop Battery Critically Low," and telling me the system is about to hibernate. Curiously, there is also a notification telling me the charge state (97%) next to an incorrect estimate of remaining battery power (2 minutes remaining). The system then hibernates.

I should add that my battery is perfectly healthy, and in Karmic and other OSs usually lasts about 4.5 hours.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-power-manager 2.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic i686
Architecture: i386
Date: Thu Apr 8 14:27:16 2010
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Beta i386 (20100318)
MachineType: MICRO-STAR INTERNATIONAL CO., LTD U-100
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=b8487c5f-67c3-44d6-8a7c-dd1be9d439f9 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gnome-power-manager
dmi.bios.date: 10/06/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.3
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: U-100
dmi.board.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.board.version: Ver.001
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.chassis.version: Ver.001
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.3:bd10/06/2008:svnMICRO-STARINTERNATIONALCO.,LTD:pnU-100:pvrVer.001:rvnMICRO-STARINTERNATIONALCO.,LTD:rnU-100:rvrVer.001:cvnMICRO-STARINTERNATIONALCO.,LTD:ct3:cvrVer.001:
dmi.product.name: U-100
dmi.product.version: Ver.001
dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO., LTD

[lupus (lupus78)]

I have exactly the same issue on my MSI Wind U-100.
Even in 9.10 I had that incorrect notification of 2 minutes remaining, just in that version the auto hibernate option was disabled i guess.
for a temporary solution i set the behaviour for critical battery to suspend, so the computer can be waked up faster. Why there is no option to do nothing in the Power Manager options?
Also if it help, i'm happy to atach log files of my battery chargings if some tells me how can i get them.

[Konstantin Lavrov (lacosta)]

The same like in my case with LG X110
See bug # 516023

[Ddall (wm-ddall)]

I have the same problem on a MSI Wind u100x with ubuntu 10.04
-I can boot the pc with the sector adaptater pluged-in, but when I unplug it, no matter what the current level of charge of the battery is, the system hibernate. (just like Jonathan)

-An important precision: If I boot the computer WITHOUT the sector adaptator, the system works properly, and reads the level of charge (but if I plug/unplug the sector adaptator, it goes to hibernation).

Another precision: This bug was fixed 2 or 3 weeks ago but it came back a few days later.

[nomentero (toni7)]

Same insue here on Ahtec NetBook LUG(MSI wind clone)

[Chris Coulson (chrisccoulson)]

Thank you for your bug report. Please stop gnome-power-manager (killall gnome-power-manager), unplug the power cord and then post the output of "upower --dump"

[lupus (lupus78)]

Here is my plugged and unplugged dump!

[Carsten Agger (agger)]

I'm also affected by this on an MSI Wind U135.

Here's the result of upower --dump after killing gnome-power-manager:

Device: /org/freedesktop/UPower/devices/line_power_ADP2
  native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/ACPI0003:00/power_supply/ADP1
  power supply: yes
  updated: Wed Apr 28 09:11:55 2010 (10 seconds ago)
  has history: no
  has statistics: no
  line-power
    online: no

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT1
  vendor: MSI Corp.
  model: MS-N014
  power supply: yes
  updated: Wed Apr 28 09:12:01 2010 (4 seconds ago)
  has history: yes
  has statistics: yes
  battery
    present: yes
    rechargeable: yes
    state: discharging
    energy: 56.0994 Wh
    energy-empty: 0 Wh
    energy-full: 56.0994 Wh
    energy-full-design: 57.72 Wh
    energy-rate: 9.4572 W
    voltage: 12.406 V
    time to empty: 5.9 hours
    percentage: 100%
    capacity: 97.1923%
  History (rate):
    1272438720 9.457 discharging
    1272438718 5.350 discharging
    1272438716 727.438 discharging

Daemon:
  daemon-version: 0.9.1
  can-suspend: yes
  can-hibernate yes
  on-battery: yes
  on-low-battery: no
  lid-is-closed: no
  lid-is-present: yes

[steve.horsley (steve-horsley)]

This procedure fixed it for me (Advent 4211 which is a wind clone):

Press Ctrl-Alt-F2 and use the pop-up to launch gconf-editor.
Navigate to Apps / gnome-power-manager / general.
De-select the option use_time_for_policy.

No need to restart, just close the config editor.

I read in another forum thread that the same problem / workround also work on a Dell Vostro 1310.

[Alfrenovsky (alfredo-fing)]

Same thing for me with a Dell inspiron 1010 (aka mini 10)

In my case the problem is the netbook, not gnome-power-manager.
But because its a common problem. gnome-power-manager seems to be the right place to put a workaround.

If I watch /proc/acpi/battery/BAT1/state I can see that inmediatly after unpluging the power cord, the "present rate" climbs up to 76000 mW. After 4 to 6 seconds drops to 900 and 4 seconds after that starts stabilizing.

The real rate is about 11000 mW.

After unpluging, no matter the remaining capacity, the very high discharging rate reported leads to miscalculation about the remaining time. Very little remaining time, and the netbook hibernates.

One workaround possible is to wait 10 or 20 seconds after any "charging state:" status change before taking any other measure that can lead to an action.
Other workaround can be to ignore the state when it reports a ridiculous out of scale value. In my case I cannot make my netbook use more than 13000 mW, so 75000 is definitivly a bad measured rate.

[Alfrenovsky (alfredo-fing)]

I tried this again with gdm stopped, so changes can happen with no suspending or hibernate.

As you can see here in my battery watch file this time my BIOS took 15 seconds to start giving reasonable values.

My netbook charges at about 35-40 Watts, discharges at 13 Watts. 700 to 750 Watts is more power then my microwave oven uses and should be ignored by any program reading the acpi battery status. When the status file shows stupid values like this one, it should be completely ignored a re-read until is looks sane.

The log file was made with this very simple shell script:

#!/bin/bash
while sleep 1
do
BATSTATE="/proc/acpi/battery/BAT1/state"
read present state charging rate therest << EOState
$(cat $BATSTATE | cut -d":" -f2 | tr "\n" " " )
EOState
echo "time $(date +%H:%M.%S)\t$charging rate: \t$rate"
done

[Alfrenovsky (alfredo-fing)]

My post #12 was bas, there was really 720000 mW and no 72000.

[Oktay Altunergil (oktaya)]

Great. Another MSI Wind specific bug. I have a Medion Akoya which is the same thing as MSI Wind and I have this issue too.

The workaround in Comment #11 regarding setting 'use_time_for_policy' to FALSE works. (Thanks)

[Peter Curtis (pdcurtis)]

I can confirm I am also seeing the problem on an MSI Wind U100 (with original bios) and had found the fix using setting 'use_time_for_policy' to FALSE works. The problem occurs with two different batteries.

Looking at the various charts one can view using the gnome-power-manager gui there seems to be a lot of random large values after a unplugging and plugging in the adapter both in charge and discharge times.

Excerpt from upower --dump shortly after a change shows

.........
   state: discharging
    energy: 22.3998 Wh
    energy-empty: 0 Wh
    energy-full: 22.6218 Wh
    energy-full-design: 24.42 Wh
    energy-rate: 11.3775 W
    voltage: 12.152 V
    time to empty: 2.0 hours
    percentage: 99.0186%
    capacity: 92.0455%
  History (charge):
    1273505398 99.019 discharging
    1273505367 99.460 discharging
    1273505336 99.902 discharging
  History (rate):
    1273505398 11.377 discharging
    1273505367 11.466 discharging
    1273505336 11.400 discharging
    1273505334 13.120 discharging
    1273505332 727.438 discharging

Daemon:
  daemon-version: 0.9.1

............
There seem to be two 'extra' anomalous readings in the rate history which do not match readings in the charge history. The idea of a delay seems a good one until real cause is found especially if it is Bios related.

I hope this can be fixed soon as such problems give Linux a bad name especially with owners of MSI machines after all the problems with Karmic. It took me 4 hours to find a fix and another hour before I came to this bug report hidden amongst many others for the gnome-power-manager. It wold have taken a lot longer if I did not know about and use gconf-editor. I am keeping our other Wind on Jaunty a bit longer which has behaved flawlessly for a year.

[Alfrenovsky (alfredo-fing)]

In Dell mini 10 there are anomalous readings just after plugging or unplugging.

The problem is the BIOS. gnome-power-manager is working fine.
Using change instead time to take actions is not a fix, is a workaround.
Another workaround will be IGNORING absolutelly the acpi battery informatión when the charge/discharge rate exceedes 700Watts (700000mW). I hope this won't break anything cause there are not (i hope) noteboots cosuming that high power

[Peter Curtis (pdcurtis)]

Alfrenovsky

I have not been able to get your script to work [yet] for me but I confirm I can see anomalous readings after both plugging in and removing the power adapter on the output from upower -dump on the MSI Wind.

If this is a common BIOS problem why have we not seen it before. I have been using two Winds under Hardy and Jaunty almost since they came out without any sign of a problem. What has changed in the latest gnome-power-manager? Did it use the charge level in the past? - if so that is a valid solution as it has been proved over many years. Allowing a settling period for what must start off as an analog measurement is also sensible. It must not be too long as we do not want to fail to shut down in time although unplugging with a critical battery is unlikely apart from a fumble.

[Peter Curtis (pdcurtis)]

I have just checked the setup in Jaunty and I find that there are more options under gconf-editor -> apps -> general including a key called invalid_timeout which does exactly what we need - the description is "The invalid timeout is in ms for Power actions. Set longer if you get a 'battery critical' messages when you unplug" In Jaunty it is set to 500 ms. So where has it gone!

I also note that other keys such as can_hibernate and can_suspend are missing and I recall some discussion over these in the past

[Alfrenovsky (alfredo-fing)]

Peter:

Forget my script. I didn't know that "upower -d" gives you the same information. cooked.

I had the same strange remaining times with karmic just after plug/unplug, I didn't report it as a bug before cause I had my hibernation support broken I disable it and I didn't notice the problem.

I was testing to achieve a reasonable timeout after a pluging/unpluging event, and the time needed are up to 15 seconds sometimes. So the wait after reading is not a feasible solution.

The key is to ignore the very high rates. But the rates may vary in different notebooks.
The batteries are supposed to be designed to last some hours.
I think we can ignore the rates that will lead the "design capacity" to drain in less than 10 minutes.
In my case the "desing capacity" is 57720 mWh so I whould ignore 346320mW or up (My strange readings are all about 700000mW)
and its far from my standard real rates 30000 in charging and 5000 to 13000 discharging.

does the arbitrary "drain in less than 10 minutes" fits to all?

[Peter Curtis (pdcurtis)]

Alfrenovsky

The 'drain in 10 minutes' limit might still gives us a potential problem between 10 minutes battery life left and the 2 minutes that is the normal shutdown point on machines that have intermediate readings.

A delay of 30 secs would use some of the hibernate time and need the standard 120 seconds to be increased to say 150 secs so neither are perfect.

I tried a time as short as 10 ms on Jauntyin 'invalid-timeout' and could not reproduce the effect there so I am not sure we have got to the bottom of it. i suspect the answer will be obvious to the writers of upower and gnome-power-manager as it has obviously been an issue in the past and many others have found it and the ' use_time_for_policy' fudge as shown by a google search for use_time_for_policy .

The output of a script such as yours on a higher time resolution for various machines may help them set suitable default parameters if they can not make them available via the Configure Editor.

By the way, I have put a way of making Configure Editor available via the Applications menu and avoiding using a terminal on my 'Wind' web page at www.pcurtis.com/wind.htm#critical_power for users who are frightened of the terminal (95%?!)

[Alfrenovsky (alfredo-fing)]

Peter.

I'm not talking about 10 minutes of remaining time (current capacity / current rate).
What I said is that when (design capacity / current rate) <= 10 minutes We should ignore the data because the "current rate" should be fake.

"design capacity" is the design battery full charge (usually a little higher than the real battery last full charge)

[Jiri Lebl (jiri-lebl)]

I have a zareason computer which is MSI underneath. I worked around the problem by unsetting /apps/gnome-power-manager/general/use_time_for_policy in gconf-editor

[Kent deVillafranca (kdevilla)]

This affects me too, on an MSI X340. Under both Karmic and Lucid, immediately after pulling the plug, it would tell me I only have 2 minutes of battery power remaining. Under Karmic, it was merely annoying...

Under Lucid, it pops up a dialogue box telling me the system is critically low on power and will shut down. And then shuts down, *no matter whether I hit OK or Cancel in the dialogue box*, and even if the time estimate has corrected itself and is now showing the expected 2.5 hours of battery life remaining!

I'm going to go use the use_time_for_policy workaround now, but surely the system should ignore blatantly false time estimates (2 minutes estimated, but battery at 90%)?

[Falcon1 (mike-valk)]

Dell Vostro 1510, Same simptons

[Ciccio (franapoli)]

Same here, msi wind u100. For some reason I only receive the warning but no action is taken. After a while the estimated remaining battery time is correct, so the only "problem" I have is a warning every time I pull the plug.

[Kaj Ailomaa (zequence)]

When fully charged and after I pull out the power cable, Ubuntu claims the power is critically low and starts to hibernate. Before going into hibernation I did see a message claiming I had 55 minutes left of battery power. Laptop is: LG G51-NPR031-xxx. Celeron Processor.

[Kaj Ailomaa (zequence)]

The popup warning message claims I only have 2 minutes left, but when I press the battery power applet, it says 55 minutes.

[Ivan Blinov (illepidus)]

MSI wind u200, Ubuntu 10.04. Bug still exists. Battery power applet and acpi -b works cprrect though.

To stop warning every time you pull the plug, repeat next steps:

Run gconf-editor.
Navigate to Apps / gnome-power-manager / notify.
De-select the option discharging.

No need to restart, just close the config editor.

[David Tombs (dgtombs)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 531190, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Please continue to report any other bugs you may find.