| Summary: | sys-power/upower - wrong battery status in after resume from suspend | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | optiluca <optiluca> |
| Component: | [OLD] KDE | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | caster, nikoli, qdii |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.freedesktop.org/show_bug.cgi?id=27399 | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=270627 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
optiluca@gmail.com
2011-03-26 18:11:34 UTC
What does "acpi -b" return? I had no acpi executable. After installing the acpi package: acpi -b Battery 0: Discharging, 59%, 00:54:15 remaining This is before any suspend/resuming, and matches what powerdevil has to say After a suspend, the powerdevil indicator goes the opposite way as what it has previously, and shows 100% charge! I guess it's just chance, and is still incorrect. In any case: acpi -b Battery 0: Discharging, 55%, 00:45:48 remaining which is sensible enough. After a further suspend, powerdevil says 93% charge, 46 minutes. And: acpi -b Battery 0: Discharging, 52%, 00:45:00 remaining So the time indication is correct, but the percentage clearly is not. Hope any of this helps :) Let's assume kde-base/powerdevil gets it wrong. I don't know where it gets its ACPI information, but KDE developers should. (Filed kde bug.) Any better luck with kde-4.6.2? No luck I am afraid. The wrongness seems to vary according to the pattern of suspend/resumes/plugging into AC one follows. For example, running on battery, suspending, plugging into AC and then resuming will yield an alleged 100% battery charge. The time indicator seems sensible though, so powerdevil reports something like 99% charge, half an hour of run time... From upstream: ------- Comment #1 From Lamarque V. Souza 2011-04-11 02:09:53 (-) [reply] ------- Powerdevil requests battery information from upower. What does upower says about your battery? The acpi command does not use upower as far as I know. Bug also found at https://bugs.freedesktop.org/show_bug.cgi?id=27399 , and mentioned in http://forums.gentoo.org/viewtopic-t-857650-view-previous.html?sid=86864833a7737fbdc23d9bacda346632 upower -d output is consistent with powerdevil, eg is equally wrong. The "percentage:" entry goes up to 100% after resume. upower -d Device: /org/freedesktop/UPower/devices/line_power_AC native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C09:00/ACPI0003:00/power_supply/AC power supply: yes updated: Thu Apr 14 23:59:08 2011 (195 seconds ago) has history: no has statistics: no line-power online: no Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 vendor: SONY model: 42T4795 serial: 2763 power supply: yes updated: Fri Apr 15 00:02:14 2011 (9 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 53.676 Wh energy-empty: 0 Wh energy-full: 56.1168 Wh energy-full-design: 54.5832 Wh energy-rate: 32.454 W voltage: 11.479 V time to empty: 1.7 hours percentage: 95.6505% capacity: 100% technology: lithium-ion History (charge): 1302818534 95.651 discharging 1302818504 96.286 discharging 1302818474 96.978 discharging 1302818444 97.729 discharging History (rate): 1302818534 32.454 discharging 1302818504 36.914 discharging 1302818474 35.629 discharging 1302818444 36.742 discharging Daemon: daemon-version: 0.9.9 can-suspend: yes can-hibernate no on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no SUSPEND/RESUME luca@optipad ~ $ upower -d Device: /org/freedesktop/UPower/devices/line_power_AC native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C09:00/ACPI0003:00/power_supply/AC power supply: yes updated: Thu Apr 14 23:59:08 2011 (297 seconds ago) has history: no has statistics: no line-power online: no Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 vendor: SONY model: 42T4795 serial: 2763 power supply: yes updated: Fri Apr 15 00:03:59 2011 (6 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 523.26 Wh energy-empty: 0 Wh energy-full: 523.26 Wh energy-full-design: 54.5832 Wh energy-rate: 395.68 W voltage: 11.194 V time to empty: 1.3 hours percentage: 100% capacity: 100% technology: lithium-ion History (charge): 1302818639 100.000 discharging 1302818594 94.130 discharging 1302818564 94.881 discharging 1302818534 95.651 discharging History (rate): 1302818639 395.680 discharging 1302818594 38.772 discharging 1302818564 40.176 discharging 1302818534 32.454 discharging Daemon: daemon-version: 0.9.9 can-suspend: yes can-hibernate no on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no 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%. (In reply to comment #8) > 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: > [...] That looks VERY interesting, you may have found the cause of the problem. :) I copied your comments into the upstream bug report; lets see if the upower developers can work out the details. Any update on this bug? (In reply to qdii from comment #10) > Any update on this bug? indeed, it's middle of 2013 and last comment is from users using UPower in 2011, a lot of bug fixes has happened since re: bugs in battery status showing as per git log please reopen the bug if you still see the need with =sys-power/upower-0.9.21 and up-to-date kernel |
