Bug 52111 - Incorrect battery levels on HP Folio 13-2000
Incorrect battery levels on HP Folio 13-2000
Status: CLOSED INVALID
Product: ACPI
Classification: Unclassified
Component: Power-Battery
All Linux
: P1 normal
Assigned To: Lan Tianyu
http://bugs.debian.org/cgi-bin/bugrep...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-29 10:40 UTC by Stefan Nagy
Modified: 2013-02-08 17:34 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.7.1
Tree: Mainline
Regression: No


Attachments
dmesg log (debian kernel 3.7.1-1~experimental.1) (54.97 KB, text/plain)
2012-12-29 10:40 UTC, Stefan Nagy
Details
output of 'lspci -vvnn' (11.57 KB, text/plain)
2012-12-29 10:41 UTC, Stefan Nagy
Details
output of 'upower --dump' (1.54 KB, text/plain)
2012-12-29 10:42 UTC, Stefan Nagy
Details
output of 'dmidecode' (12.06 KB, text/plain)
2012-12-29 10:43 UTC, Stefan Nagy
Details
output of 'acpidump' (290.26 KB, text/plain)
2012-12-29 10:45 UTC, Stefan Nagy
Details
disassembled ASL source code file (DSDT) (476.56 KB, text/plain)
2012-12-29 10:47 UTC, Stefan Nagy
Details

Description Stefan Nagy 2012-12-29 10:40:15 UTC
Created attachment 89861 [details]
dmesg log (debian kernel 3.7.1-1~experimental.1)

Since GNOME failed to send my notebook into hibernation I observed the battery values and realized that the reported battery level will never be lower than
2.99967% (according to 'upower --dump') or 2% (according to 'acpi -b'), time remaining never less than about 5 minutes.

The notebook is 6 months old, the affected battery is the genuin HP battery and the notebook's firmware is up to date. I tested the battery several times with the 'HP Unified Extensible Firmware Interface (UEFI) Support Environment' and it always passed.
Comment 1 Stefan Nagy 2012-12-29 10:41:09 UTC
Created attachment 89871 [details]
output of 'lspci -vvnn'
Comment 2 Stefan Nagy 2012-12-29 10:42:17 UTC
Created attachment 89881 [details]
output of 'upower --dump'
Comment 3 Stefan Nagy 2012-12-29 10:43:40 UTC
Created attachment 89891 [details]
output of 'dmidecode'
Comment 4 Stefan Nagy 2012-12-29 10:45:37 UTC
Created attachment 89901 [details]
output of 'acpidump'
Comment 5 Stefan Nagy 2012-12-29 10:47:47 UTC
Created attachment 89911 [details]
disassembled ASL source code file (DSDT)
Comment 6 Stefan Nagy 2013-01-08 23:29:03 UTC
Since my original description isn't really detailed I'm adding some more information:

In general, the reported battery levels seem to be quite accurate. Just when the battery is discharging and reaches a low charging level the reported values (percentage, time remaining) jump up and down until the battery drains and the notebook suddenly shuts down.

Since the reported values are never lower than 2.99967% (according to 'upower --dump') or 2% (according to 'acpi -b'), the battery won't reach a critical charging level as defined in org.gnome.settings-daemon.plugins.power, so GNOME fails to send the notebook into hibernation.

Since I can workaround this problem by changing the values in org.gnome.settings-daemon.plugins.power to meet the reported battery levels I'm quite sure this is no gnome-settings-daemon or UPower bug.

Please tell me if you need more information.
Comment 7 Lan Tianyu 2013-02-04 13:43:33 UTC
hi  Stefan:
            I check that the output presentage from acpi command is "remaining capacity"/"last full capacity". You can check the output of "grep . /proc/acpi/battery/BAT0/*" and find the values of "remaining capacity" and "last full capacity".  These values both came from bios directly and acpi battery just exposes them to user space. So I think this is not a kernel bug.
Comment 8 Stefan Nagy 2013-02-04 14:32:55 UTC
I think you are right: this is not a kernel bug. I tested this on another HP Folio 13-2000 running Windows 7 today and can confirm that Windows is also affected by this bug.

My friend who owns this notebook was never affected by this bug on Windows because the default values for "critical battery" are high enough to avoid this bug: with the default settings Windows sends the notebook into hibernation at 5 percent (!).

After setting the critical battery value to 2 percent I encountered the same problem I'm having with Debian GNU/Linux: after reaching 3 percent the value won't change for quite some time until the battery drains and the notebook suddenly shuts down.

Please set the status to INVALID (seems like I can't do that myself).

Thanks for your help!

Note You need to log in before you can comment on or make changes to this bug.