Bug 27399

Summary: Wrong numbers just after AC unplug
Product: upower Reporter: Michael Biebl <mbiebl>
Component: generalAssignee: Richard Hughes <richard>
Status: RESOLVED DUPLICATE QA Contact:
Severity: critical    
Priority: highest CC: bgamari, caster, dilfridge, freedesktop-bugs, sobukus, tarmo.lindvall
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Michael Biebl 2010-03-31 09:15:30 UTC
Immediately after AC unplug, upower is showing incorrect numbers for remaining time.
In my particular case, the battery is fully charged, I then unplug, and g-p-m pops up a dialog, saying that I have 3 minutes left before my battery is empty (which is obviously bogus). After a short period of time (usually a matter of 30+ secs), the values reported by upower are correct.

This might actually be a kernel/hardware problem, reporting incorrect current_now values (as shown in the referenced downstream bug reports [1][2])

Nonetheless, upower should probably workaround this by either:
a/ having some sanity checks to ignore unreasonable high/low (static) values
b/ ignore current values for say 60secs after ac unplug
c/ compute the mean values for properties like current_now and filter values which exceed a certain ratio
d/ other ideas?


Please also see the relevant downstream bug reports:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571161
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574850
Comment 1 Roberto Luttino 2010-12-24 02:02:04 UTC
The notebook is unusable, it turns off every few minutes and could seriously damage the hard disk.

