From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: In version 2.6.9-1.667 charge and discharge rates for the battery were displayed in /proc/acpi/battery/BAT1/state, however this is no longer the case in 2.6.9-1.678_FC3 and 2.6.9-1.681_FC3 this number is always reported at 0. This causes things like the GNOME battery applet to misreport the present charge in the battery, it will display the charge percentage at the last time the ac power was connected or disconnected. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install specified updated kernel on an acpi enabled laptop. 2. Watch /proc/acpi/battery/BAT1/state not correct report the rate at which the battery is charging or discharging (will report 0 rather than the correct rate) Actual Results: See problem report Expected Results: It should report the rate at which the battery is charging or discharging. Additional info: It seems that this might not be entirely a kernel issue because it seems to now appear in 667, perhaps udev?
I think this bug is a duplicate for #142714 (or vice versa :-) ). I can tell that this problem still exists in kernel 2.6.10-1.737_FC3 and updated FC3.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I have update the kernel to 2.6.12-1.1372-FC3 and still no success. when running with AC adapter connected [dan@certp BAT1]$ cat state present: yes capacity state: ok charging state: discharging present rate: 0 mA remaining capacity: 4000 mAh present voltage: 17344 mV and the listing is the same when I disconnect the AC adapter. The state of AC adapter in /proc/acpi/ac_adapter/ACAD/state is detected correctly.
I have found some info in bug #3851 in bugzilla.kernel.org. The discussed patches are included in 2.6.13-rc3. Is there any possiblity to recompile latest kernel from Development/Rawhide for FC3? I have problems with SELINUX dependencies.
Now I am running "vanilla" 2.6.12-rc3-git7 (with ACPI Debug enabled) and there is big step forward. /proc/acpi/battery/BAT1/state detect when AC adapter is connected and changes state from charging to discharging and vice versa. Another step is that current capacity is decreased when in discharging state and increased when in charging state. Only "present rate" is always set to zero.
(In reply to comment #5) > Now I am running "vanilla" 2.6.12-rc3-git7 (with ACPI Debug enabled) It is 2.6.13-rc3-git7 naturally :-)
(In reply to comment #2) > An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which > may contain a fix for your problem. Please update to this new kernel, and > report whether or not it fixes your problem. > > If you have updated to Fedora Core 4 since this bug was opened, and the problem > still occurs with the latest updates for that release, please change the version > field of this bug to 'fc4'. This bug still occurs in the most recent Fedora Core 4 kernel. > Thank you.
In the last kernel for FC4 (kernel-2.6.12-1.1398_FC4) I see the present rate set to a non-zero value (in both charging and discharging states), but it does not change during the time. And the value for remaining capacity is not updated too.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
This update has partially fixed the problem, as I now see the battery charging and discharging, however there are still points that it gets stuck and won't update. For example it's still reporting 58% capacity even though it's been plugged in all night and the hardware indicator light says it's at full charge. [eryanv@localhost ~]$ cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charging present rate: 2368 mA remaining capacity: 2464 mAh present voltage: 16032 mV However if I disconnect the AC power, then it will jump from 58% to 100% .
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
This update as not fixed the problem. It works as in previous reports. It also looks like this is the same bug as reported in bug #136948
Testing with 2.6.14-1.1644_FC4 the gnome battery charge monitor does not show the battery charge state after a few hours of running after the kernel spits out these messages the battery status no longer works. kernel 2.6.13-1.1532 is the last kernel that worked properly. I'm guessing the reentrancy counter is not getting deincremented or it exiting early. ACPI-0292: *** Error: Looking up [SERN] in namespace, AE_ALREADY_EXISTS ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.GBIF] (Node c20ef5a0), AE_ALREADY_EXISTS ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT ACPI-0213: *** Error: Method reached maximum reentrancy limit (255) ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c20ef460), AE_AML_METHOD_LIMIT
Appears to be fixed in kernel 2.6.14-1.1653_FC4