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
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 .. ;(
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.
(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
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.
And another one: http://bugs.gentoo.org/334345 Man, why don't we talk to each other?
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?
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.
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%.
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.
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?
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.
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?
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
Appears to be fixed in Ubuntu (see linked Ubuntu report).
(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.