I tried to download a patch (http://ppa.launchpad.net/brian-rogers/power/ubuntu), the failure was reduced but every now and then reappears.

If this bug is not resolved soon I will be forced to use another operating system in spite of myself ..  ;(
Comment 2 Richard Hughes 2010-12-24 02:48:46 UTC
The importance flag is for the developer to assign priorities, not the reporter. Could you please try with upstream versions of upower and gnome-power-manager please, as Ubuntu include lots of patches that are not upstream. You probably want to check to see if there are any BIOS upgrades available. Thanks.
Comment 3 Roberto Luttino 2010-12-24 09:26:04 UTC
(In reply to comment #2)
> The importance flag is for the developer to assign priorities, not the
> reporter. 
I'm very sorry...
It's the first time that I use a bugtracker.

> Could you please try with upstream versions of upower and
> gnome-power-manager please, as Ubuntu include lots of patches that are not
> upstream. You probably want to check to see if there are any BIOS upgrades
> available. Thanks.

I have a EEEPC 901GO with latest BIOS (2103 from ASUS support site) and Ubuntu 10.10 installed from scratch.

Every now and then my laptop low battery warning (0% when in reality the battery was freshly charged) and switches off.

What logs can help you? I would be very pleased to help you in any way.

In the meantime I'll try this other ppa: https://launchpad.net/~brian-rogers/+archive/power
seems more updated

Thanks for your support,
Roberto Luttino
Comment 4 Thomas Orgis 2010-12-25 10:29:14 UTC
Well, then ... I really would like to see this issue resolved. I hope to help with linking in some noise from users that somehow went into the wrong channels (i.e., did not end up here):

https://bugzilla.redhat.com/show_bug.cgi?id=509190
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/531190
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/665806

This is really a very annoying issue that is making Linux unusable on some machines for a very long time now. At least somewhere in the software stack there must be some kind of workaround, if the root cause is flaky hardware.

Settling if/where there is a bug in upower would be a start.
Comment 5 Thomas Orgis 2010-12-25 10:39:44 UTC
And another one:
http://bugs.gentoo.org/334345

Man, why don't we talk to each other?
Comment 6 talindva 2011-01-12 10:18:26 UTC
From this we can see that hardware and kernel reports right figures when unplugging the powercord:
tarmo@tarmo-hpmini ~ $  cat /proc/acpi/battery/BAT1/info
present:                 yes
design capacity:         2600 mWh
last full capacity:      2383 mWh
battery technology:      non-rechargeable
design voltage:          10800 mV
design capacity warning: 120 mWh
design capacity low:     24 mWh
capacity granularity 1:  0 mWh
capacity granularity 2:  100 mWh
model number:            Primary
serial number:           100000
battery type:            LiOn
OEM info:                Hewlett-Packard
tarmo@tarmo-hpmini ~ $ cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            64269 mW
remaining capacity:      1959 mWh
present voltage:         12548 mV
tarmo@tarmo-hpmini ~ $ cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1260 mW
remaining capacity:      1959 mWh
present voltage:         11789 mV

Here we can see how upower miscalculates remaining battery charge (time to empty 2.2 minutes):
tarmo@tarmo-hpmini ~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_AC0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00/power_supply/AC0
  power supply:         yes
  updated:              Wed Jan 12 14:35:07 2011 (835 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT1
  vendor:               Hewlett-Packard
  model:                Primary
  serial:               100000
  power supply:         yes
  updated:              Wed Jan 12 14:35:13 2011 (829 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              2.383 Wh
    energy-empty:        0 Wh
    energy-full:         2.383 Wh
    energy-full-design:  2.6 Wh
    energy-rate:         65.535 W
    voltage:             12.364 V
    percentage:          100%
    capacity:            91.6538%
    technology:          lithium-ion

Daemon:
  daemon-version:  0.9.1
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:   yes
tarmo@tarmo-hpmini ~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_AC0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00/power_supply/AC0
  power supply:         yes
  updated:              Wed Jan 12 14:50:10 2011 (3 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/PNP0A03:00/PNP0C0A:00/power_supply/BAT1
  vendor:               Hewlett-Packard
  model:                Primary
  serial:               100000
  power supply:         yes
  updated:              Wed Jan 12 14:50:13 2011 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              2.383 Wh
    energy-empty:        0 Wh
    energy-full:         2.383 Wh
    energy-full-design:  2.6 Wh
    energy-rate:         65.535 W
    voltage:             12.43 V
    time to empty:       2.2 minutes
    percentage:          100%
    capacity:            91.6538%
    technology:          lithium-ion

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

Could it be that upower uses very high charging rate as basis of calculation of remaining time (seen in the first battery state)?
I agree with previous comments that this is a critical problem.  This is causing laptop being useless.  When unplugging laptop goes to standby, when waking up, it comes up but immediately hibernates etc... I hope there could be some sort of patch for this version of upower, because it will be used in ubuntu 10.04 for tree years (long term support).  Is there any way I could help in locating the problem?
Comment 7 Andreas K. Hüttel 2011-04-14 16:30:23 UTC
https://bugs.gentoo.org/show_bug.cgi?id=360607

Another related bug report. Here, the numbers seem to be wrong always after resume from suspend.
Comment 8 Andreas K. Hüttel 2011-04-23 12:49:49 UTC
From the Gentoo bug report: 

--- Comment #8 from Lu Ran <hephooey_dev@fastmail.fm> 2011-04-23 19:42:50 UTC ---
I have a W510 with amd64 Gentoo, exactly the same anonying bug, I did some
research and I think it is a bug in the kernel, though upower handle data
differently from hal thus exposed the bug. Here is the problem I find:

When I boot up normally, "cat /sys/.../BAT0/charge_now" gives me something like
this:

7517000

"cat /sys/../BAT0/charge_full" shows

9396000

Use the battery for a while, (I am not sure exactly how to trigger this
reliably though), the number beomes

69350000

and

93960000

Notice the extra "0"! However upower only check charge_full once when it
starts, now it find "energy" calculated from "charge_now" is larger than
"energy_full" calculated from "charge_full", it assume "energe_full" is wrong
and replace the value using "energy" calculated from "charge_now".The battery
capacity become 100% for a while.

Now suspend/resume, the number from "charge_now" and "charge_full" becomes
normal again, but now upower have a cached "energy_full" calculated when
"charge_now" is 10 times larger. The capacity upower calculated will hardly be
larger than 10%.
Comment 9 Richard Hughes 2011-05-17 03:28:37 UTC
I'm pretty sure we work around the kernel bug in new releases -- the problem was tat the kernel sometimes changed the reporting data units between suspend and resume. If this doesn't work with a new kernel and upower, than please reopen. Thanks.
Comment 10 Michael Biebl 2011-05-17 05:41:43 UTC
Hi Richard!

(In reply to comment #9)
> I'm pretty sure we work around the kernel bug in new releases -- the problem
> was tat the kernel sometimes changed the reporting data units between suspend
> and resume. If this doesn't work with a new kernel and upower, than please
> reopen. Thanks.

Which version of the Linux kernel and gnome-power-manager are supposed to have those workarounds?
Comment 11 Valerio Messina 2011-05-22 16:57:56 UTC
ubuntu 11.04 with K2.6.38-8-generic
$ upower --version
UPower client version 0.9.9
UPower daemon version 0.9.9

I got my netpc goes to suspension disconnecting power plug with batteries completely charged.
Comment 12 Ben Gamari 2011-11-24 13:33:33 UTC
Given my own experience, as well as that of others (https://bugs.launchpad.net/ubuntu/+source/upower/+bug/531190), it seems that this is still occurring. Is it possible that this still isn't fixed in upower 0.9.13 running on a 3.0.0 kernel?
Comment 13 jorge.ad.romero 2012-02-13 05:52:14 UTC
I have this problem and we have many comments saying that the issue still occurs, so i am reopening the bug

https://bugs.launchpad.net/ubuntu/+source/upower/+bug/531190
https://bugs.gentoo.org/show_bug.cgi?id=360607
https://bugzilla.redhat.com/show_bug.cgi?id=748240
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571161
Comment 14 David Tombs 2012-07-19 23:27:46 UTC
Appears to be fixed in Ubuntu (see linked Ubuntu report).
Comment 15 Bastien Nocera 2013-10-20 21:49:23 UTC
(In reply to comment #14)
> Appears to be fixed in Ubuntu (see linked Ubuntu report).

Closing as a dupe of 24667, which is the same bug from the same reporter.

*** This bug has been marked as a duplicate of bug 24667 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.