Bug 38452 - Battery status Unlnown after resume
Summary: Battery status Unlnown after resume
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Battery (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Lan Tianyu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 15:34 UTC by Alex Zhavnerchik
Modified: 2012-05-24 08:00 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.0.0-rc5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
debug patch (535 bytes, patch)
2011-07-04 08:18 UTC, Lan Tianyu
Details | Diff
acpi dump (300.83 KB, text/plain)
2011-07-04 09:55 UTC, Alex Zhavnerchik
Details
acpi -V output (484 bytes, text/plain)
2011-07-04 15:45 UTC, Alex Zhavnerchik
Details
dmesg (95.22 KB, text/plain)
2011-07-04 15:46 UTC, Alex Zhavnerchik
Details
DSDT.hex (461.56 KB, text/x-hex)
2012-02-07 07:09 UTC, Lan Tianyu
Details

Description Alex Zhavnerchik 2011-06-28 15:34:01 UTC
Hi

I have two batteries installed in my thinkpad t420s and after resume acpi shows strange information like always different design and last full capacity and shows status as Unknown.

Sysfs also show status as unknown:
> cat /sys/class/power_supply/BAT0/status            
Unknown

while for second battery it shows right status:
> cat /sys/class/power_supply/BAT1/status
Charging

Also sysfs interface shows correct energy_full_design and energy_full for both batteries.

If I boot the system (not resume) all information displays correctly
Comment 1 Lan Tianyu 2011-07-04 08:17:20 UTC
Please attach the output of acpidump.

Apply the debug patch in the upstream latest kernel and test again. Attach the 
output of dmesg.
Comment 2 Lan Tianyu 2011-07-04 08:18:21 UTC
Created attachment 64552 [details]
debug patch
Comment 3 Alex Zhavnerchik 2011-07-04 09:55:40 UTC
Created attachment 64562 [details]
acpi dump

I've attached acpi dump
Comment 4 Alex Zhavnerchik 2011-07-04 15:45:11 UTC
Created attachment 64582 [details]
acpi -V output

"acpi -V" output after resume
Comment 5 Alex Zhavnerchik 2011-07-04 15:46:03 UTC
Created attachment 64592 [details]
dmesg

dmesg output with debug patch after resume
Comment 6 Lan Tianyu 2011-07-05 03:20:02 UTC
From dmesg, The BAT0 status had not changed since booting up. 

(In reply to comment #0)
> If I boot the system (not resume) all information displays correctly.
Did this happen in the process?

Please attach the output of following before and after resuming. 
"cat /sys/class/power_supply/BAT0/charge_full_design"
"cat /sys/class/power_supply/BAT0/charge_full"
"cat /sys/class/power_supply/BAT0/charge_now"
Comment 7 Alex Zhavnerchik 2011-07-05 12:05:25 UTC
There are several strange thing:
1. /sys/class/power_supply/BAT*/status cat be "Unknown" after fresh boot or resume randomly (once "Unknown" for BAT0 or other times for BAT1)
2. After resume if I work on batteries (AC adaptor unpluged) for example BAT0 doesn't have /sys/class/power_supply/BAT0/charge_now but has /sys/class/power_supply/BAT0/energy_now. Same situation with charge_full and charge_full_design. But BAT0 has status "Discharging".  While BAT1 has status "Unknown" and charge_now, charge_full and charge_full_design in place.

Seems charge_full, charge_full_design, charge_now contain same information after fresh boot and after resume (on AC adaptor). On battery energy_now, energy_full and energy_full_design contain same information as charge_full, charge_full_design, charge_now used to.
Comment 8 Lan Tianyu 2011-07-06 02:14:36 UTC
(In reply to comment #7)
> 2. After resume if I work on batteries (AC adaptor unpluged) for example BAT0
> doesn't have /sys/class/power_supply/BAT0/charge_now but has
> /sys/class/power_supply/BAT0/energy_now. Same situation with charge_full and
> charge_full_design. But BAT0 has status "Discharging".  While BAT1 has status
> "Unknown" and charge_now, charge_full and charge_full_design in place.
Whether charge_now or energy_now is applied depends on the unit of the battery preset rate. When the unit is "mW", energy_now is applied. When the unit is "mA", charge_now is applied. The same for charge_full and charge_full_design.

"cat /proc/acpi/battery/BAT*/*" can be used to identify the unit.

You can attach the output of "cat /proc/acpi/battery/BAT*/*" instead of previous operation.

> There are several strange thing:
> 1. /sys/class/power_supply/BAT*/status cat be "Unknown" after fresh boot or
> resume randomly (once "Unknown" for BAT0 or other times for BAT1)
The status is returned from the method "_BST" in the DSDT. This result depends on the hardware. Is there newer bios version? Dose it work correctly on the Windows?
Comment 9 Alex Zhavnerchik 2011-07-06 17:20:49 UTC
BTW, maybe this issue has impact on resume process, BAT0 shows that it's completely discharched and system reboots just fater resuming, while BAT1 has 75%
Comment 10 Lan Tianyu 2011-07-13 06:10:32 UTC
Update your firmware to the latest one. It is possible to do the update using CD images loaded from grub, if thinkwiki.org does not have the info on how to do it, ask in the linux-thinkpad mailing list.
Comment 11 Alex Zhavnerchik 2011-07-15 23:34:27 UTC
Do you mean BIOS or what firmware?
Comment 12 Lan Tianyu 2011-07-16 05:42:50 UTC
http://www.thinkwiki.org/wiki/BIOS_Upgrade

Update BIOS and ECP
Comment 13 Alex Zhavnerchik 2011-07-19 21:24:11 UTC
I've upgraded BIOS and ECP and still see:
> cat /sys/class/power_supply/BAT0/status 
Charging
> cat /sys/class/power_supply/BAT1/status 
Unknown
Comment 14 Lan Tianyu 2011-07-27 02:00:35 UTC
Please attach output of the dmesg.
Comment 15 Zhang Rui 2012-01-18 05:22:49 UTC
Tianyu, what's the status of this bug?
Comment 16 Zhang Rui 2012-02-02 02:55:36 UTC
ping...
Comment 17 Lan Tianyu 2012-02-07 07:09:27 UTC
Created attachment 72308 [details]
DSDT.hex

Please override the DSDT.hex and reproduce the bug with the previous debug patch after running "echo 1 > /sys/module/acpi/parameters/aml_debug_output".
And then attach the output of the dmesg.

http://www.lesswatts.org/projects/acpi/overridingDSDT.php
Comment 18 Zhang Rui 2012-05-24 08:00:52 UTC
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem still exists in the latest upstream kernel.

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