Bug 140883 - kernel no longer reports battery charge rate
kernel no longer reports battery charge rate
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-25 23:51 EST by Erik Volkman
Modified: 2015-01-04 17:13 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-19 22:40:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Erik Volkman 2004-11-25 23:51:32 EST
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?
Comment 1 Dan Horak 2005-01-11 12:16:18 EST
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.
Comment 2 Dave Jones 2005-07-15 16:18:58 EDT
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.
Comment 3 Dan Horak 2005-07-16 06:07:16 EDT
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.
Comment 4 Dan Horak 2005-07-21 05:47:47 EDT
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.
Comment 5 Dan Horak 2005-07-30 06:14:03 EDT
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.
Comment 6 Dan Horak 2005-07-30 06:16:37 EDT
(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 :-)
Comment 7 Erik Volkman 2005-08-22 17:07:12 EDT
(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.

Comment 8 Dan Horak 2005-08-23 04:20:29 EDT
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.
Comment 9 Dave Jones 2005-09-30 02:54:12 EDT
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.
Comment 10 Erik Volkman 2005-10-06 09:31:55 EDT
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% .
Comment 11 Dave Jones 2005-11-10 15:01:18 EST
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.
Comment 12 Erik Volkman 2005-11-23 12:10:10 EST
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
Comment 13 Kevin DeKorte 2005-11-29 11:00:51 EST
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
Comment 14 Kevin DeKorte 2005-12-18 14:26:27 EST
Appears to be fixed in kernel 2.6.14-1.1653_FC4

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