devicekit-power incorrectly reports battery fully charged when connecting AC

Bug #418428 reported by Chris Irwin
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
DeviceKit-Power
Unknown
Medium
devicekit-power (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: gnome-power-manager

When connecting the AC power cord to my laptop, gnome-power-manager sometimes reports the battery is fully-charged. The notification icon appears to be a fully-charged battery with AC cord. The tooltip says something like "Laptop battery fully charged (31%)". Unplugging and replugging a few times will solve the issue.

Sorry, I wasn't quite sure if this is devicekit-power or gpm.

ProblemType: Bug
Architecture: amd64
Date: Tue Aug 25 00:48:25 2009
DistroRelease: Ubuntu 9.10
Package: gnome-power-manager 2.27.5-0ubuntu3
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-6.26-generic
SourcePackage: gnome-power-manager
Uname: Linux 2.6.31-6-generic x86_64

Revision history for this message
In , Sebastien Bacher (seb128) wrote :

*** Bug 23176 has been marked as a duplicate of this bug. ***

Revision history for this message
Chris Irwin (chrisirwin) wrote : gnome-power-manger incorrectly reports battery fully charged when connecting AC

Binary package hint: gnome-power-manager

When connecting the AC power cord to my laptop, gnome-power-manager sometimes reports the battery is fully-charged. The notification icon appears to be a fully-charged battery with AC cord. The tooltip says something like "Laptop battery fully charged (31%)". Unplugging and replugging a few times will solve the issue.

Sorry, I wasn't quite sure if this is devicekit-power or gpm.

ProblemType: Bug
Architecture: amd64
Date: Tue Aug 25 00:48:25 2009
DistroRelease: Ubuntu 9.10
Package: gnome-power-manager 2.27.5-0ubuntu3
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-6.26-generic
SourcePackage: gnome-power-manager
Uname: Linux 2.6.31-6-generic x86_64

Revision history for this message
Chris Irwin (chrisirwin) wrote :
Revision history for this message
Chris Irwin (chrisirwin) wrote : apport-collect data

Architecture: amd64
DistroRelease: Ubuntu 9.10
Package: gnome-power-manager 2.27.5-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-7.27-generic
Uname: Linux 2.6.31-7-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Chris Irwin (chrisirwin) wrote : Re: gnome-power-manger incorrectly reports battery fully charged when connecting AC
Revision history for this message
Chris Irwin (chrisirwin) wrote :
Revision history for this message
Chris Irwin (chrisirwin) wrote :
Revision history for this message
Chris Irwin (chrisirwin) wrote :
tags: added: apport-collected
Revision history for this message
Chris Irwin (chrisirwin) wrote :

Changing to devicekit-power. I ran apport-collect while affected by the issue and it appears that it is devicekit-power that is reporting the erroneous information (i imagine gpm simply states what it is told). Also, gpm does not update charge percentage while in this incorrect state.

affects: gnome-power-manager (Ubuntu) → devicekit-power (Ubuntu)
Revision history for this message
In , Martin Pitt (pitti) wrote :

There's another report about that with this debug info: http://launchpadlibrarian.net/30846231/gnome-power-bugreport.txt

Martin Pitt (pitti)
summary: - gnome-power-manger incorrectly reports battery fully charged when
+ devicekit-power incorrectly reports battery fully charged when
connecting AC
Changed in devicekit-power (Ubuntu):
status: New → Confirmed
Changed in devicekit-power:
status: Unknown → Confirmed
Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

hi

I'm having the same trouble, it seems.
My system is a Dell Latitude 131L laptop, running Karmic amd64. Udated at least once a day, although there haven't been that many updates over the last week or so.

When I pull the plug and re-insert it, the applet seems to be losing track completely, messing up charge states and expected 'time left' completely. Finally it decides that power is now critical and goes into a hibernate (without a cancel-option). Unfortunately suspend/hibernate/resume doesn't work that well anymore since Karmic beta, so this means a crash and hard reboot later.

Right now I'm running off the charger but with my battery 'fully charged' it will stay at less than 8% and not recharge, and no option to break this circle...

enjoy
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

Update: with the pc switched off (not hibernated) I swapped my charger with an identical one from another laptop. Somehow that got the charging started again. I booted and the battery reported to be charging.

Then I used the laptop until a charge of about 10%. When i put the charger back in, immedeately I got a message saying the battery was critically low (below 8%) and the system was going into hibernate.
Hibernate is still broken so crash boom bang went the pc.
I unplugged and replugged my charger and the light on the battery came on, so it seemed to charge.

Booted, and yes it was charging. The estimated time to full charge was way off (several hours), and estimated time running on a full battery even further (something like 6-7 hours... that would be nice, if it were true ;-) )

It seems to me that the data collected concerning charge and decharge times get corrupted somehow. Somtimes after a cold boot there seems to be no power history at all.

cheers
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

update-
Still having problems with this, although a lot has been changed recently in the affected components.

