ACPI reports 78% with fully charged battery

Hello there,

My ACPI and KDE Battery Monitor both report my battery as being 78% charged, even though I normally use it plugged in and it should be fully charged. I’ve found a bug report of the same thing in Ubuntu, but it seems to only happen to Sony laptops and I’m using a Lenovo G560. Plus, the bug is pretty old. Does anybody have a clue how to find out if my battery really isn’t charging or if it’s a software problem? And if it’s a software problem, does anyone have an idea of how to fix it?

The bug report is here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177963
It seems to occur with laptops with “smart” battery configuration settings in Windows. As I’ve never had Windows on this computer, that possibility is already shut out.

Thanks a bunch!
Daniel

It might not be the case, but it might need calibrating. Go to the power management section in systemsettings and edit your powersave profile to do nothing when the battery reaches critical levels. Let it run until the laptop turns it’s self off, and recharge fully before powering back up.

67GTA wrote:

>
> It might not be the case, but it might need calibrating. Go to the power
> management section in systemsettings and edit your powersave profile to
> do nothing when the battery reaches critical levels. Let it run until
> the laptop turns it’s self off, and recharge fully before powering back
> up.

Could you expand a bit on the recal process? I’ve got a Toshiba A105 that
has never reset itself to properly report the charge state of a replacement
battery. I thought it was because I went to the extended life battery but
it never really reported the true low/critical level status. At one time,
the laptop would shutdown at 15% charge reported but that has crept up over
time to about 45%. Watching the discharge curve over time, I can see the
impending shutdown by the rapid decrease in the charge level before shutdown
but it would sure be convenient to have the power control see that as well!

Basic issue is that I don’t seem to get any change in the calibration after
running to shutdown followed by a re-charge.


Will Honea

That may not help in your case, but worth a try. After multiple charges/discharges at different levels, the bios/OS can get confused about the reported/actual charge levels of the battery. Calibrating ensures that the battery levels match the bios/OS levels reported by completely draining/recharging the battery. The first boot after completely draining and completely recharging the battery should show a full charge. This can cause symptoms such as the bios/OS reporting incorrect battery levels. Your problem may go deeper than that. You might want to file a bug against acpi/kernel. Another possibility is that you just have a bad battery.

67GTA wrote:

>
> That may not help in your case, but worth a try. After multiple
> charges/discharges at different levels, the bios/OS can get confused
> about the reported/actual charge levels of the battery. Calibrating
> ensures that the battery levels match the bios/OS levels reported by
> completely draining/recharging the battery. The first boot after
> completely draining and completely recharging the battery should show a
> full charge. This can cause symptoms such as the bios/OS reporting
> incorrect battery levels. Your problem may go deeper than that. You
> might want to file a bug against acpi/kernel. Another possibility is
> that you just have a bad battery.

I think your final thought is the real answer. The replacement was a 9-cell
extended life unit for the original 6-cell standard one so I’m thinking the
voltage curve during discharge is different and the hardware is unable to
adjust. I thought the charge state was read from the battery pack itself
but being a (cheap) replacement that may not work. PITA anyway.


Will Honea

I’ve seen several (new) bad batteries. Sometimes the cells will short out. I have a 9 cell battery for my Dell Studio, and it has never shown the right charge info. It has stayed within 5% of the actual charge (not as bad as yours). Does the battery report the right charge in Windows? If so, file a bug against acpi. https://bugzilla.novell.com/index.cgi

Thanks for the tip! I’ll be taking a small trip tomorrow and will discharge the battery completely and then reload it completely… Will report back day after tomorrow :slight_smile:

67GTA wrote:

>
> I’ve seen several (new) bad batteries. Sometimes the cells will short
> out. I have a 9 cell battery for my Dell Studio, and it has never shown
> the right charge info. It has stayed within 5% of the actual charge (not
> as bad as yours). Does the battery report the right charge in Windows?
> If so, file a bug against acpi. https://bugzilla.novell.com/index.cgi

Good thought. I haven’t booted XP in so long I can probably recharge the
battery from dead in the time it will take to update XP :wink:

I think I was spoiled by an older Thinkpad - the battery diagnostics from
IBM were outstanding!


Will Honea

I had fond thoughts of my old IBM Thinkpad (RIP). I haven’t tried them from Lenovo.

On 2010-12-29 22:57, Will Honea wrote:

> I think your final thought is the real answer. The replacement was a 9-cell
> extended life unit for the original 6-cell standard one so I’m thinking the
> voltage curve during discharge is different and the hardware is unable to
> adjust. I thought the charge state was read from the battery pack itself
> but being a (cheap) replacement that may not work. PITA anyway

My (wild) guess is that the battery itself, being, cheap, doesn’t report
correctly.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

Howdy!

Hmm, I tried running the battery down to nothing and charging again before starting and the battery still isn’t shown at 100% - but strangely enough it does reach 79% now, which is 1% higher than before.

Anybody have any other ideas? I’m kind of unsure about making a bug report since I’m the only person who’s found exactly this problem. It’s a fairly new laptop and I use the battery that was shipped with the computer. The consistency of the problem - up until today - leads me to think it could be a bug, but then again… I could be wrong :slight_smile:

Carlos E. R. wrote:

> On 2010-12-29 22:57, Will Honea wrote:
>
>> I think your final thought is the real answer. The replacement was a
>> 9-cell extended life unit for the original 6-cell standard one so I’m
>> thinking the voltage curve during discharge is different and the hardware
>> is unable to
>> adjust. I thought the charge state was read from the battery pack itself
>> but being a (cheap) replacement that may not work. PITA anyway
>
> My (wild) guess is that the battery itself, being, cheap, doesn’t report
> correctly.

