Dual / Two Batteries, shutdown on empty expansion battery.

[Ebbex]

Binary package hint: gnome-power-manager

Have two fully charged batteries on your laptop. Let the expansion battery on your laptop run out of power. Watch your laptop power down with still 50% charge left.

Ubuntu Edgy: IBM Thinkpad X40.

[Greg Wilkins (gregw-mortbay)]

I can confirm this problem.
I have an IBM Thinkpad a30p which has run hoary and dapper without issue.
Once I upgraded to edgy the system will shutdown with no warning once one battery is empty.

Both batteries are new in the system and both have good capacity. If after the shutdown, I remove the empty battery, the machine is able to boot and run on the other battery and I get the normal notification as the power gets low.

[Greg Wilkins (gregw-mortbay)]

I noticed the topic was changed to say "GPM only recognises first battery".

This is not the case. Both acpi and gpm can see
both my batteries and I have attached a screen shot of the Device Information tab that shows it knows about both batteries.

However, the Charge History, Power History tabs do not appear to know about two batteries

[Michael Zehrer (zehrer)]

I can confirm this with my Thinkpad z60m using an ultrabay advanced battery as the second one.

If both battries are inserted during startup gnome-power-manager detects both and details are shown in the info dialog.

If the ultrabay battery runs out of power gnome-power-manger happily suspends my thinkpad ignoring the main battery.

If I insert the second battery while gnome-power-manager is running it will not be detected.

[Paul Sladen (sladen)]

Michael: Can you do:

  sudo acpi_listen

and capture the event that is sent for each of:

  (a) removing the ultrabay battery
  (b) inserting the ultrabay battery
  (c) removing the internal battery
  (d) inserting the internal battery

[Greg Wilkins (gregw-mortbay)]

This is two removals of the internal batter:

root@brick:/home/gregw# acpi_listen
battery BAT0 00000081 00000000
battery BAT0 00000080 00000000
battery BAT0 00000081 00000001
battery BAT0 00000081 00000000
battery BAT0 00000080 00000000
battery BAT0 00000081 00000001

I get no events for the ultrabay battery, but I started with it not
in the machine.

Next time I reboot I will see if the initial removal is seen

[Michael Zehrer (zehrer)]

Paul:

(a) removing the ultrabay battery
battery BAT1 00000001 00000000

(b) inserting the ultrabay battery
battery BAT1 00000001 00000001
battery BAT1 00000080 00000001

(c) removing the internal battery
battery BAT0 00000081 00000000

(d) inserting the internal battery

battery BAT0 00000080 00000000
battery BAT0 00000081 00000001

If I start without the ultrabay battery inserted, I see no events when I insert or remove the battery.

[Greg Wilkins (gregw-mortbay)]

I restarted with the external battery inserted and now I see events for it.

removal:
battery BAT1 00000001 00000000

insert:
battery BAT1 00000001 00000001

But unlike paul and unlike the internal battery, I only see a single event on insertion.

[Roland Dreier (roland.dreier)]

I just had my thinkpad x60s shutdown when the second battery ran to empty, even though the first battery was completely full. I reported this as a separate bug but it was marked as a duplicate of this one, but I'm not sure what my problem has to do with hotplug of batteries -- both batteries were installed when I booted up and remained installed the whole time I was using my laptop. GPM sees both batteries, and in fact when it displayed the critical low power warning and shut down my laptop, it was also showing a 70% charge with 4 hours of runtime left.

[Greg Wilkins (gregw-mortbay)]

Roland,

I two was a little sceptical that my problem (which is the same as yours) was related to hot plugging of batteries.

But the investigations above have shown that there is at least another issue related to hotplug and the batteries. So it seams a unlikely coincidence that the two new issues with batteries are unrelated.... but they may be.

Also, I think that devices are still "hotplugged" during boot as the same/similar mechanism is used to detect hardware at startup as later on.

[Roland Dreier (roland.dreier)]

I doubt my problem is related to hotplugging. GPM definitely knew about both batteries when it shut down the computer (I had just looked at the battery info a little earlier and saw both batteries)

It seems more likely that there are two bugs that are being tracked in a single bug #.

[Roland Dreier (roland.dreier)]

It seems this has been reported and partially diagnosed upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=361583

Based on that upstream bug's discussion and my own reading of the g-p-m source code, I am confident that my problem is not related to ACPI: it is clear from the g-p-m source that when all battery events are being generated properly, it will still trigger a critical low power shutdown if any one battery becomes empty, even if other full batteries are present in the system.

