"Critcally low" shown on unplug at 100% full

Bug #516023 reported by Paul Sladen
92
This bug affects 19 people
Affects Status Importance Assigned to Milestone
gnome-power-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: gnome-power-manager

Just had the "Laptop battery critically low" message shown at the point of unplugging the external power cord, despite the battery saying 100% full. This is with:

  gnome-power-manager: 2.29.1-0ubuntu2

Ideally "Critically" should only be used when battery capacity is < 10% full or < 10 minutes remaining.

Revision history for this message
Paul Sladen (sladen) wrote :
Revision history for this message
Konstantin Lavrov (lacosta) wrote :

I can confirm it when testing lubuntu

$ gnome-power-manager --version
Version 2.29.2

My LG X110 is forced to hibernete after being unpluged from AC.

Revision history for this message
Konstantin Lavrov (lacosta) wrote :
Changed in gnome-power-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Konstantin Lavrov (lacosta) wrote :

Today I search in newest bugs for gnome-power-manager and found several similar cases.

At least those new bugs sound very similar.

I decided to post here what I discover till now.

There are laptops that have enormous peak in energy consumption while being plug to or unplugged from AC power.

Look at screenshoot from gnome-power-statistic: energy-rate is more then 0,7kW

When cable was unplugged calculated time-to-empty is wrong and very small. But g-p-m reacts on this event and do what is set in prefs.

To avoid suspend or hibernating I turn off time policy:
gconftool-2 --type bool --set /apps/gnome-power-manager/general/use_time_for_policy false

 In this case 'Critical low battery' event not happen because percentage is correct. But 'Battery discharging' notification still shows wrong minutes and right percentage: 1 minute of battery power remaining (99%)

Actually this energy-rate jump not g-p-m related (I filled bug 531190 against upower), but anyway this behavior of g-p-m is very annoying.

And it was not so with hal

Revision history for this message
Hein van Dam (h-t-vandam) wrote :

The gconftool-2 command solves the problem for my msi Wind. Thanks.

Revision history for this message
Hein van Dam (h-t-vandam) wrote :

The drawback of this solution in my case at least is that I have to use the command after every reboot. As it is indeed rather annoying a proper fix would be very welcome.

Revision history for this message
Alexey Brodkin (alexey-brodkin) wrote :

The gconftool-2 command also helped with MSI Wind U90.
Konstantin, thanks a lot. This issue was a royal pain in ass.

Revision history for this message
David Tombs (dgtombs) wrote :

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.

Revision history for this message
David Tombs (dgtombs) wrote :

Paul: can you specify why this is not a duplicate? Sounds the same to me.

Revision history for this message
Paul Sladen (sladen) wrote :

David: regardless of how crap/invalid the incoming data might be, g-p-m needs to be able to sanity check _itself_ and not generate notifications in illogical situations (eg. 100% full).

Revision history for this message
David Tombs (dgtombs) wrote :

Well the underlying cause is the same between these two bugs, so perhaps a g-p-m task on the other one would be the right solution here?

I'm not sure whether g-p-m should do sanity checking here: what if your battery really will die almost immediately upon unplugging? I've had a laptop that would do that.

Revision history for this message
Roderik (piep0003) wrote :

If g-p-m would just perform even a slight filter for extreme outliers in its data, this would be solved. I have a Medion Akoya (MSI Wind rebrand), and yes whenever I unplug (even after fully charging), apparently the battery reports an extreme power surge (not even sure if it's real, it could also just be a glitch).

Not only does this trigger notifications that the battery is almost empty when it's clearly not, it also throws off the scale of the graphs in the power-statistics window, and the discharge profile has a bunch of erroneous peaks in it.

Filtering them out would be fairly trivial. My normal power consumption seems to hover between 10W and 14W, while the typical peak values generated on unplugging the cable always is in the range of 710-720W. I don't think there are any normal circumstances under which a battery should/would report such a huge leap in power usage, not even when it's near the end of its lifetime and almost immediately dies.

BTW in a related question, does anyone know where g-p-m stores its "charge profile" and "discharge profile" data? I looked for it in several places, without luck. I want to see and try if I can manually remove the huge peak values that are in the discharge profile, because right now it looks like a flat line with two or three peaks towering out of it (because of the scaling of the peaks).

Revision history for this message
Tony Mugan (tmugan) wrote :
Revision history for this message
sid (itissid) wrote :

Why cant the gpm poll the events a few times after a specific event for some interval of time and then make a decision as to what to do. 3-4 seconds is enough for the power-surge to correct itself right?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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