Interesting result here. The lappy was indicating about 3% above the charge
level (53%) where it would crap out in Linux (OS 11.3 x86_64) so I rebooted
to Windows XP. It came up showing the same 53% charge and I figured it
would die shortly. 2 hours later, it finally reported “low level” (10%) and
8 minutes after that reported “Critical” and shut itself down nicely. I
plugged it in, booted to XP and let it charge to the “Low” level of 10% then
pulled the plug and rebooted to Linux (on battery). Up comes Linux, then it
hibernated to disk - I forgot that I had the power management set to
hibernate at something like 15% on battery - so I booted up again and got
the power plugged in before it could commit suicide again. Reported battery
charge was 9% - close enough to what Win reported. After a full charge
(100%), I pulled the plug and darned if it didn’t report 100% with a
projected life of 4+ hours!

All I can figure is that there is a BIOS component to the ACPI used by Linux
that XP reset properly where Linux was never able to. This will take some
time to sort out but for now I appear to have restored the usable battery
life to nearly double what it was before I started. Maybe XP is good for
something after all.


Will Honea

Hi
I wonder if adding the grub option acpi_osi=linux may help?


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.24-0.2-default
up 3 days 4:06, 3 users, load average: 0.17, 0.12, 0.04
GPU GeForce 8600 GTS Silent - Driver Version: 260.19.29

That is interesting. Microsoft has managed to do all sorts of shady bios coding with their home brewed aml compiler, and wreak havoc on acpi functions for linux/mac. This was even part of one of their antitrust lawsuits. You may be a victim of it. You might want to read my thread here HOWTO Fix A Buggy DSDT File - Ubuntu Forums The only bad thing now is the custom dsdt support has been dropped from the mainline kernel, and the novell devs decided to let it go also. You would have to compile a custom kernel to apply it if it evens helps in your case. The reasoning for dropping this was to get more people to file kernel bugs upstream instead of just patching them locally. My reasons for using a custom dsdt with that laptop (RIP) were fixed in the opensuse kernel, and passed upstream. Not to get off on a rant, but the patch introduced by the ubuntu devs was never sent upstream.>:(

malcolmlewis wrote:

> I wonder if adding the grub option acpi_osi=linux may help?

Another of those little known/stealth functions - got a quick link to more
info? Man Grub doesn’t tell me much.


Will Honea

At the boot/grub screen where you select the OS, just type in acpi_osi=“Linux” and hit enter. This will temporarily boot with the option. If it helps, we can show you how to make it permanent.

67GTA wrote:

>
> That is interesting. Microsoft has managed to do all sorts of shady bios
> coding with their home brewed aml compiler, and wreak havoc on acpi
> functions for linux/mac. This was even part of one of their antitrust
> lawsuits. You may be a victim of it. You might want to read my thread
> here ‘HOWTO Fix A Buggy DSDT File - Ubuntu Forums’
> (http://ubuntuforums.org/showthread.php?t=1036051) The only bad thing
> now is the custom dsdt support has been dropped from the mainline
> kernel, and the novell devs decided to let it go also. You would have to
> compile a custom kernel to apply it if it evens helps in your case. The
> reasoning for dropping this was to get more people to file kernel bugs
> upstream instead of just patching them locally. My reasons for using a
> custom dsdt with that laptop (RIP) were fixed in the opensuse kernel,
> and passed upstream. Not to get off on a rant, but the patch introduced
> by the ubuntu devs was never sent upstream.>:(

Some interesting info in the thread. The only problem I can see here is
that the perceived low level value appears to creep up over time and your
info would corroborate that it is a BIOS ACPI interface issue. Shutdowns
and such all seem to work. First run is that after the XP session Linux got
an actual 4+ hours of battery life and shut down at the programmed 10%
battery level. Time will tell if that base level creeps up again.

Given the time frames involved, it will take a while to gather any
definitive info but it’s a start. I don’t use the laptop heavily enough to
run through the whole battery cycle more than maybe twice a week normally.


Will Honea

On 2010-12-31 20:53, Will Honea wrote:

> Another of those little known/stealth functions - got a quick link to more
> info? Man Grub doesn’t tell me much.

Because it is not a grub option, but a kernel option.

/usr/src/linux/Documentation/kernel-parameters.txt:

> acpi_osi= [HW,ACPI] Modify list of supported OS interface strings
> acpi_osi=“string1” # add string1 – only one string
> acpi_osi="!string2" # remove built-in string2
> acpi_osi= # disable all strings


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

Carlos E. R. wrote:

> On 2010-12-31 20:53, Will Honea wrote:
>
>> Another of those little known/stealth functions - got a quick link to
>> more info? Man Grub doesn’t tell me much.
>
> Because it is not a grub option, but a kernel option.
>
> /usr/src/linux/Documentation/kernel-parameters.txt:
>
>> acpi_osi= [HW,ACPI] Modify list of supported OS interface
>> strings
>> acpi_osi=“string1” # add string1 – only one
>> string
>> acpi_osi="!string2" # remove built-in string2
>> acpi_osi= # disable all strings
>

Gracias. Ahora lo entiendo. No wonder I couldn’t find it.

So far it has been more of a nuisance than anything else. The vast majority
of my work is on the desktop and the Lenovo box I use is pretty friendly to
Linux so I haven’t had to risk fat fingers in the kernel settings very much.


Will Honea