[Ebbex (eb4x)]

Yep. This wasn't an issue in dapper with the older g-p-m. It's all g-p-m's fault. g-p-m sees both my batteries, and calculates the total time and total charge, but shuts down on one empty battery.

[Matthew Garrett (mjg59)]

Justification: Cripples any machines with multiple batteries, regression from dapper

[Luka Renko (lure)]

I have prepared a test version with a fix mentioned in upstream bug. I have also added some additional debugs just in case if the fix does not work to collect some additional data.

See attached debdiff.

[Luka Renko (lure)]

This is test package for i386. If any of reporters can test it and try to reproduce the bug it would be great.

I would suggest that you do the following to get all logs:

  killall gnome-power-manager
  gnome-power-manager --no-daemon --verbose 2>&1 | tee gpm.log

If problem is fixed, please confirm - if not please attached gpm.log for further inspection.

[Roland Dreier (roland.dreier)]

OK, I am trying the new package now -- it will take a little time for my second battery to run down.

However I am not optimistic that this will fix it: I don't see any changes to gpm-manager.c:battery_status_changed_primary() beyond adding some debug prints. I definitely don't see anything that would make it take any other batteries into account -- so I expect it will still trigger a shutdown when any one battery becomes empty, no matter whether there are other full batteries installed or not.

Anyway I will let you know either way, and include the log if it fails.

[Roland Dreier (roland.dreier)]

OK, as expected my laptop shut down when the second battery ran down and the first battery was still full. I'm attaching the gpm.log as requested.

The output from the new debugging statements in the patch is:

[battery_status_changed_primary] gpm-manager.c:2058 (21:58:06): Laptop battery: critical level:
[battery_status_changed_primary] gpm-manager.c:2059 (21:58:06): charging=0 discharging=1:
[battery_status_changed_primary] gpm-manager.c:2060 (21:58:06): pct_charge=72 remaining=2:

[Luka Renko (lure)]

The problem is that HAL is saying that you have only 2 sec left (remaining), even though it is claiming couple of debugs before that you have 9654 seconds left.

It is very unlikely that we can do a quick hack for edgy to address this for Edgy released (unless upstream author finds some elegant solution), but since percentage_charge looks to be sane, it would probably make sense to switch back to using percentage instead of remaining time for warnings. You can do that by changing the following gconf value:

  /apps/gnome-power-manager/use_time_for_policy

(do not ask me how as I do not use GNOME ;-) )

[Luka Renko (lure)]

Can some of the reporters confirm if above workaround helps?
If yes, we will document this in release notes.

[Greg Wilkins (gregw-mortbay)]

I switched use_time_for_policy off and have just been able to survive the emptying of my second battery and the system is now running on the second battery.

so the work around appears to work.

thanks

[Luka Renko (lure)]

It seems this is more widely spread problem which causes problems both for gnome-power-manager (Ubuntu) as well as guidance-power-manager (Kubuntu).

It looks like that some ACPI events (like unplug of AC, one battery getting empty, or even eject of CD...) can cause battery remaining_time to be "reset" or at least being recalculated.

Since gnome (at least by default) uses remaining_time property for critical action handling, this can cause automatic action (like hibernation or shutdown). In KDE, we have CHARGE_LEVEL_THRESHOLD at 50% (which is a bit high) which prevents critical action if charged above that level.

Related bugs with notes when the action is triggered:
- bug 60442: gnome: one of two batteries is completely discharged (flat)
- bug 64752: kde: one of two batteries is completely discharged (flat)
- bug 67180: gnome: on unplug of AC
- bug 67081: kde: on CD load (may be unrelated)

[Luka Renko (lure)]

Other similar (related?) issues worth mentioning:
- bug 66094: gnome: on unplug of AC (see also duplicate bug 63769 and bug 67180)
- bug 64936: gnome: remaining_time changing randomly (hibernate helps)
- bug 62440: gnome: remaining_time wrong when charging

[Greg Wilkins (gregw-mortbay)]

Also - even with the work around (using % instead of time remaining), there are issues.
If I eject the battery currently in use, the system shutsdown.
If I insert a battery not there at startup, it is not seen.

[Luka Renko (lure)]

