Bug 52111
| Summary: | Incorrect battery levels on HP Folio 13-2000 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Stefan Nagy (stefan.nagy) |
| Component: | Power-Battery | Assignee: | Lan Tianyu (tianyu.lan) |
| Status: | CLOSED INVALID | ||
| Severity: | normal | CC: | lenb, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695634 | ||
| Kernel Version: | 3.7.1 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg log (debian kernel 3.7.1-1~experimental.1)
output of 'lspci -vvnn' output of 'upower --dump' output of 'dmidecode' output of 'acpidump' disassembled ASL source code file (DSDT) |
||
Created attachment 89871 [details]
output of 'lspci -vvnn'
Created attachment 89881 [details]
output of 'upower --dump'
Created attachment 89891 [details]
output of 'dmidecode'
Created attachment 89901 [details]
output of 'acpidump'
Created attachment 89911 [details]
disassembled ASL source code file (DSDT)
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. 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.
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! |
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.