Bug 33672
Summary: | 2.6.29 regression: g-p-m unable to display battery time remaining | ||
---|---|---|---|
Product: | ACPI | Reporter: | Andres Cimmarusti (acimmarusti) |
Component: | BIOS | Assignee: | acpi_bios |
Status: | CLOSED INVALID | ||
Severity: | normal | CC: | acpi-bugzilla, lenb |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | >= 2.6.32 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
dmidecode
battery under 2.6.27 (ubuntu live cd) battery under 2.6.28 (ubuntu live cd) battery under 2.6.29 (fedora live cd) battery under 2.6.31 (ubuntu live cd) battery under 2.6.32 (ubuntu live cd) debug patch dmesg after patching kernel 2.6.39.2 acpidump log |
Description
Andres Cimmarusti
2011-04-19 04:38:23 UTC
No luck enabling the deprecated CONFIG_ACPI_PROCFS $ cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 0 mA remaining capacity: 6402 mAh present voltage: 10800 mV $ acpi -b Battery 0: Discharging, 97%, discharging at zero rate - will never fully discharge. Naturally charging rate is also reported to be zero by kernel: $ acpi -b Battery 0: Charging, 84%, charging at zero rate - will never fully charge. Created attachment 55062 [details]
dmidecode
useful hardware info (note the battery has issues)
lets get the possible confusion from the user-client out of the picture. please show this info for the kernels in question, which will show exactly what the kernel is exporting. grep . /sys/class/power_supply/*/* grep . /proc/acpi/battery/*/* ideally you can show this information for the old working kernel, as well as the new failing kernel. if you can reproduce this issue using a kernel.org release, that would be ideal, and even better if you can identify the 1st kernel.org kernel that broke. Created attachment 55732 [details]
battery under 2.6.27 (ubuntu live cd)
Created attachment 55742 [details]
battery under 2.6.28 (ubuntu live cd)
Created attachment 55752 [details]
battery under 2.6.29 (fedora live cd)
Created attachment 55762 [details]
battery under 2.6.31 (ubuntu live cd)
Created attachment 55772 [details]
battery under 2.6.32 (ubuntu live cd)
I have tested many kernels (logs attached): gnome power manager estimates time remaining on battery correctly for kernels 2.6.27 and 2.6.28, but starts to fail with 2.6.29. I could not see any difference in the output of the commands you asked between the many kernels, but perhaps I overlooked it. Especially, all kernels reported a value of "0 mA" for discharge rate and field "power_now" does not show up. This is leading me to believe the problem is in upower (g-p-m transitioned from HAL to upower around gnome 2.26 and kernel 2.6.29 - both in Fedora 11). I think HAL had some workarounds for batteries that don't display rates properly...and some of them have yet to be done for upower. In upower's git tree I found the following rather recent commit: http://cgit.freedesktop.org/upower/commit/?id=95ecdb25b26c0f28c43be1f84083c75d90840fa9 Could this be the answer? or should the kernel report my rates and it's misbehaving (even when I thought it was working alright? Thanks I have tested the above commit to upower without success. Version 0.9.10 which includes the patch still does not 'help' g-p-m to display the remaining battery time. Could someone tell me if this is an issue with my battery's driver in the kernel or if upower hasn't yet implemented all the quirks of hal ? hmm, I also don't see any output difference between 2.6.28 and 2.6.29:-( just out of curiosity, is this still a problem with kernel 2.6.39? Problem remains with 2.6.39: $ grep . /sys/class/power_supply/*/* /sys/class/power_supply/ACAD/online:0 /sys/class/power_supply/ACAD/type:Mains /sys/class/power_supply/ACAD/uevent:POWER_SUPPLY_NAME=ACAD /sys/class/power_supply/ACAD/uevent:POWER_SUPPLY_ONLINE=0 /sys/class/power_supply/BAT1/alarm:0 /sys/class/power_supply/BAT1/charge_full:6600000 /sys/class/power_supply/BAT1/charge_full_design:6600000 /sys/class/power_supply/BAT1/charge_now:6138000 /sys/class/power_supply/BAT1/current_now:0 /sys/class/power_supply/BAT1/cycle_count:0 /sys/class/power_supply/BAT1/manufacturer:Hewlett-Packard /sys/class/power_supply/BAT1/model_name:Primary /sys/class/power_supply/BAT1/present:1 /sys/class/power_supply/BAT1/status:Discharging /sys/class/power_supply/BAT1/technology:Li-ion /sys/class/power_supply/BAT1/type:Battery /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_NAME=BAT1 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_STATUS=Discharging /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_PRESENT=1 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_TECHNOLOGY=Li-ion /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_CYCLE_COUNT=0 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_VOLTAGE_NOW=10800000 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_CURRENT_NOW=0 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_CHARGE_FULL_DESIGN=6600000 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_CHARGE_FULL=6600000 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_CHARGE_NOW=6138000 /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_MODEL_NAME=Primary /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_MANUFACTURER=Hewlett-Packard /sys/class/power_supply/BAT1/uevent:POWER_SUPPLY_SERIAL_NUMBER= /sys/class/power_supply/BAT1/voltage_min_design:10800000 /sys/class/power_supply/BAT1/voltage_now:10800000 Created attachment 63292 [details]
debug patch
Please apply this patch. Run "cat /proc/acpi/battery/BAT0/status" and attach the output of the dmesg.
I applied the patch and compiled a new kernel (2.6.39.2): $ uname -a Linux debturion 2.6.39.2-dt.k8-amd64 #1 PREEMPT Wed Jul 6 09:24:55 EDT 2011 x86_64 GNU/Linux However, "/proc/acpi/battery/BAT0/status" does NOT exist! I do have "/proc/acpi/battery/BAT1/state", so the output from this is: $ cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 0 mA remaining capacity: 6534 mAh present voltage: 10800 mV You'll find dmesg attached. Thanks for looking into this. Created attachment 64792 [details]
dmesg after patching kernel 2.6.39.2
From the dmesg, the battery present rate which is returned from the DSDT in the Bios is always zero. This is caused by the hardware or bios. Please attach the output of acpidump. (In reply to comment #10) > I have tested many kernels (logs attached): > gnome power manager estimates time remaining on battery correctly for kernels > 2.6.27 and 2.6.28, but starts to fail with 2.6.29. It is very strange that gpm can estimates remaining time with the preset rate zero. remaining time = remaining capacity / present rate; Created attachment 64882 [details] acpidump log (In reply to comment #17) > From the dmesg, the battery present rate which is returned from the DSDT in > the > Bios is always zero. This is caused by the hardware or bios. > > Please attach the output of acpidump. I've just attached the acpidump. Now, if it is caused by hardware or bios, are you saying this can't be fixed in the kernel? > > I have tested many kernels (logs attached): > > gnome power manager estimates time remaining on battery correctly for > kernels > > 2.6.27 and 2.6.28, but starts to fail with 2.6.29. > It is very strange that gpm can estimates remaining time with the preset rate > zero. > remaining time = remaining capacity / present rate; Yeah, I understand your reservations, but it does work. In fact I've finally found a couple of leads as to why it stopped working for me (and many others whose batteries don't report rates): https://bugs.freedesktop.org/show_bug.cgi?id=24329 It appears that when the major linux distros switched from hal to udev/upower, there was some functionality lost. The fix has apparently been released for upower now: http://cgit.freedesktop.org/upower/commit/?id=2d8358ae4eea4ecaa103891e660a5cdd4c166f5b Broadly, it is just a question of sampling the battery state for a couple of minutes and estimating a rate from there. From the acpidump, I find the dsdt in the bios fixedly returns zero as the battery present rate to kernel. This is bios issue. (In reply to comment #18) > It appears that when the major linux distros switched from hal to > udev/upower, > there was some functionality lost. The fix has apparently been released for > upower now: > > > http://cgit.freedesktop.org/upower/commit/?id=2d8358ae4eea4ecaa103891e660a5cdd4c166f5b > > Broadly, it is just a question of sampling the battery state for a couple of > minutes and estimating a rate from there. So upower can resolve the problem for you in the every kernel version? (In reply to comment #19) > So upower can resolve the problem for you in the every kernel version? Yes, and in fact it has done it. I've pulled upower 0.9.12 from Debian unstable into my Debian testing and battery time predictions are now reported. Since this is a BIOS issue, I guess this is not the kernel's responsibility so the bug should be closed, perhaps? |