Greg, the two issues that you are mentioning now are not directly related to remaining_time, therefore I suggest that you open new bugs for them and please submit "lshal -m" output when reproducing them.

[Riccardo Setti (giskard)]

hello,

there is a fix in CVS, dunno if we are in time for a new upload of gpm.

[Matt Zimmerman (mdz)]

We won't delay the release for this, but if someone attaches the upstream patch it can be a candidate for StableReleaseUpdates

[Oliver Grawert (ogra)]

its attached on teh upstream bug, i'll crae about it for -updates, tollef and i discussed it this morning already :)

[Greg Wilkins (gregw-mortbay)]

This is a serious thing to allow in a "stable" release.
The first many users are going to see of this is their notebook will shutdown without warning in the middle of some vital work.

Restarting their notebook and it will continue as normal (on second battery).

It may take some users MANY cycles to realize there is a problem.
Much important work may be lost and stability feeling of ubuntu will be badly harmed.

This is definitely something that should be in the stable release.

I thought the idea of getting bunnies like me to try the unstable release was to make sure that less-technical users would not get bitten by such issues.

[Luka Renko (lure)]

I would like to point out that the fix mentioned in upstream bug only addresses less problematic part of this issue (bug 62625), but does not fix the root cause of this bug or implement a workaround for it. This is why the upstream bug is not closed yet.

We need to document the workaround for the users of problematic HW that is exposed to remaining_time bug. The workaround is to change gnome-power-manager config to use percentage charged instead of remaining time for automatic actions. See my previous comment regarding that.
I think this should go in release notes of Edgy.

If we are overly concerned by this behaviour (as Greg is in previous post), we could reconsider changing default value in gconf for this and use percentage charged as default.

[jens_acamedia (commercial-acamedia)]

i would just like to add that on my acer 1644 i only have one battery which is for some reason listed as BAT1 under /proc/acpi/battery...

i assume that this is the reason why im suffering from similar problems with gpm...when i unplug AC it always tells me 1 hour remaining (with 3 %) and then doesnt change...if i plug AC back in the values for percetage charged remain incorrect and it tells me i have one hour remaining to recharged (though i only unplugged AC for a couple of minutes this time)...

so this is also a problem for people with only one battery...

[shaggy (slimshaggy)]

ups, i made a dupe
https://launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/68089

[Stu Hood (stuhood)]

There is a patch against CVS upstream at http://bugzilla.gnome.org/show_bug.cgi?id=361583#c28 that fixes this issue, but needs some testing: if anyone here would be willing to recompile to try it out, it'd be appreciated.

Jens: It sounds like your hardware is reporting faulty charge data, or not reporting anything at all... its probably unrelated to this bug.

[meba (jakub-rtfm)]

I will try the patch this week. It's really annoying :)

[meba (jakub-rtfm)]

Hmm, it seems that i need to reinstall whole gnome-common from CVS to use CVS version of power manager. Are anybody willing to create .deb for me?

[shaggy (slimshaggy)]

I simpy turned of the shutdown in the power-manager, cause shuting down the computer eventhough there is a full battery left is really annoying.

But with this there is a chance i do really forget to shutdown in time and loose data, or damage my laptop, who knows.

Please fix this in edgy's power-manager.

[Luka Renko (lure)]

Did you try workaround from comment: https://launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/60442/comments/18

[shaggy (slimshaggy)]

where is the fix?

[shaggy (slimshaggy)]

pardon, didnt see it came upstream

[Game_Ender (game-ender67)]

This issue is fixed in CVS, but the fix has been pack borted and released as a fix for edgy yet? I am curious becuase I am about to upgrade a laptop to edgy, and I don't want to be bitten by this.

[Jim Popovitch (jimpop)]

In Gnome you can run this command to change the "use_time_for_policy" state:

gconftool-2 --type=bool --set
        /apps/gnome-power-manager/use_time_for_policy false

[Lloyd Dewolf (lloydde)]

I encountered this bug today. It was embarrassing ;-) Can we get an edgy maintenance fix for this?

[Jim Popovitch (jimpop)]

Something else to put into the fix is a way to specify when "Low Battery" should be declared. With 2 batteries, and 5+ hours of use, 30% left doesn't qualify for "Low Battery" notifications.

[Jim Popovitch (jimpop)]

See the attached JPG for an example of how a %49 battery can look like you have 20 mins left.

[shaggy (slimshaggy)]

when having two batteries in the system, i'd think the power manager should show two battery graphs in the panel.

