From owner-freebsd-current@FreeBSD.ORG Mon Jul 25 16:29:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9320C16A41F; Mon, 25 Jul 2005 16:29:07 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D117C43D5C; Mon, 25 Jul 2005 16:29:06 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6PGT5o5002189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2005 09:29:05 -0700 Message-ID: <42E5134F.706@root.org> Date: Mon, 25 Jul 2005 09:29:03 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <42E1481F.5040306@root.org> <20050723133819.36efb537.lists@yazzy.org> <42E29CAA.1020007@root.org> <20050724215818.55f951ae.lists@yazzy.org> <42E42F10.3030309@root.org> <20050725091221.106a0368.lists@yazzy.org> In-Reply-To: <20050725091221.106a0368.lists@yazzy.org> Content-Type: multipart/mixed; boundary="------------060301040900060402010609" Cc: acpi@freebsd.org, kjelderg@gmail.com, freebsd-current@freebsd.org Subject: Re: acpi battery rework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 16:29:07 -0000 This is a multi-part message in MIME format. --------------060301040900060402010609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Marcin Jessa wrote: > On Sun, 24 Jul 2005 17:15:12 -0700 > Nate Lawson wrote: >>As far as Eric's result, I'll check that on my systems as well. I >>_think_ the previous behavior was more correct (-1 = unknown) so I'll >>commit this minor change. The "state" variable should not have changed >>so please let me know for sure if it has. "1" means "discharging" which >>doesn't sound right if you're on AC power. If you just recently plugged >>in the laptop, try polling the status a few more times (apm(8) gives >>more detail) and see if it catches up. Some systems lag reporting >>various values until they are sure they've restabilized after an AC line >>change. >> >>Marcin, if your system reports a valid rate of use, we can calculate >>time. If you're on AC power, there is no time available (since your >>batteries aren't discharging at any rate). Try a previous >>kernel/acpi.ko to be certain what the behavior used to be. > > > [yazzy@lapdance:~]> uname -a > FreeBSD lapdance.yazzy.net 6.0-BETA1 FreeBSD 6.0-BETA1 #4: Sat Jul 23 17:35:13 CEST 2005 root@lapdance.yazzy.net:/usr/obj/usr/src/sys/LAPDANCE-6.0 i386 > > Running on AC: > [yazzy@lapdance:~]> sysctl -a | grep battery > hw.acpi.battery.life: 23 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 2 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > > Running on battery: > [yazzy@lapdance:~]> sysctl -a | grep battery > hw.acpi.battery.life: 23 > hw.acpi.battery.time: 41 > hw.acpi.battery.state: 1 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > [yazzy@lapdance:~]> And with a 7-current kernel, everything is the same except "time" is always -1 both on and off AC power? Please try this patch with 7-current and report its output both on and off power. It prints out more debugging info each time the battery is read. -- Nate --------------060301040900060402010609 Content-Type: text/plain; name="batt_dbg.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="batt_dbg.diff" Index: sys/dev/acpica/acpi_battery.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_battery.c,v retrieving revision 1.13 diff -u -r1.13 acpi_battery.c --- sys/dev/acpica/acpi_battery.c 23 Jul 2005 19:35:59 -0000 1.13 +++ sys/dev/acpica/acpi_battery.c 25 Jul 2005 15:59:29 -0000 @@ -161,6 +161,7 @@ error = ENOMEM; goto out; } +printf("batt pass1: dev %p ", batt_dev); /* Default info for every battery is "not present". */ acpi_reset_battinfo(&bi[i]); @@ -174,11 +175,13 @@ ACPI_BATT_GET_STATUS(batt_dev, &bst[i]) != 0 || ACPI_BATT_GET_INFO(batt_dev, bif) != 0) continue; +printf("ok "); /* If a battery is not installed, we sometimes get strange values. */ if (!acpi_battery_bst_valid(&bst[i]) || !acpi_battery_bif_valid(bif)) continue; +printf("valid "); /* Record state and calculate percent capacity remaining. */ valid_units++; @@ -204,10 +207,12 @@ */ if (bst[i].rate > 0 && (bst[i].state & ACPI_BATT_STAT_DISCHARG)) valid_rate += bst[i].rate; +printf("state %d cap %d valid_rate %d\n", bi[i].state, bi[i].cap, valid_rate); } /* If the caller asked for a device but we didn't find it, error. */ if (dev != NULL && dev_idx < 0) { +printf("batt: couldn't find dev %p\n", dev); error = ENXIO; goto out; } @@ -226,6 +231,8 @@ bi[i].min = 0; total_min += bi[i].min; total_cap += bi[i].cap; +printf("batt pass2: min %d total_min %d total_cap %d\n", bi[i].min, total_min, +total_cap); } /* --------------060301040900060402010609--