Bug 8820

Summary: battery charging at impossible rate - Acer Aspire 5580
Product: ACPI Reporter: Andika Triwidada (andika)
Component: BIOSAssignee: Alexey Starikovskiy (astarikovskiy)
Status: REJECTED WILL_NOT_FIX    
Severity: normal CC: acpi-bugzilla
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.22 Subsystem:
Regression: --- Bisected commit-id:
Attachments: result of acpidump -b
Adjust current for Acer notebooks
tested and modified patch

Description Andika Triwidada 2007-07-28 03:32:01 UTC
Most recent kernel where this bug did not occur: none
Distribution: Debian Sid
Hardware Environment: Acer Aspire 5580
Software Environment: Gnome
Problem Description: 

My Acer Aspire 5580 shows normal info on discharging

andika@hokage:~$ cat /proc/acpi/battery/*/*
alarm:                   unsupported
present:                 yes
design capacity:         4000 mAh
last full capacity:      4131 mAh
battery technology:      rechargeable
design voltage:          11100 mV
design capacity warning: 300 mAh
design capacity low:     165 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            PRESPAL
serial number:           217
battery type:            LION
OEM info:                PANASONIC
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            2437 mA
remaining capacity:      448 mAh
present voltage:         10336 mV

But abnormal (?) one when charging:

andika@hokage:~$ cat /proc/acpi/battery/*/*
alarm:                   unsupported
present:                 yes
design capacity:         4000 mAh
last full capacity:      4131 mAh
battery technology:      rechargeable
design voltage:          11100 mV
design capacity warning: 300 mAh
design capacity low:     165 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            PRESPAL
serial number:           217
battery type:            LION
OEM info:                PANASONIC
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            63418 mA
                         ^^^^^^^^
remaining capacity:      256 mAh
present voltage:         10640 mV

Steps to reproduce:

1a. plug in battery, 
1b. disconnect AC charger, 
1c. $ cat /proc/acpi/battery/*/*

2a. ensure battery is not fully charged, 
2b. reconnect AC charger, 
2c. cat /proc/acpi/battery/*/*
Comment 1 Andika Triwidada 2007-07-28 03:35:59 UTC
Created attachment 12187 [details]
result of acpidump -b
Comment 2 Fu Michael 2007-11-12 18:38:15 UTC
Alex, any reponse?
Comment 3 Alexey Starikovskiy 2007-11-13 00:23:13 UTC
Michael, this is known issue of Acer... they try to put negative value into positive only field. And more, field is 64 bit long, but they put sign bit into 16th bit, so we cannot easily detect this...
Andika, do you ran the _latest_ available BIOS ?
Comment 4 Andika Triwidada 2007-11-13 04:21:08 UTC
BIOS just upgraded to version: v1.3223 (Release Date: 01/04/07) but problem still exist. I will try upgrade to newer BIOS version (from file AS5580v3508.WPH) later and report back.
Comment 5 Andika Triwidada 2007-11-14 11:52:12 UTC
Upgraded to 3508 (release date 06/04/07). Doesn't change anything :(
Comment 6 Alexey Starikovskiy 2007-11-14 14:25:33 UTC
Created attachment 13549 [details]
Adjust current for Acer notebooks

Please check if this patch helps...
Comment 7 Andika Triwidada 2007-11-14 22:44:39 UTC
Created attachment 13557 [details]
tested and modified patch

previous display error was on charging, so test should against 0x02

Alexey, thanks for your patch.
Comment 8 Fu Michael 2007-12-09 22:20:37 UTC
(In reply to comment #7)
> Created an attachment (id=13557) [details]
> tested and modified patch
> 
> previous display error was on charging, so test should against 0x02
> 
> Alexey, thanks for your patch.
> 
Andika, does the patch fix your issue?
Comment 9 Andika Triwidada 2007-12-10 00:15:04 UTC
Yes, my patch (attachment id 13557) fixed the issue.(In reply to comment #8)
> (In reply to comment #7)
> > Created an attachment (id=13557) [details] [details]
> > tested and modified patch
> > 
> > previous display error was on charging, so test should against 0x02
> > 
> > Alexey, thanks for your patch.
> > 
> Andika, does the patch fix your issue?
> 

Yes, my patch (attachment id 13557) fixed the issue.

Regards,
Andika
Comment 10 Alexey Starikovskiy 2007-12-10 01:09:37 UTC
Thanks for a patch
Comment 11 Alexey Starikovskiy 2007-12-11 03:20:04 UTC
I think this approach is not good for inclusion into kernel...
It seems that Acer BIOS writers made a mistake -- 
instead of "If (And (Local3, 0x8000))", which is check for negative value
they wrote "If (LAnd (Local3, 0x8000))", which will be true if Local3 is not 0.
Andika, could you please check that removing "L" from the above statement in _BST method of DSDT helps as well?
There is a slightly outdated tutorial on how to do this:
http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
Comment 12 Andika Triwidada 2007-12-11 16:23:26 UTC
(In reply to comment #11)
> I think this approach is not good for inclusion into kernel...
> It seems that Acer BIOS writers made a mistake -- 
> instead of "If (And (Local3, 0x8000))", which is check for negative value
> they wrote "If (LAnd (Local3, 0x8000))", which will be true if Local3 is not
> 0.
> Andika, could you please check that removing "L" from the above statement in
> _BST method of DSDT helps as well?

Confirmed! That make a good result too.
Comment 13 Andika Triwidada 2007-12-12 06:49:12 UTC
Sorry, my test kernel already contain backported version of previous patch. I will do another test.
Comment 14 Zhang Rui 2008-03-23 23:50:37 UTC
Hi, Andika,
any update on this?
Comment 15 Andika Triwidada 2008-04-08 04:18:43 UTC
solution #11 confirmed with kernel from Debian linux-source-2.6.24-5
sorry for late respond
Comment 16 Zhang Rui 2008-04-08 20:38:52 UTC
Alexey,
we should reject it and mark it as WILL_NOT_FIX if this is a bios problem that we won't fix in Linux kernel.
Comment 17 Shaohua 2008-05-22 20:29:09 UTC
From my understanding, we can't push this workaround. This definitily will break other systems. Also, we could apply the workaround in userspace. A UI can do the calculation for the specific machine. I'll mark the bug as WILL_NOT_FIX.