Funny battery values (nx6325)
Joerg Wunsch
remi# acpiconf -i 0
Design capacity: 279 mAh
Last full capacity: 279 mAh
Technology: secondary (rechargeable)
Design voltage: 10800 mV
Capacity (warn): 14 mAh
Capacity (low): 3 mAh
Low/warn granularity: 100 mAh
Warn/full granularity: 100 mAh
Model number: Primary
Serial number: 00784 2006/10/04
Type: LIon
OEM info: Hewlett-Packard
State: high
Remaining capacity: 99%
Remaining time: unknown
Present rate: 0 mA
Voltage: 12424 mV
The battery is declared as 55 Wh, which would correspond to 5.1 Ah
(probably 3 x 2 x 18650 cells).
When unplugging the AC supply, I get:
remi# acpiconf -i 0
Design capacity: 279 mAh
Last full capacity: 279 mAh
Technology: secondary (rechargeable)
Design voltage: 10800 mV
Capacity (warn): 14 mAh
Capacity (low): 3 mAh
Low/warn granularity: 100 mAh
Warn/full granularity: 100 mAh
Model number: Primary
Serial number: 00784 2006/10/04
Type: LIon
OEM info: Hewlett-Packard
State: discharging
Remaining capacity: 98%
Remaining time: 0:08
Present rate: 2064 mA
Voltage: 11870 mV
I'm not sure whether the "remaining time" is realistic or not. In the
past (FreeBSD 6.x), it used to immediately shut down when unplugging
AC since the battery state was always unknown. Now, FreeBSD 8.x is
the first version that actually manages to survive running on
batteries.
This is an HP/Compaq nx6325.
Any clues how to fix these values?
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Nate Lawson
> Funny battery configuration with 8-stable:
>
> remi# acpiconf -i 0
> Design capacity: 279 mAh
> Last full capacity: 279 mAh
> When unplugging the AC supply, I get:
>
> State: discharging
> Remaining capacity: 98%
> Remaining time: 0:08
> Present rate: 2064 mA
^^^^^^^
> Voltage: 11870 mV
>
> I'm not sure whether the "remaining time" is realistic or not. In the
> past (FreeBSD 6.x), it used to immediately shut down when unplugging
> AC since the battery state was always unknown. Now, FreeBSD 8.x is
> the first version that actually manages to survive running on
> batteries.
>
> This is an HP/Compaq nx6325.
>
> Any clues how to fix these values?
Fix the query for present rate to not return 2A. Perhaps a problem
reading the EC.
--
Nate
Joerg Wunsch
> > When unplugging the AC supply, I get:
> >
> > State: discharging
> > Remaining capacity: 98%
> > Remaining time: 0:08
> > Present rate: 2064 mA
> ^^^^^^^
> > Voltage: 11870 mV
> > Any clues how to fix these values?
> Fix the query for present rate to not return 2A. Perhaps a problem
> reading the EC.
I think the 2 A are realistic. With a 5100 mAh capacity, it should
result in somewhat more than 2 hours of run time (maybe more if the
laptop eventually goes idle, and reduces CPU speed).
What isn't realistic though is that the capacity (both, "design
capacity", as well as "last full capacity") is given as just 279 mAh.
Should I provide any ACPI dump files?
I'm not sure whether there are any ACPI BIOS updates available for
that computer. I've always got a hard time finding them on the HP
website. They are telling me everything about Windows device drivers,
Windows 7 upgrades, and other completely uninteresting (to me) items,
but nothing about BIOS/firmware upgrades.
Garrett Cooper
> As Nate Lawson wrote:
>
>> > When unplugging the AC supply, I get:
>> >
>> > State: discharging
>> > Remaining capacity: 98%
>> > Remaining time: 0:08
>> > Present rate: 2064 mA
>> ^^^^^^^
>> > Voltage: 11870 mV
>
>> > Any clues how to fix these values?
>
>> Fix the query for present rate to not return 2A. Perhaps a problem
>> reading the EC.
>
> I think the 2 A are realistic. With a 5100 mAh capacity, it should
> result in somewhat more than 2 hours of run time (maybe more if the
> laptop eventually goes idle, and reduces CPU speed).
If you were pulling 2 A, that's be the same approximate amount as many
2 x 1U servers. Nate's right -- something is wrong there (this is
particularly true if you're in Europe because you'd be pulling less
current per device as the voltage is actually 240V RMS based, not 120V
RMS based).
> What isn't realistic though is that the capacity (both, "design
> capacity", as well as "last full capacity") is given as just 279 mAh.
>
> Should I provide any ACPI dump files?
>
> I'm not sure whether there are any ACPI BIOS updates available for
> that computer. I've always got a hard time finding them on the HP
> website. They are telling me everything about Windows device drivers,
> Windows 7 upgrades, and other completely uninteresting (to me) items,
> but nothing about BIOS/firmware upgrades.
HTH,
-Garrett
Joerg Wunsch
> > I think the 2 A are realistic. With a 5100 mAh capacity, it should
> > result in somewhat more than 2 hours of run time (maybe more if the
> > laptop eventually goes idle, and reduces CPU speed).
> If you were pulling 2 A, that's be the same approximate amount as
> many 2 x 1U servers.
Remember, this is measured at 10.8 V (or whatever the actual value is)
battery voltage... The laptop is running on batteries here, how
should it be able to measure the mains voltage/current? (Despite, the
mains part of the supply is completely decoupled by the PSU.)
This is what I'm getting on an old TP600E machine:
dhcp208# acpiconf -i 0
Design capacity: 34560 mWh
Last full capacity: 14080 mWh
Technology: secondary (rechargeable)
Design voltage: 10800 mV
Capacity (warn): 1728 mWh
Capacity (low): 345 mWh
Low/warn granularity: 1 mWh
Warn/full granularity: 1 mWh
Model number: ThinkPad Battery
Serial number:
Type: LION
OEM info: IBM Corporation
State: discharging
Remaining capacity: 99%
Remaining time: 1:18
Present rate: 10641 mW
Voltage: 11850 mV
10.6 W / 11.85 V = 0.9 A (the machine was idle here)
No idea why the Thinkpad is returning Watts instead of Amperes, as
most other ACPI BIOSes do.
Ian Smith
> As Garrett Cooper wrote:
>
> > > I think the 2 A are realistic. With a 5100 mAh capacity, it should
> > > result in somewhat more than 2 hours of run time (maybe more if the
> > > laptop eventually goes idle, and reduces CPU speed).
>
> > If you were pulling 2 A, that's be the same approximate amount as
> > many 2 x 1U servers.
>
> Remember, this is measured at 10.8 V (or whatever the actual value is)
> battery voltage... The laptop is running on batteries here, how
> should it be able to measure the mains voltage/current? (Despite, the
> mains part of the supply is completely decoupled by the PSU.)
That's right, 2A * 11V = ~22W which sounds perfectly reasonable. My T23
on battery draws about 24W @1133MHz idle, about 12W @733MHz, which I've
verified as my house supply is 12V, and on AC these draw metered 3.0 and
1.5A respectively, ie 36W and 18W @12V, allowing inverter inefficiency.
> This is what I'm getting on an old TP600E machine:
>
> dhcp208# acpiconf -i 0
> Design capacity: 34560 mWh
> Last full capacity: 14080 mWh
> Technology: secondary (rechargeable)
> Design voltage: 10800 mV
> Capacity (warn): 1728 mWh
> Capacity (low): 345 mWh
Which are 5% and 1% of nominal capacity, commonly used values.
> Low/warn granularity: 1 mWh
> Warn/full granularity: 1 mWh
Same on my T23. cf below to your nx6325 values.
> Model number: ThinkPad Battery
> Serial number:
> Type: LION
> OEM info: IBM Corporation
> State: discharging
> Remaining capacity: 99%
> Remaining time: 1:18
> Present rate: 10641 mW
> Voltage: 11850 mV
>
> 10.6 W / 11.85 V = 0.9 A (the machine was idle here)
Looks about right to me.
> No idea why the Thinkpad is returning Watts instead of Amperes, as
> most other ACPI BIOSes do.
Same on the T23. Likely depends on both the EC and the in-battery chip,
but there must be an order of magnitude miscalculation 'somewhere'?
Requoting your original:
> The battery is declared as 55 Wh, which would correspond to 5.1 Ah
> (probably 3 x 2 x 18650 cells).
Sounds right. My T23 battery is rated at 43200mWh design capacity.
> When unplugging the AC supply, I get:
>
> remi# acpiconf -i 0
> Design capacity: 279 mAh
> Last full capacity: 279 mAh
These are obviously completely silly, and should be more like 5100mAh as
you observed. ie, they're something like 1/18 of their proper value,
perhaps 1/20?
> Technology: secondary (rechargeable)
> Design voltage: 10800 mV
> Capacity (warn): 14 mAh
> Capacity (low): 3 mAh
These are 5% and 1% of the silly value above.
> Low/warn granularity: 100 mAh
> Warn/full granularity: 100 mAh
About 9mWh, further showing how crook the capacity values are.
> Model number: Primary
> Serial number: 00784 2006/10/04
> Type: LIon
> OEM info: Hewlett-Packard
> State: discharging
> Remaining capacity: 98%
> Remaining time: 0:08
> Present rate: 2064 mA
> Voltage: 11870 mV
This shows the remaining time calculation using these wrong capacity
values. 0:08 times ~18 = 146m = 2:26 which sounds much more likely.
What happens if you let it discharge; how long do you really get?
cheers, Ian
Joerg Wunsch
> >Design capacity: 279 mAh
> >Last full capacity: 279 mAh
> Is this consistent or does it vary from boot to boot or if you
> disconnect and reconnect the battery?
Currently, my wife is on a business trip with that machine.
Hopefully, I'll also get a statement about how long it lasts on
battery once she is back ;-), and I'll re-check those values then.
> >The battery is declared as 55 Wh, which would correspond to 5.1 Ah
> >(probably 3 x 2 x 18650 cells).
>
> But is also over 3 years old. Almost everything you do to LiION
> batteries makes their capacity drop.
That's right, but it wouldn't be supposed to affect the "Design
capacity", would it? ;)
Can anybody tell where these values actually come from? I could
perhaps even build a small microcontroller gadget, in order to query
the battery for its values offline (using I涎 aka SMbus) in order to
see where the mistake might be.
Peter Jeremy
>Funny battery configuration with 8-stable:
>
>remi# acpiconf -i 0
>Design capacity: 279 mAh
>Last full capacity: 279 mAh
Is this consistent or does it vary from boot to boot or if you
disconnect and reconnect the battery?
>Serial number: 00784 2006/10/04
...
>The battery is declared as 55 Wh, which would correspond to 5.1 Ah
>(probably 3 x 2 x 18650 cells).
But is also over 3 years old. Almost everything you do to LiION
batteries makes their capacity drop. Whilst 279mAh is probably
a bit unrealistic, I wouldn't be at all surprised if the real
capacity was 2790mAh. (Having ACPI values be out by exactly an
order of magnitude seems fairly common - I've yet to see a system
where at least one value wasn't reported as 10x or 0.1x the
actual value).
>Present rate: 2064 mA
>Voltage: 11870 mV
These numbers seem realistic. Your best bet is to see how long the
system lasts on battery. (If you regularly run on battery, you should
probably install some monitoring tools such as sysutils/battmond and
sysutils/xbattbar).
--
Peter Jeremy
Alexandre "Sunny" Kovalenko
> As Peter Jeremy wrote:
>
> > >Design capacity: 279 mAh
> > >Last full capacity: 279 mAh
>
> > Is this consistent or does it vary from boot to boot or if you
> > disconnect and reconnect the battery?
>
> Currently, my wife is on a business trip with that machine.
> Hopefully, I'll also get a statement about how long it lasts on
> battery once she is back ;-), and I'll re-check those values then.
>
> > >The battery is declared as 55 Wh, which would correspond to 5.1 Ah
> > >(probably 3 x 2 x 18650 cells).
> >
> > But is also over 3 years old. Almost everything you do to LiION
> > batteries makes their capacity drop.
>
> That's right, but it wouldn't be supposed to affect the "Design
> capacity", would it? ;)
>
> Can anybody tell where these values actually come from? I could
> perhaps even build a small microcontroller gadget, in order to query
> see where the mistake might be.
>
You can dump your ASL (see Handbook for instructions) and search for
something like:
Method (_BIF, 0, NotSerialized)
{
If (\_SB.PCI0.SBRG.ECD.BTIN)
{
Noop
Return (BIFF)
}
Else
{
Acquire (ECMX, 0xFFFF)
// *** This is power unit (0 - mWh/mW, 1 - mAh/mA)
Store (\_SB.PCI0.SBRG.ECD.BIF0 (), Index (BIFF, 0x00))
// *** This is the design capacity in units above
Store (\_SB.PCI0.SBRG.ECD.BIF2 (), Index (BIFF, 0x01))
Store (\_SB.PCI0.SBRG.ECD.BIF2 (), Index (BIFF, 0x02))
Store (\_SB.PCI0.SBRG.ECD.BIF3 (), Index (BIFF, 0x03))
Store (\_SB.PCI0.SBRG.ECD.BIF4 (), Index (BIFF, 0x04))
Store (\_SB.PCI0.SBRG.ECD.BIF5 (), Index (BIFF, 0x05))
Store (\_SB.PCI0.SBRG.ECD.BIF6 (), Index (BIFF, 0x06))
Store (\_SB.PCI0.SBRG.ECD.BIF7 (), Index (BIFF, 0x07))
Store (\_SB.PCI0.SBRG.ECD.BIF8 (), Index (BIFF, 0x08))
Release (ECMX)
Return (BIFF)
}
}
and try to track down where the actual values came from. Chapter 10 of
the ACPI specification (http://www.acpi.info/spec.htm) should provide
you with more information on the subject.
The contents of the method above came from some ASL I had laying around
-- yours will likely be different. The important part is the returned
package that contains values in the specific sequence.
HTH,
--
Alexandre Kovalenko (Олександр Коваленко)
Ian Smith
> As Peter Jeremy wrote:
>
> > >Design capacity: 279 mAh
> > >Last full capacity: 279 mAh
>
> > Is this consistent or does it vary from boot to boot or if you
> > disconnect and reconnect the battery?
Or try another battery?
> Currently, my wife is on a business trip with that machine.
> Hopefully, I'll also get a statement about how long it lasts on
> battery once she is back ;-), and I'll re-check those values then.
>
> > >The battery is declared as 55 Wh, which would correspond to 5.1 Ah
> > >(probably 3 x 2 x 18650 cells).
> >
> > But is also over 3 years old. Almost everything you do to LiION
> > batteries makes their capacity drop.
Except keeping spares in the fridge, but not the freezer.
> That's right, but it wouldn't be supposed to affect the "Design
> capacity", would it? ;)
It wouldn't be supposed to :) caveat: I've only 5.5 sources to hand.
acpiconf -i does no calculations, just prints what's given by
if (ioctl(acpifd, ACPIIO_CMBAT_GET_BIF, &battio) == -1)
err(EX_IOERR, "get battery info (%d) failed", num);
printf("Battery %d information\n", num);
if (battio.bif.units == 0)
pwr_units = "mWh";
else
pwr_units = "mAh";
etc, also answering mWh vs mAh display question. Tracing back through
acpi_cmbat_get_total_battinfo in acpi_cmbat.c indicates that calculaing
remaining time does uses last full capacity, but from there back through
acpi_cmbat_get_bst and acpi_cmbat_get_bif it's all just retrieval, from
acpi packages of _BST and _BIF .. presumably updated somehow via the EC,
but I'm in way over my head already ..
> Can anybody tell where these values actually come from? I could
> perhaps even build a small microcontroller gadget, in order to query
> the battery for its values offline (using I涎 aka SMbus) in order to
> see where the mistake might be.
Most of it must be stored in the in-battery chip, but I don't know where
specs may be, or even whether they all use same protocols. Sounds like
some fun, snooping EC <-> battery chatter and reverse engineering that -
assuming it occurs on an accessible smbus? - but maybe there's something
in the ASL that might be bent? Peter's factor of 10 sounds plausible.
I'm interested in this because my T23 battery is just about dead, only
sometimes taking a charge now - that or the charging circuit is dodgy,
which I'll find out when the new battery arrives.
cheers, Ian
Kevin Oberman
> From: Ian Smith <smi...@nimnet.asn.au>
> Sender: owner-fre...@freebsd.org
FWIW, IBM/Lenovo recommend that, should the battery capacity stuff get
messed up, you FULLY discharge the battery and then re-charge. They say
to turn off all automatic shutdowns so the battery will completely
drain. (This does mean an fsck on re-boot and I suggest that you do a
sync(8) when it gets close and, of course, don't have anything open.
This is claimed to re-initialize the values stored in the battery and I
found this worked on a battery in my old 600E. Mine did not have a weird
"Design Capacity" value, though.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Joerg Wunsch
> FWIW, IBM/Lenovo recommend that, should the battery capacity stuff
> get messed up, you FULLY discharge the battery and then re-charge.
I'm doing that right now with my TP 600E battery, too. It was
completely dead (one out of the three cell pairs had 0.0 V), so I
replaced all cells by some other 18650 cells I've got around. While
the machine yelled "Battery critically low" after only about 5 minutes
of run-time, it already lasts for half an hour now. I hope I'll also
be able to re-train the Coulomb meter chip in the battery there.
> This is claimed to re-initialize the values stored in the battery
> and I found this worked on a battery in my old 600E. Mine did not
> have a weird "Design Capacity" value, though.
Same here, the "Design capacity" of that TP 600E battery makes sense,
unlike on the nx6325.
As Ian Smith wrote:
> > > Is this consistent or does it vary from boot to boot or if you
> > > disconnect and reconnect the battery?
> Or try another battery?
Only got that one. The machine is normally a semi-desktop one.
> > That's right, but it wouldn't be supposed to affect the "Design
> > capacity", would it? ;)
> It wouldn't be supposed to :)
> Tracing back through acpi_cmbat_get_total_battinfo in acpi_cmbat.c
> indicates that calculaing remaining time does uses last full
> capacity, but from there back through acpi_cmbat_get_bst and
> acpi_cmbat_get_bif it's all just retrieval, from acpi packages of
> _BST and _BIF
Thanks for the analysis!
> Most of it must be stored in the in-battery chip, but I don't know
> where specs may be, or even whether they all use same protocols.
I think this is all called the "Smart Battery specification", which is
essentially a layer on top of a standard I涎 bus. I once looked at it
lightly in connection with a battery control IC as I did build my own
battery (out of used 18650 cells, again) for a ham radio transceiver.
But I haven't really looked into the Smart Battery specs so far, as my
transceiver didn't want to talk it anyway. ;-)
> Peter's factor of 10 sounds plausible.
Except for the design capacity value.
> You can dump your ASL (see Handbook for instructions) and search for
> something like:
Thanks for that hint, I'll do it as soon as the machine is back here.
Moore, Robert
There are two types of batteries, the "Smart Battery" and the so-called "Control Method Battery".
AFAIK, by far, the control method battery is dominant. Smart batteries are rare.
The file acpi_cmbat.c refers to control method batteries, I don't think smart batteries. Support for these batteries usually requires another driver, I would imagine something like acpi_smbat.c.
Bob
>> Peter's factor of 10 sounds plausible.
>
>Except for the design capacity value.
>
>> You can dump your ASL (see Handbook for instructions) and search for
>> something like:
>
>Thanks for that hint, I'll do it as soon as the machine is back here.
>
>--
>cheers, J"org .-.-. --... ...-- -.. . DL8DTL
>
>http://www.sax.de/~joerg/ NIC: JW11-RIPE
>Never trust an operating system you don't have sources for. ;-)
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>To unsubscribe, send any mail to "freebsd-acpi...@freebsd.org"
Joerg Wunsch
> There are two types of batteries, the "Smart Battery" and the
> so-called "Control Method Battery".
> AFAIK, by far, the control method battery is dominant. Smart
> batteries are rare.
Thanks, if all else (on the ACPI-level) fails, I'll remember
this.
Alexandre "Sunny" Kovalenko
> As Alexandre Sunny Kovalenko wrote:
>
> > You can dump your ASL (see Handbook for instructions) and search for
> > something like:
>
>
> > and try to track down where the actual values came from. Chapter 10
> > of the ACPI specification (http://www.acpi.info/spec.htm) should
> > provide you with more information on the subject.
>
> on all available laptops around, and while I can basically follow the
> logic of most of those ASL files, I'm completely confused about the
> ASL file I'm getting from the nx6325. Perhaps that confusion about it
> is also what confuses acpiconf -i0... ;-)
>
> I'm attaching both, the acpiconf -i0 output as well as the ASL file.
> Is anybody able to hint me where the _BIF and _BST methods get their
> actual data from?
>
> _______________________________________________
> freebs...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi...@freebsd.org"
Unfortunately, it looks like values are coming straight from Embedded
Controller without any modifications:
Method (C1AC, 1, Serialized)
{
...
If (C14C)
{
Store (Arg0, C160)
Store (C164, Local0)
// This is your design capacity
Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
// This is your last full capacity
Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
// And yes they are the same by design of your BIOS ;)
...
and
OperationRegion (C153, EmbeddedControl, 0x00, 0xFF)
Field (C153, ByteAcc, NoLock, Preserve)
{
Offset (0x86),
C160, 4,
Offset (0x87),
...
Offset (0x8D),
C164, 16,
Offset (0x91),
...
and
Name (C1AF, Package (0x02)
{
Package (0x0D)
{
0x01,
0xFFFFFFFF,
0xFFFFFFFF,
0x01,
0xFFFFFFFF,
0x00,
0x00,
0x64,
0x64,
"Primary",
"100000",
"LIon",
"Hewlett-Packard"
},
...
Given that you are not getting default values, something is actually
being read and returned. Unfortunately you are going to need somebody
smarter then myself to tell you whether magic number they store and
offsets they use to read the values are indeed valid.
You have couple of options you can try yourself, though:
* play with OS names (you can find possible variants in the ASL) and see
if any of them make a difference.
* build ACPI module with the debug information and see what is being
stored and read, and, more importantly, if there are any warnings and/or
errors.
Information on how to do either of these things could be found at
http://www.freebsd.org/doc/handbook/acpi-debug.html
Out of sheer curiosity... what does acpiconf -i1 say?
--
Alexandre Kovalenko (Олександр Коваленко)
--------------------------------------------------------------
Ovi Store: Fresh apps and more
http://store.ovi.com/?cid=ovistore-fw-bac-na-acq-na-ovimail-g0-na-4
Dan Lukes
> Is anybody able to hint me where the _BIF and _BST methods get their
> actual data from?
Method (_BIF, 0, NotSerialized)
{
Return (C1AC (0x00))
}
where 0x00 seems to be battery number.
The structure that will be returned is here:
Name (C1AF, Package (0x02)
{
Package (0x0D)
{
0x01,
0xFFFFFFFF,
0xFFFFFFFF,
0x01,
0xFFFFFFFF,
0x00,
0x00,
0x64,
0x64,
"Primary",
"100000",
"LIon",
"Hewlett-Packard"
},
And it's filled in C1AC() method. The Design/Last Full Capacity is
filled here:
Store (C164, Local0)
Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
It mean that both numbers are same and come from C164 variable.
C164 variable is defined as 16bit variable on offset 0x8D of
EmbeddedController (_HID=PNP0C09) memory region.
So, now you know from where the Design/Last Full Capacity come from.
Unless you have improper BIOS (BIOS for other computer type/version)
then there seems not to be problem between ACPI and OS. You should ask
why independent embedded controller store such value to memory where the
OS is reading it. As far as I know, you can't debug the operations of
embedded controller, so you can imagine only why it store such values
here ...
Dan
Ian Smith
> On Thu, 2010-03-18 at 20:53 +0100, Joerg Wunsch wrote:
> > As Alexandre Sunny Kovalenko wrote:
> >
> > > You can dump your ASL (see Handbook for instructions) and search for
> > > something like:
> >
> > ...
> >
> > > and try to track down where the actual values came from. Chapter 10
> > > of the ACPI specification (http://www.acpi.info/spec.htm) should
> > > provide you with more information on the subject.
> >
> > OK, the machine's back here now. Meanwhile, I already tried all that
> > on all available laptops around, and while I can basically follow the
> > logic of most of those ASL files, I'm completely confused about the
> > ASL file I'm getting from the nx6325. Perhaps that confusion about it
> > is also what confuses acpiconf -i0... ;-)
> >
> > I'm attaching both, the acpiconf -i0 output as well as the ASL file.
> > Is anybody able to hint me where the _BIF and _BST methods get their
> > actual data from?
> Unfortunately, it looks like values are coming straight from Embedded
Hardly smarter than yourself :) but I notice there's another Method C1AC
in the EC section, Scope (C0E3), which appears, perhaps, to be doing
these calculations around line 2767 of Joerg's file. It's way too
complicated with double derefs etc for me to follow, but it does maths
and refers to C1AF a lot, so might be updating those values? I notice a
couple of divide by 100 after adding 99 .. if I'm reading it right ..
Divide (Add (Local1, 0x63), 0x64, Local3, Local2)
where something may be out by 10 in the manner Peter mentioned earlier?
> Out of sheer curiosity... what does acpiconf -i1 say?
It should't be there, but .. I wondered about that too :)
cheers, Ian
Ian Smith
[..]
> > I'm interested in this because my T23 battery is just about dead, only
> > sometimes taking a charge now - that or the charging circuit is dodgy,
> > which I'll find out when the new battery arrives.
> FWIW, IBM/Lenovo recommend that, should the battery capacity stuff get
> messed up, you FULLY discharge the battery and then re-charge. They say
> to turn off all automatic shutdowns so the battery will completely
> drain. (This does mean an fsck on re-boot and I suggest that you do a
> sync(8) when it gets close and, of course, don't have anything open.
>
> This is claimed to re-initialize the values stored in the battery and I
> found this worked on a battery in my old 600E. Mine did not have a weird
> "Design Capacity" value, though.
Yes, been through all that. I drained it from the BIOS setup screen
rather than with an OS running, until the power button won't respond at
all. I got one more charge cycle out of it after the last drain, but
now it's always in critical charging state, and down to 8.6V, where it
usually shuts off below ~10V. Pretty sure it's done for .. possibly
what Joerg experienced, with at least one cell shot. I'm really hoping
the charging circuit is ok; even at 8.6V charging 'present rate' is 0.
There's a line in acpi_cmbat.c, still in 8, that I'm very glad never
became more than a perhaps, or I'd be in real trouble :)
/* XXX if all batteries are critical, perhaps we should suspend. */
cheers, Ian
Dan Lukes
> > Method (C1AC, 1, Serialized)
> > {
> > ...
> > If (C14C)
> > {
> > Store (Arg0, C160)
> > Store (C164, Local0)
> > // This is your design capacity
> > Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
> > // This is your last full capacity
> > Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
> > // And yes they are the same by design of your BIOS ;)
> > ...
> Hardly smarter than yourself :) but I notice there's another Method C1AC
> in the EC section, Scope (C0E3),
The above fragment is from method you are speaking about.
> these calculations around line 2767 of Joerg's file. It's way too
> complicated with double derefs etc for me to follow
Easy:
Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
... do this:
C1AF[1] = Local0
> but it does maths and refers to C1AF a lot, so might be updating those values?
C1AF is array returned by _BIF; C1AF[1] is it's "Design Capacity" item.
C1AC method extract values from EC's memory into array returned by _BIF.
Mostly with no math.
> I notice a
> couple of divide by 100 after adding 99 .. if I'm reading it right ..
>
> Divide (Add (Local1, 0x63), 0x64, Local3, Local2)
>
> where something may be out by 10 in the manner Peter mentioned earlier?
It do this:
Local2 = (Local1 + 99) / 100
e.g. Local1 / 100 rounded up
Local2 is then stored into C1AF[5] (first case) or C1AF[6] (second
case). The C1AF[5] is "Design Capacity of Warning", C1AF[6] is "Design
Capacity of Low".
Suspicious values for C1AF[2] / "Last Full Charge Capacity" come from
EC's C164 with no math.
Dan
Alexandre "Sunny" Kovalenko
<Snip>
> > Out of sheer curiosity... what does acpiconf -i1 say?
>
> It should't be there, but .. I wondered about that too :)
Actually, it should -- there is the second package
Package (0x0D)
{
0x01,
0xFFFFFFFF,
0xFFFFFFFF,
0x01,
0xFFFFFFFF,
0x00,
0x00,
0x64,
0x64,
"Travel",
"100000",
"LIon",
"Hewlett-Packard"
}
complete with the separate _BIF and _BST methods and the parameter to
the C1AC method denoting battery number.
But this is likely the check for the presence of the second battery:
ShiftLeft (0x01, Arg0, Local7)
C1A9 (0x01)
If (LEqual (C1AA (Local7), 0x0F))
{
Return (0xFFFFFFFD)
}
Still curious, though.
--
Alexandre Kovalenko (Олександр Коваленко)
--------------------------------------------------------------
Ovi Store: New apps daily
http://store.ovi.com/?cid=ovistore-fw-bac-na-acq-na-ovimail-g0-na-3
Ian Smith
> On 03/19/10 06:18, Ian Smith:
> > > Method (C1AC, 1, Serialized)
> > > {
> > > ...
> > > If (C14C)
> > > {
> > > Store (Arg0, C160)
> > > Store (C164, Local0)
> > > // This is your design capacity
> > > Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
> > > // This is your last full capacity
> > > Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
> > > // And yes they are the same by design of your BIOS ;)
> > > ...
>
> > Hardly smarter than yourself :) but I notice there's another Method C1AC
> > in the EC section, Scope (C0E3),
>
> The above fragment is from method you are speaking about.
Indeed. I was confused by the later reference to method C1AC at line
5666, and see it references \_SB.C074.C0E3.C149.C1AC - I haven't quite
grasped the scoping yet ..
> > these calculations around line 2767 of Joerg's file. It's way too
> > complicated with double derefs etc for me to follow
>
> Easy:
> Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
> ... do this:
> C1AF[1] = Local0
Can you / anyone suggest a good basic tutorial for ASL/AML? The last
time I tried following it from the ACPI specs I nearly drowned :)
> > but it does maths and refers to C1AF a lot, so might be updating those
> > values?
>
> C1AF is array returned by _BIF; C1AF[1] is it's "Design Capacity" item.
>
> C1AC method extract values from EC's memory into array returned by _BIF.
> Mostly with no math.
Ok.
> > I notice a
> > couple of divide by 100 after adding 99 .. if I'm reading it right ..
> >
> > Divide (Add (Local1, 0x63), 0x64, Local3, Local2)
> >
> > where something may be out by 10 in the manner Peter mentioned earlier?
>
> It do this:
>
> Local2 = (Local1 + 99) / 100
>
> e.g. Local1 / 100 rounded up
Ok, Local3 being remainder I guess? I need to study the language better
before thrashing around with guesswork; it seems sensibly orthogonal.
> Local2 is then stored into C1AF[5] (first case) or C1AF[6] (second case). The
> C1AF[5] is "Design Capacity of Warning", C1AF[6] is "Design Capacity of Low".
>
> Suspicious values for C1AF[2] / "Last Full Charge Capacity" come from EC's
> C164 with no math.
Design and Lastfull Capacity being set equal, so equally suspicious ..
Thanks Dan,
cheers, Ian
Ian Smith
> On Fri, 2010-03-19 at 16:18 +1100, Ian Smith wrote:
> <Snip>
> > > Out of sheer curiosity... what does acpiconf -i1 say?
> >
> > It should't be there, but .. I wondered about that too :)
>
> Actually, it should -- there is the second package
>
> Package (0x0D)
> {
> 0x01,
> 0xFFFFFFFF,
> 0xFFFFFFFF,
> 0x01,
> 0xFFFFFFFF,
> 0x00,
> 0x00,
> 0x64,
> 0x64,
> "Travel",
> "100000",
> "LIon",
> "Hewlett-Packard"
> }
>
> complete with the separate _BIF and _BST methods and the parameter to
> the C1AC method denoting battery number.
Yes indeed. Sorry .. I meant that it shouldn't show as being present,
thinking Joerg had implied that it had only the one battery fitted.
> But this is likely the check for the presence of the second battery:
>
> ShiftLeft (0x01, Arg0, Local7)
> C1A9 (0x01)
> If (LEqual (C1AA (Local7), 0x0F))
> {
> Return (0xFFFFFFFD)
> }
-3 seems to be the 'not present' / uninitialised value. It's likely
meant to work - off AC - with either or both batteries fitted.
> Still curious, though.
Mmm. It still seems to come down to the wrong Design Capacity (equals
Lastfull Capacity) being reported either by the battery itself, or being
miscalculated by the EC. This value - still something like 1/18 of the
expected capacity - is then propagated to the 5% and 1% values.
Joerg, so how long does it really run on battery? If only 10 minutes or
so, it looks like the battery is toast (and maybe lastfull, not design
capacity is what's being reported for both?) If 2.5hrs or so, this may
be 'only' a reporting issue? No more recent BIOS updates for it?
cheers, Ian
Joerg Wunsch
everyone.
As Dan Lukes wrote:
> And it's filled in C1AC() method. The Design/Last Full Capacity is
> filled here:
> Store (C164, Local0)
> Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
> Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
>
> It mean that both numbers are same and come from C164 variable.
Ah, that explains the observed behaviour, I think! (See below.)
As Ian Smith wrote:
> > Out of sheer curiosity... what does acpiconf -i1 say?
>
> It should't be there, but .. I wondered about that too :)
It's available as an entry, but claimed to be "not present" (which is
correct). I guess there's an option to stuff a second battery pack
into the DVD drive bay, I didn't check HP's website for that. That
would at least explain the sheer existance of the second entry.
[About re-calibrating the battery pack]
> Yes, been through all that. I drained it from the BIOS setup screen
> rather than with an OS running, until the power button won't respond
> at all.
I drained my TP600 battery with FreeBSD running single-user, until the
computer eventually turned off. Pinging the ethernet IF remotely, I
could monitor by which time it stopped responding. After all, I've
got a battery back to 1.5 h lifetime, which is plenty for that machine.
> Pretty sure it's done for .. possibly what Joerg experienced, with
> at least one cell shot.
In my case, the battery was so severely dead, it did not accept any
charge, and the TP600 could not run from that battery at all.
> I'm really hoping
> the charging circuit is ok; even at 8.6V charging 'present rate' is 0.
It might simply refuse to charge due to the too low pack voltage. I
wouldn't assume you can kill the charging circuit that way.
What eventually surprised me is that it seems almost all laptops use
some kind of de-facto standard 18650 cylindrical cells, usually
arranged in N pairs of cells, with N being either 3 (10.8 V battery
pack) or 4 (14.8 V battery pack). I bought 5 identical-type old
laptop battery packs in the bay, in order to just use the cells for my
ham radio transceiver. This got me 40 18650 cells, and I've been
using 16 out of those for the transceiver (these were all in really
good shape). One battery pack suffered from a dead cell pair, so this
left me with another 3x2 cells in good shape -- which did now populate
the old battery pack of that TP600E. ;-) The other 16 cells are also
still usable for tinkering, but cannot deliver the higher currents
needed for laptops or my ham radio rig, though they would still do
pretty well for low-current consumers (general electronics). So
bottom line, the good news is that you can actually replace those
cells in dead battery packs. :)
As Alexandre Sunny Kovalenko wrote:
> But this is likely the check for the presence of the second battery:
Yes, apparently, as the second batter is always (correctly) announced as
being not present.
As Ian Smith wrote:
> Can you / anyone suggest a good basic tutorial for ASL/AML? The last
> time I tried following it from the ACPI specs I nearly drowned :)
I guess I'm also in need for one... ;-)
> > Still curious, though.
> Mmm. It still seems to come down to the wrong Design Capacity
> (equals Lastfull Capacity) being reported either by the battery
> itself, or being miscalculated by the EC. This value - still
> something like 1/18 of the expected capacity - is then propagated to
> the 5% and 1% values.
I've had a look at the battery pack now, it is declared as 10.8 V, 55
Wh. This would correspond to 5093 mAh. However, now that I know the
"design" and "last full" capacity are always set as identical by the
BIOS, I'm no longer *that* surprised about the reported value. This
machine has been essentially running from mains power for years now,
so I don't know when it actually might have been able to calculate real
values for "last full capacity" for the last time.
> Joerg, so how long does it really run on battery?
I'll try that as soon as possible (the machine is the production-level
machine of my wife...), and I'll use the single-user method so the
battery can actually drain down until it's really empty.
Btw., as someone suggested to tinker with the ACPI OS name, I gave
that a try, too. When using "Microsoft Windows", it claims I didn't
have a battery at all :-o, for all other values (like "Microsoft
Windows NT", or "Microsoft Windows 2006") it reports the same 279 mAh
as when not modifying the OS name at all.
Nate Lawson
> As Ian Smith wrote:
>
>> Can you / anyone suggest a good basic tutorial for ASL/AML? The last
>> time I tried following it from the ACPI specs I nearly drowned :)
>
> I guess I'm also in need for one... ;-)
I summarized all the info I knew of here a little while ago:
http://rdist.root.org/2008/10/17/all-about-acpi/
P.S. Thanks for the AVR work.
--
Nate
Joerg Wunsch
> > Joerg, so how long does it really run on battery?
> I'll try that as soon as possible (the machine is the
> production-level machine of my wife...), and I'll use the
> single-user method so the battery can actually drain down until it's
> really empty.
It lasted 1.5 h at a reported current of about 2.3 A, so the actual
capacity is around 3.5 Ah, which is certainly a reasonable value for a
3-year old LiIon. I couldn't wait until it shut off itself, so I
eventually stopped the procedure when the reported voltage reached 9.0
V (i.e., 3.0 V per cell).
Battery state reporting went a little funny. As expected, it
initially dropped quickly until it reported a remaining runtime of
0:00 (as that time was based on the nonsensical 279 mAh level). At
that point, the report was stuck at the same values for maybe 30 or 40
minutes, until ACPI eventually reported a "battery is seriously low"
event. Then, it started to report actual data (battery voltage,
current draw) again.
Alas, the reported values now are still way off:
remi# acpiconf -i0
Design capacity: 791 mAh
Last full capacity: 791 mAh
Technology: secondary (rechargeable)
Design voltage: 10800 mV
Capacity (warn): 40 mAh
Capacity (low): 8 mAh
Low/warn granularity: 100 mAh
Warn/full granularity: 100 mAh
Model number: Primary
Serial number: 00784 2006/10/04
Type: LIon
OEM info: Hewlett-Packard
State: discharging
Remaining capacity: 99%
Remaining time: 0:39
Present rate: 1190 mA
Voltage: 12017 mV
Given that I now now it's got more than 3 Ah, having the battery
report 791 mAh is certainly not understandable. But I'm now sure it's
nothing in our ACPI code that is bogus but rather the battery itself
(and the ACPI BIOS not implementing a real "design capacity" value).
Thanks to anybody contributing to the discussion!
Dan Lukes
> Battery state reporting went a little funny. As expected, it
> initially dropped quickly until it reported a remaining runtime of
> 0:00 (as that time was based on the nonsensical 279 mAh level). At
> that point, the report was stuck at the same values for maybe 30 or 40
> minutes, until ACPI eventually reported a "battery is seriously low"
> event. Then, it started to report actual data (battery voltage,
> current draw) again.
>
> Alas, the reported values now are still way off:
>
> remi# acpiconf -i0
> Design capacity: 791 mAh
> Last full capacity: 791 mAh
Three or four cycles of charging / depth depleting may recalibrate the
internals and reported values may become more appropriate.
You should not stop the discharging prematurely - it affect the results.
If you run notebook mostly on AC adapter so the battery is never
discharged so much then internal circuits become confused about battery
capacity. It's common behavior - nothing special to notebooks.
Dan
Joerg Wunsch
> Three or four cycles of charging / depth depleting may recalibrate
> the internals and reported values may become more appropriate.
I wonder whether I'll better do that outside the computer though.
After all, the Coulomb counter in the battery does not care much
whether it is attached to a computer querying it or not.
> You should not stop the discharging prematurely - it affect the
> results.
I did want to reboot it into normal operation in order to allow the
nightly backup to run. I simply ran out of time waiting for the
battery to drain completely. Anyway, at a voltage level of < 9.0 V,
it wouldn't have lasted for another quarter of an hour. (Worst case
cutoff level for a LiIon cell is around 2.7 V.)
Ian Smith
> As Dan Lukes wrote:
>
> > Three or four cycles of charging / depth depleting may recalibrate
> > the internals and reported values may become more appropriate.
>
> I wonder whether I'll better do that outside the computer though.
> After all, the Coulomb counter in the battery does not care much
> whether it is attached to a computer querying it or not.
Hard to second guess what's going on in the battery chip, apart from
measuring current in and out, over a shunt of some sort I suppose.
It's most likely got constants (brand/model/serial/design cap etc)
in EPROM, no? and presumably its estimate of present state in RAM.
> > You should not stop the discharging prematurely - it affect the
> > results.
That's my understanding too. I don't think that process is linear, ie
you really do need to drain it to some set point before it resets, such
that the next full charge can calculate a new 'last full' capacity, so
several such cycles should bring that up nearer your 3Ah estimate.
> I did want to reboot it into normal operation in order to allow the
> nightly backup to run. I simply ran out of time waiting for the
> battery to drain completely. Anyway, at a voltage level of < 9.0 V,
> it wouldn't have lasted for another quarter of an hour. (Worst case
> cutoff level for a LiIon cell is around 2.7 V.)
The chip's estimation of its voltage is likely much more accurate than
current, given the cost of accurate small-current shunts, so I expect
you can trust it to know its cutoff / reset level. I find running it
down from the BIOS setup screen more comfortable, perhaps after taking
it down near empty while you can load it enough to get on with the job.
BTW, I see my presumed-dead battery which was down to 8.6V is now back
to 11.4V (still saying Critical Charging) after 2 days suspended on AC,
after hearing its inverter's fan revving during periods overnight, ie
taking some charge now and again. Truly mysterious, _seeming_ to work
differently suspended under 8.0 than 7.2-S .. but that's ridiculous!
> Never trust an operating system you don't have sources for. ;-)
As in the BIOS, the EC, and the battery chip? :)
cheers, Ian