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/*/*
Created attachment 12187 [details] result of acpidump -b
Alex, any reponse?
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 ?
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.
Upgraded to 3508 (release date 06/04/07). Doesn't change anything :(
Created attachment 13549 [details] Adjust current for Acer notebooks Please check if this patch helps...
Created attachment 13557 [details] tested and modified patch previous display error was on charging, so test should against 0x02 Alexey, thanks for your patch.
(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?
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
Thanks for a patch
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
(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.
Sorry, my test kernel already contain backported version of previous patch. I will do another test.
Hi, Andika, any update on this?
solution #11 confirmed with kernel from Debian linux-source-2.6.24-5 sorry for late respond
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.
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.