HP Compaq 8710W Battery status problems
Ian Smith
smithi at nimnet.asn.au
Sat Jul 12 05:44:39 UTC 2014
On Sat, 12 Jul 2014 01:53:22 +0200, Old Fart wrote:
> Sent: Friday, July 11, 2014 at 4:30 PM
> From: "Old Fart" <flyfisheroregon at mail.com>
> To: freebsd-acpi at freebsd.org
> Subject: Re: HP Compaq 8710W Battery status problems
> Sent: Thursday, July 10, 2014 at 2:31 PM
> From: "Anthony Jenkins" <Anthony.B.Jenkins at att.net>
> To: "Ron Freidel" <flyfisheroregon at mail.com>, freebsd-acpi at freebsd.org
> Subject: Re: HP Compaq 8710W Battery status problems
> <snip>
> > Plugged in and fully charged....
> > acpiconf -i batt
> Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'?
> On my machine the two commands (-i 0 & -i batt) deliver identical
> information, when I posted originally I was tired and bleary
> eyed/headed...
Yes, '-i anyword' gets you battery 0. Consider it a feature :)
> <snip>
> [ajenkins at ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1
> acpiconf: get battery info (1) failed: Device not configured
> Here's the output of acpiconf-i 1
> [ronf at mobile] ~% acpiconf -i 1
> Design capacity: 0 mWh
> Last full capacity: 0 mWh
> Technology: primary (non-rechargeable)
> Design voltage: 0 mV
> Capacity (warn): 0 mWh
> Capacity (low): 0 mWh
> Low/warn granularity: 0 mWh
> Warn/full granularity: 0 mWh
> Model number:
> Serial number:
> Type:
> OEM info:
> State: not present
> Present voltage: unknown
> Just for giggles I did run acpiconf -i 0 & -i 1 without the battery
> installed, saw this...
> [ronf at mobile] ~% acpiconf -i 0
> Design capacity: unknown
> Last full capacity: unknown
> Technology: secondary (rechargeable)
> Design voltage: unknown
> Capacity (warn): 0 mWh
> Capacity (low): 0 mWh
> Low/warn granularity: 0 mWh
> Warn/full granularity: 0 mWh
> Model number:
> Serial number:
> Type:
> OEM info:
> State: not present
> Present voltage: unknown
That looks completely normal for a removed battery.
> [ronf at mobile] ~% acpiconf -i 1
> Design capacity: 0 mWh
> Last full capacity: 0 mWh
> Technology: primary (non-rechargeable)
> Design voltage: 0 mV
> Capacity (warn): 0 mWh
> Capacity (low): 0 mWh
> Low/warn granularity: 0 mWh
> Warn/full granularity: 0 mWh
> Model number:
> Serial number:
> Type:
> OEM info:
> State: not present
> Present voltage: unknown
> Apparently if my sysapses are firing correctly, the os is seeing the
> laptops main battery as secondary and a non existant battery as
> primary.
I believe 'primary' and 'secondary' here are referring to power-source
technology under ACPI, not their relative positions. Why it should
consider battery1 to be 'primary (non-rechargeable)' I don't know,
unless it has provision for using a pack of non-rechargeable batteries?
Or at least, some battery source that the machine won't try to charge?
> A little more info..
>
> Looking at dmesg I see
>
> battery0: <ACPI Control Method Battery> on acpi0
> battery1: <ACPI Control Method Battery> on acpi0
>
> Battery1 does not exist.
No, your battery1 is not installed, but ACPI claims to be ready when you
do install one in the other slot. What does its manual say about this?
My old '98 Compaq 1500c - still running, but under APM rather than ACPI,
only because its ACPI failed to switch to battery when AC was removed -
worked with a second battery also installed, when it replaced the floppy
disk drive. It also showed both battery slots in dmesg just like that.
However, acpiconf showed both as 'secondary (rechargeable)', and did
work properly to work out remaining capacity and time with both fitted,
even properly discharging one until near empty before switching to the
other, and charging them up in turn when AC was reconnected.
Not that this helps your issue of it discharging without updating the
capacity %, time remaining etc. This could be a fault in the embedded
controller (if the Sony uses one of those?) but perhaps more likely a
fault in the coulomb-counter chip in the battery itself. Have you tried
another battery? It's not so uncommon for these chips to fail, or at
least lose any sensible idea of what's going on with the battery, which
sometimes a complete discharge/recharge cycle, or several, _might_ fix.
If it fails similarly with another battery, then it may be an issue with
the ACPI implementation itself on that machine, in which case other
instances of the problem occurring should show up on a search. Are you
running the latest BIOS upgrade for your laptop?
cheers, Ian
More information about the freebsd-acpi
mailing list