This is an upstream bug report for Debian's bug # 623019 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623019 gnome-power-manager has stopped displaying the time remaining on my laptop battery. It doesn't appear to be a bug in g-p-m, and perhaps not even in upower but in acpi. This is the proof: $ acpi Battery 0: Discharging, 99%, discharging at zero rate - will never fully discharge. Sometime later I rerun same command $ acpi Battery 0: Discharging, 90%, discharging at zero rate - will never fully discharge. The maintainer of the Debian package for acpi-client says that the bug is in the kernel that has stopped reporting the discharge rate. It is worth noting that I've found a similar bug report in Arch Linux: https://bugs.archlinux.org/task/21917 This led me to realize that the Debian testing kernel (now at 2.6.38) does not have the option CONFIG_ACPI_PROCFS nor CONFIG_ACPI_PROCFS_POWER enabled. That is, no battery directory or info is stored in /proc/acpi/battery/, but in /sys/class/power_supply/battery/...so perhaps the kernel still is not providing all the info it used in the old directory system. I will try compiling the kernel with these options enabled and see if this works. Andres Cimmarusti
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?