From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 17 15:43:30 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B77A1106566B for ; Wed, 17 Mar 2010 15:43:29 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01ACF8FC08 for ; Wed, 17 Mar 2010 15:43:28 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o2HFhR1P007314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Mar 2010 08:43:27 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 04F841CC18; Wed, 17 Mar 2010 08:43:27 -0700 (PDT) To: Ian Smith In-reply-to: Your message of "Thu, 18 Mar 2010 01:05:47 +1100." <20100317224207.A85436@sola.nimnet.asn.au> Date: Wed, 17 Mar 2010 08:43:27 -0700 From: "Kevin Oberman" Message-Id: <20100317154327.04F841CC18@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-17_07:2010-02-06, 2010-03-17, 2010-03-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003170145 Cc: Joerg Wunsch , freebsd-acpi@freebsd.org Subject: Re: Funny battery values (nx6325) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 15:43:30 -0000 > Date: Thu, 18 Mar 2010 01:05:47 +1100 (EST) > From: Ian Smith > Sender: owner-freebsd-acpi@freebsd.org > > On Wed, 17 Mar 2010, Joerg Wunsch wrote: > > 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²C 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 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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751