First tried some of the packages in Lucid to see if that would help, but no joy.
Then upgraded to Lucid Alpha completely and checking in for updates at least twice a day.

The problem still comes and goes. I think I've noticed some sort of pattern:

- if I plug in the charger when the battery is still over 10%, it tends to start charging -not always-.

- if the battery is under 10% (I prefer to go as low as 3-5%), plugging in the charger -usually- takes me straight to the 'battery full' status

- if I then unplug and re-plug the charger, I get the 'critically low' message and the pc shuts down, no matter what.
When rebooting after an unexpected shutdown ('battery critically low') I have seen in history/statistics that the 'rate' shows spikes up to 500W or so. Of course that would calculate to a remaining battery capacity of only seconds. The normal rate for this laptop is about 20-50W, no more.
Could it be that there is an error in handling the charge or rate inputs, multiplying the rate by 10 ?

- if the battery is reported as 'fully charged' but in fact is quite empty, after a while it shows a normal increase in cell charge, but only to about 60-80% after which it stabilizes. This graph is drawn in green (charged).
When the battery status is changed to 'charging' again (don't really know what triggers that) the cell charge goes up further to 96% or more and then jumps to 100% / fully charged.

Also, when the battery is reported to be in 'fully charged' state while it is not, I see a new error when booting. This is my BIOS telling me the charger could not be identified (oh?) and therefore the battery may not be charged properly.
Does this have to do with the interaction between the embedded system in the battery, the bios/hw on the motherboard and the way this is managed by devicekit-power and/or gnome power manager?
I do not know much about the more intimate conversation between these pieces of my pc.

Let me know if I can do something else to help you find the cause of this.

cheers
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

Happened again last night.
Plugged the charger in with the battery at around 27%. 'Battery fully charged' came up immediately. Unplugging and plugging in several times didn't change it, so I left it like that (it will charge anyway, I found) and worked on for a while.
When packing up for the day I closed the lid (suspend/resume works again).

This morning I opened the lid, the system resumed just fine and I saw my desktop reappear.
Then it shut down very quickly without any message or possibility to cancel.

After rebooting (I got the 'charger can not be identified' message again from the BIOS) I found that the rate again has a spike at something like 355W where it should be 35-40W.

Any ideas?

cheers
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

Same thing just now, battery is on 40% and is reported as 'fully charged'.
Unplugging and plugging the charger gives several data points of 710W in the Power Statistics / History / Rate graph. For now this seems reproducible behaviour.

cheers
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

Well it's not getting any better.
Plugging in the charger keeps giving a spike in the registered rate that is about exactly 10 times that of the value just before and after.
The battery used to start charging normally every once in a while, so plugging/unplugging could reset the 'battery charged' status. Now it does not do that anymore: it goes to fully charged state regardless of the % of charge left in the battery and stays there.
Whether the battery actually gets charged seems totally random. I have seen it stay on 8% for more than a day, or it starts going up right away, although the official status is 'charged'. When it completely refuses to charge I have to plug in another identical charger to break the lock-up. Once it is charging again, I -usually, not always- can use my own charger to continue.

Also I have seen the charge stop going up at values like 80%, 87% etc. Sometimes it just takes it up to 97% after which it jumps to 100% and seems happy.
In all cases it certainly does not update the statistics, as seen by the charge accuracy graph which does not increase to 100%. The discharge accuracy graph has done so allright.

All 'n all pretty annoying for laptop use, this unpredictable behaviour.

cheers
Tom

Revision history for this message
Tom Louwrier (tom-louwrier) wrote :

Here's something that might help: I switched to another power supply; same brand, smaller, but still.
The power management seems to be working as it should now (fine) but also the errors have gone from my logs (bug 549741).

To me this definitively points to a bug somewhere in the bios, the battery's firmware and/or the power supply (if any).
It may very well even be limited to a specific series of devices.

If that is the case, I don't think there will be a proper fix for it. Maybe addition of a quirk to detect it and activate a workaround (what?).
Of course I'll be happy to do more testing and report the outcome here. Just let me know.

cheers
Tom

Changed in devicekit-power:
importance: Unknown → Medium
Changed in devicekit-power:
importance: Medium → Unknown
Changed in devicekit-power:
importance: Unknown → Medium
Revision history for this message
In , Bugzilla-x (bugzilla-x) wrote :

Does this still happen?

Changed in devicekit-power:
status: Confirmed → Incomplete
Revision history for this message
In , Mike-cloaked (mike-cloaked) wrote :

Is this KDE bug report related?

https://bugs.kde.org/show_bug.cgi?id=326332

Revision history for this message
In , Bugzilla-x (bugzilla-x) wrote :

(In reply to comment #4)
> Is this KDE bug report related?
>
> https://bugs.kde.org/show_bug.cgi?id=326332

No. This bug is only about the charge history. You'll want to file a separate bug and attach the output of "upower -d".

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/upower/upower/issues/61.

Changed in devicekit-power:
status: Incomplete → Unknown
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.