[Jim Popovitch (jimpop)]

I have two batteries and GPM shows both in the Device Info tab, however Charge/Power/EstTime History panels do show one graph line. I don't think it is possible to change the Power or EstTime panels to show 2 or more line graphs as it is really the sum that you are interested in, not the individual specs. For instance, how would you display remaining time for 2 batteries? If you had 2 line graphs for remaining time it might display that you had 1.2 hours on one battery and 30 mins on the other.... but what value is that to the end user?

[Lloyd Dewolf (lloydde)]

Bug still exists!

Matt Zimmerman what happened to it being a "candidate for StableReleaseUpdates" ?

ENV: ThinkPad T42p with two batteries
Ubuntu 6.10 (edgy) / gnome-power-manager 2.16.1-0ubuntu3

Shuts down at %81 total battery.
Repro: sometimes, does not always shutdown; somehow on occasion I have got a full drain of both batteries before shutdown (I think)

ADDITIONAL DETAILS

There is 2nd problem of hot plugging which sound like a problem which should be tracked separately. I have not investigated that scenario nor the other unrelated issues late in the bug.
(The best bug management is symptom-based for verifiability.)

[Matt Zimmerman (mdz)]

On Tue, Feb 20, 2007 at 11:45:37PM -0000, foolswisdom wrote:
> Bug still exists!
>
> Matt Zimmerman what happened to it being a "candidate for
> StableReleaseUpdates" ?

As you remarked, this bug hasn't been fixed yet. StableReleaseUpdates is a
process by which a bug fix can be provided as a maintenance update for
users. However, that can't be done until the bug has been isolated and
fixed.

--
 - mdz

[Lloyd Dewolf (lloydde)]

mdz, thank you for the response! I thought (guess, wrongly) because it is fixed in upstream, the issue was isolated and well understood.

Is there a test package someone would like me to try?

Although, the number of people affected are minimal, the symptom is severe. I have visions of some senior business person laptop shutting down at a crucial moment. It seems like a class of problem that Canonical would want to monitor closely.

[Carlos F. (topopardo-deactivatedaccount)]

Bug 66094, similar to this one, is fixed now on Feisty. Just FYI.

[Richard Hughes (richard-hughes)]

Guys, I'm the upstream author. The reason g-p-m does not work with more than one primary battery very well, is that I'm unable to test it. I'm a poor student, with a inexpensive single battery notebook and so cannot add the multi-battery code to the test-suite. I rely on people with multiple batteries to contribute fixes (and code).

See http://hughsient.livejournal.com/17663.html for the work on head - if anybody can donate a shitty multi-battery laptop all this can be fixed in 2-18.

[Michał Mach (michau)]

Cannot donate a laptop to you, but if you're interested in any stack logs or - as last resort - distant access to my machine (ThinkPad X41 with two batteries running Edgy Eft), I'm more than glad to help.

Let me know.

[Richard Hughes (richard-hughes)]

Guys, have you had better luck with 2.19.x? The battery profiling code in 2.19.x should make a lot of these multi-battery issues go away as we profile the system state, not the battery.

[Mark Stosberg (markstos)]

On Thu, 2007-07-05 at 10:07 +0000, Richard Hughes wrote:
> Guys, have you had better luck with 2.19.x? The battery profiling code
> in 2.19.x should make a lot of these multi-battery issues go away as we
> profile the system state, not the battery.

I have a Thinkpad T20 with two batteries. With Feisty, things seem to
work OK. The battery monitor shows me both the battery levels, and I
have definitely run it down past the first battery.

<thinks>

However, I recall using the fix relating to this value:

 /apps/gnome-power-manager/use_time_for_policy

So, the original issue may just be masked for me. However, this
workaround works flawlessly, and I see no reason it couldn't become the
default behavior.

  Mark

>
--
 . . . . 1997-2007: Ten Years of Excellence. . . . . .
   Mark Stosberg Principal Developer
   <email address hidden> Summersault, LLC
   765-939-9301 ext 202 database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[Richard Hughes (richard-hughes)]

/apps/gnome-power-manager/use_time_for_policy needs to be true. It appears the 2-18 and 2-19 code is much more sensible.

[shaggy (slimshaggy)]

fixed in feisty and gutsy

[Ted Gould (ted)]

Reported as fixed. (and the upstream patch has been applied a long time ago)

