Bug 10094 - ACPI shows wrong values for battery
Summary: ACPI shows wrong values for battery
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Battery (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-24 22:12 UTC by Daniel Barkalow
Modified: 2008-02-28 23:32 UTC (History)
0 users

See Also:
Kernel Version: 2.6.23-gentoo-r8
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg (21.17 KB, text/plain)
2008-02-24 22:13 UTC, Daniel Barkalow
Details
acpidump (99.86 KB, text/plain)
2008-02-24 22:13 UTC, Daniel Barkalow
Details
/proc/acpi/battery/info (probably accurate information) (428 bytes, application/octet-stream)
2008-02-24 22:14 UTC, Daniel Barkalow
Details
/proc/acpi/battery/state (wrong as far as anything useful) (188 bytes, text/plain)
2008-02-24 22:15 UTC, Daniel Barkalow
Details
/proc/acpi/battery/info (no battery actually inserted) (430 bytes, text/plain)
2008-02-25 08:28 UTC, Daniel Barkalow
Details
/proc/acpi/battery/state (no battery at all) (188 bytes, text/plain)
2008-02-25 08:28 UTC, Daniel Barkalow
Details
dmesg with above command line options (30.42 KB, application/octet-stream)
2008-02-26 11:51 UTC, Daniel Barkalow
Details

Description Daniel Barkalow 2008-02-24 22:12:37 UTC
I'm having problems with the battery reporting on my laptop (Lenovo 3000 N100 0768  36U). In particular, the LEDs imply that the battery isn't working at all (and it doesn't power the computer if the AC isn't plugged in), but /proc/acpi/battery/BAT1/state says it's fine. Also, it sometimes thinks there's a battery plugged in even when there isn't one at all (and it makes up some odd values for the battery).

It's always (since 2.6.17, the first kernel I had on here) been slow to update and updates somewhat irregularly, and only a little while after being checked (i.e., the first check will show the state at boot, even if it's changed substantially since then).
Comment 1 Daniel Barkalow 2008-02-24 22:13:33 UTC
Created attachment 14970 [details]
dmesg
Comment 2 Daniel Barkalow 2008-02-24 22:13:59 UTC
Created attachment 14971 [details]
acpidump
Comment 3 Daniel Barkalow 2008-02-24 22:14:45 UTC
Created attachment 14972 [details]
/proc/acpi/battery/info (probably accurate information)
Comment 4 Daniel Barkalow 2008-02-24 22:15:59 UTC
Created attachment 14973 [details]
/proc/acpi/battery/state (wrong as far as anything useful)
Comment 5 Daniel Barkalow 2008-02-25 08:28:05 UTC
Created attachment 14980 [details]
/proc/acpi/battery/info (no battery actually inserted)
Comment 6 Daniel Barkalow 2008-02-25 08:28:32 UTC
Created attachment 14981 [details]
/proc/acpi/battery/state (no battery at all)
Comment 7 ykzhao 2008-02-26 01:50:51 UTC
Hi, Daniel
    It seems that the problem is related with BIOS. The status of the battery is related with the following AML code:
 >    Method (_STA, 0, NotSerialized)
                    {
                        If (LAnd (ECOK (), LEqual (ECDY, Zero)))
                        {
                            If (^^EC0.BAL0)
                            {
                                Sleep (0x14)
                                Return (0x1F)
                            }
                            Else
                            {
                                Sleep (0x14)
                                Return (0x0F)
                            }
                        }
                        Else
                        {
                            Sleep (0x14)
                            Return (0x1F)
                        }
                    }
> 
    From the above AML code we can know that the status of the battery is related with the variable of ECDY. The initial value of ECDY is 5 and it will be decreased when the battery state is updated. But when ECDY is greater than zero, the status will always be present. Only when ECDY is decreased to zero can OS can report the correct stutus of the battery.(ECOK reflects the status of EC controller after EC driver is loaded successfully).
    
Comment 8 ykzhao 2008-02-26 01:57:03 UTC
Hi, Daniel
    Will you please try to boot the system with the option of "acpi.debug_layer=0x10000 acpi.debug_level=0x17" and do the following test? (The battery is unplugged.
    a. cat /proc/acpi/battery/*  five times ( The time interval between twice operations should be more than 5 seconds.)
    b. After the step a is executed, please check whether the status of battery is correct.
   
    After the test is finished, please attach the output of dmesg.
    Thanks.
    
Comment 9 Daniel Barkalow 2008-02-26 11:51:13 UTC
Created attachment 15013 [details]
dmesg with above command line options

I lost count of the exact number of polls I did, but I think it was about 5, and then the status changed correctly to "present: no". Is there similar breakage in the AML for other aspects, where you have to try 5 times before it would stop giving you wrong results?
Comment 10 ykzhao 2008-02-27 19:29:51 UTC
HI, Daniel
   Thanks for the info. 
   From the description there are three problems about the laptop.
   a. OS reports that the battery is still present even when the battery is unplugged.
   b. the laptop can't be booted without AC adapter even when the battery is plugged.
   
   From the log in comment #9 the problem is caused by broken BIOS. Maybe the problem b is related with the BIOS.
   
   Will you please explain the problem b more clearly? 
   Will you please upgrade bios for your laptop and see whether the above problems still exists?
   thanks.
 
Comment 11 Daniel Barkalow 2008-02-28 09:46:43 UTC
Thanks for the help so far on identifying the source of the problem.

Several points:

The first ~5 times I'd use /proc/acpi/battery/*/*, it would give wrong state even about a present battery, so I'm not entirely sure how much to trust any of the reporting I'm using here.

For a little while, the state was jumping straight from almost charged to nearly empty. After that, it would seem to trickle-charge for an appropriate amount of time for actually having been nearly full, and then it would say it was charged, and jump to the nominal capacity.

Last Friday, I let it discharge for a little while and it suddenly shut down. After that, the computer refuses to use that battery (the battery LED comes on green for a little while, and then goes off).

Now, if the battery is plugged in, the ACPI reports (IIRC even after polling 5 times) that the battery is nearly full and present. I'm wondering if it is getting this idea based on a plausible interaction with the battery, or if the AML is nuts about that.

I (today) got a new battery, which has been charging and behaving reasonably, at least so far.

I'd like to try a BIOS update, but I haven't figured out a way to update the BIOS, since I don't have Windows.

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