[Richard Klein (kleinric)]

Hi,

I'm running Ubuntu 9.04, Jaunty on an Asus R1F(and similarly, my father's Asus R1E). I has a hotswap bay with an extra battery. It works fine when the battery runs down with the computer is on, but shuts down when you turn on the computer.
ie:

Battery1 - 90%
Battery2 - 0% (but convenient to leave in the computer)

When I turn on the computer, the power thing pops up saying the battery level is critical and then turns off, even though battery1 is fine. It only does this as you turn on the computer; if i take battery2 out start the computer, then put it back in after ubuntu has settled, then its all ok (thats what i've been doing since feisty). That system works fine if you know battery2 is dead, but its frustrating if you dont know and turn around just in time to see the computer turning off.

Thanks for the help, let me know if i can give you any more info.

Thanks,
ric

[Dejan (dejan-rodiger)]

Hi all,

This bug is not fixed after few years? I am using Ubuntu 10.10 with gnome-power-manager 2.32.0. After first battery is empty it goes to suspend/hibernate...

I am trying /apps/gnome-power-manager/general/use_time_for_policy false to see if this will improve power-management.

[Mark Stosberg (markstos)]

Dejan, the bug status is marked as "Fixed Released". It is possible you have found a new variation. You could start by providing your laptop make and model, and confirming that you can run on just the second battery. (ie: you know the batteries work independently)

[Dejan (dejan-rodiger)]

I have HP EliteBook 8440P. I can get additional battery out and nothing happens, it works on Primary battery and says it has only 1:35 hours remaining. When I add additional battery back in, it says it is now discharging Travel battery and Primary is in state Charged.
So, yes, I can work only on Primary battery and connect/disconnect second battery online. It doesn't go to suspend/hibernate. But when Travel battery is discharged, my system says it will now go into suspend mode.

[Dejan (dejan-rodiger)]

This change to false helped: /apps/gnome-power-manager/general/use_time_for_policy

[moose (snyderra)]

This also happens in 11.10 on a elitebook 8540w

[Dag Rende (dag-s)]

The conf property mentioned above, has changed path.
In Ubuntu 11.10, it is a dconf property with path /org/gnome/settings-daemon/plugins/power/use-time-for-policy.
Use dconf-editor to check and change it.

[Dejan (dejan-rodiger)]

BTW, I tested this property again and it doesn't work on Ubuntu 10.10 and HP Elitebook 8440p

[Jan (janozaurus+ubuntu)]

This bug or a related problems appears to affect Ubuntu up to 13.10 Saucy.

My configuration is a Sony Vaio Pro SVP13 with extended battery. Both batteries were present when the computer was booted, so the issue is not related to hotpluggin. Hibernation is not supported on this laptop and was not used, so the issue is not related to hibernate-resume.

Both batteries can be charged and as long as both are not empty, everything works as expected. However, when one becomes, empty, Ubuntu is shut down (due to critical battery). The computer can be restarted and works fine with from the 2nd battery. However, if the laptop is put to sleep, after resume, Ubuntu decides that the computer must be shut down immediately, which leads to data loss.

I suggest to reopen this bug

[James Ward (jamesward)]

This happens to me after I resume from suspend. If one battery is dead then upon resume, Ubuntu shuts down.

[stevepowell99 (steve-promente)]

same here. Lenovo thinkpad T420s on Saucy / Kubuntu. I have the standard battery and an ultrabay battery.

[tetzlav (tetzlav-web)]

+1

on T410s with kubuntu trusty... :-/

[tetzlav (tetzlav-web)]

i think its more a bug in kde: https://bugs.kde.org/show_bug.cgi?id=253453

[tetzlav (tetzlav-web)]

Here is allready a patch: https://git.reviewboard.kde.org/r/116481/diff/#

[tetzlav (tetzlav-web)]

This patch applied at kde-workspace 4.11.10 and IT WORKS perfectly! :)
https://git.reviewboard.kde.org/r/116481/diff/raw/

[Christoph Grimmer-Dietrich (christoph-grimmer)]

I'm running Ubuntu 17.04 on a Lenovo Thinkpad T460s. My Laptop just shut down when the 2nd battery was empty and the 1st was at about 40% capacity. That really sucks especially since this happend for the first time in a year.

[Facundo Batista (facundo)]

This happens to also to me. I have a Thinkpad T460s with two batterys, I'm using Ubuntu 19.10