From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 21 11:02:02 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 078F516A4CE for ; Mon, 21 Jun 2004 11:02:02 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 020BC43D5A for ; Mon, 21 Jun 2004 11:02:02 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i5LB1p1n064560 for ; Mon, 21 Jun 2004 11:01:51 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5LB1pAH064554 for freebsd-acpi@freebsd.org; Mon, 21 Jun 2004 11:01:51 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Jun 2004 11:01:51 GMT Message-Id: <200406211101.i5LB1pAH064554@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 11:02:02 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2004/01/31] kern/62194 acpi kern/acpi: Unable to map IRQ on device cb 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/08/11] i386/55473 acpi Mouse broken on some AWARD BIOS with ACPI o [2004/03/17] misc/64365 acpi ACPI problems o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) 3 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 22 18:55:16 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 382EB16A4DD for ; Tue, 22 Jun 2004 18:55:16 +0000 (GMT) Received: from web41106.mail.yahoo.com (web41106.mail.yahoo.com [66.218.93.22]) by mx1.FreeBSD.org (Postfix) with SMTP id 2502143D3F for ; Tue, 22 Jun 2004 18:55:16 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040622185505.62849.qmail@web41106.mail.yahoo.com> Received: from [24.18.54.216] by web41106.mail.yahoo.com via HTTP; Tue, 22 Jun 2004 11:55:05 PDT Date: Tue, 22 Jun 2004 11:55:05 -0700 (PDT) From: Jeffrey Katcher To: freebsd-acpi@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Atheros driver doesn't work with ACPI enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 18:55:16 -0000 Hardware: IBM Thinkpad T40 with IBM Atheros A/B Mini-PCI card Software: FreeBSD 5-current (as of yesterday) I posted this earlier to the -current list, but I've isolated it as being an ACPI thing. If I boot with ACPI disabled, I can kldload if_ath, up the interface and go. With ACPI, I can kldload the driver, but I get unending hardware error reset messages when I up the interface. Thanks, Jeff Katcher From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 22 22:46:06 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F9EF16A4CE for ; Tue, 22 Jun 2004 22:46:06 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0777D43D39 for ; Tue, 22 Jun 2004 22:46:06 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 80671 invoked by uid 1000); 22 Jun 2004 22:46:07 -0000 Date: Tue, 22 Jun 2004 15:46:07 -0700 (PDT) From: Nate Lawson To: Jeffrey Katcher In-Reply-To: <20040622185505.62849.qmail@web41106.mail.yahoo.com> Message-ID: <20040622154535.V79174@root.org> References: <20040622185505.62849.qmail@web41106.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org Subject: Re: Atheros driver doesn't work with ACPI enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:46:06 -0000 On Tue, 22 Jun 2004, Jeffrey Katcher wrote: > Hardware: IBM Thinkpad T40 with IBM Atheros A/B Mini-PCI card > Software: FreeBSD 5-current (as of yesterday) > > I posted this earlier to the -current list, but I've isolated it as being an > ACPI thing. If I boot with ACPI disabled, I can kldload if_ath, up the > interface and go. With ACPI, I can kldload the driver, but I get unending > hardware error reset messages when I up the interface. What was the date of your last cvsup? A PCI irq routing issue was worked around a week ago or so. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 22 22:51:50 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B0316A4CF for ; Tue, 22 Jun 2004 22:51:50 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3324D43D5C for ; Tue, 22 Jun 2004 22:51:50 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 80716 invoked by uid 1000); 22 Jun 2004 22:51:25 -0000 Date: Tue, 22 Jun 2004 15:51:25 -0700 (PDT) From: Nate Lawson To: Dan Cojocar In-Reply-To: <20040617131024.GA7772@Zeus.UBBCluj.Ro> Message-ID: <20040622154616.G79174@root.org> References: <20040603124930.GA58885@Zeus.UBBCluj.Ro> <20040617131024.GA7772@Zeus.UBBCluj.Ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:51:50 -0000 On Thu, 17 Jun 2004, Dan Cojocar wrote: > I made some progress on my one, finaly i can change > hw.acpi.thermal.tz0.active. > My asl contains in EC0 section: in Field (ERAM, ByteAcc, > Lock, Preserve): FAN, 1 and FANL, 16 > I made some search on web and found that FANL is FAN Low, but i'm > not sure :(. > Can somebody explain me this, and what represents 16 there, or > maybe point me to some documentation. You'll have to look at the ACPI spec if you want to decode the field values. In this case, the numbers are field widths and mean FAN is 1 bit, FANL is 16 bits wide. The spec won't tell you what FAN or FANL mean but you can sometimes figure it out from the surrounding AML. I looked at a similar ASL dump and it appears the FAN and FANL values aren't referenced elsewhere. So your fan control needs to be done by something other than ACPI. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 22 23:02:47 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81E1616A4CE for ; Tue, 22 Jun 2004 23:02:47 +0000 (GMT) Received: from web41109.mail.yahoo.com (web41109.mail.yahoo.com [66.218.93.25]) by mx1.FreeBSD.org (Postfix) with SMTP id 64DF443D1F for ; Tue, 22 Jun 2004 23:02:47 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040622230233.67825.qmail@web41109.mail.yahoo.com> Received: from [24.18.54.216] by web41109.mail.yahoo.com via HTTP; Tue, 22 Jun 2004 16:02:33 PDT Date: Tue, 22 Jun 2004 16:02:33 -0700 (PDT) From: Jeffrey Katcher To: Nate Lawson In-Reply-To: <20040622154535.V79174@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-acpi@FreeBSD.org Subject: Re: Atheros driver doesn't work with ACPI enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 23:02:47 -0000 > What was the date of your last cvsup? A PCI irq routing issue was worked > around a week ago or so. > > -Nate I've been rebuilding daily since this turned up. I saw it with yesterday morning's build (~9am PST) and haven't tried this morning's yet. Didn't see anything ACPI related on the cvs-all list so I didn't try. Jeff From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 06:45:02 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 848CB16A4CE for ; Wed, 23 Jun 2004 06:45:02 +0000 (GMT) Received: from zeus.ubbcluj.ro (Ns2.UBBCluj.Ro [193.231.20.1]) by mx1.FreeBSD.org (Postfix) with SMTP id 5EEE343D46 for ; Wed, 23 Jun 2004 06:45:01 +0000 (GMT) (envelope-from dan@zeus.ubbcluj.ro) Received: (qmail 996 invoked by uid 1002); 23 Jun 2004 06:44:45 -0000 Date: Wed, 23 Jun 2004 09:44:45 +0300 From: Dan Cojocar To: Nate Lawson Message-ID: <20040623064445.GB85230@Zeus.UBBCluj.Ro> References: <20040603124930.GA58885@Zeus.UBBCluj.Ro> <20040617131024.GA7772@Zeus.UBBCluj.Ro> <20040622154616.G79174@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040622154616.G79174@root.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-acpi@freebsd.org Subject: Re: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 06:45:02 -0000 Hello, First, thanks for your reply. I'm confused now because i defined in my asl _AC0, _AC1 and their corespondent _AL0 and _AL1, and Devices for FAN, and now i can change active status from -1 to 0 or 1. I enabled debug and i see that my fan1 and fan2 are changing status from D3 to D0 when the temperature is bigger then AC0, but i'm not sure i defined correct temperatures for AC0 and AC1, because in my asl they were absent, and i defined AC0 at 70C and AC1 at 65C. I don't know if there values are correct, but now the fan is turned on at 65C and he gets more speed at 70C but it seems that the temperature is very slow decreased, maybe i'm doing something wrong here :( You said that it's possible that my fan control is done by something other than ACPI, how can i establish who is responsible with my fans? Thanks, Dan > You'll have to look at the ACPI spec if you want to decode the field > values. In this case, the numbers are field widths and mean FAN is 1 bit, > FANL is 16 bits wide. The spec won't tell you what FAN or FANL mean but > you can sometimes figure it out from the surrounding AML. I looked at a > similar ASL dump and it appears the FAN and FANL values aren't referenced > elsewhere. So your fan control needs to be done by something other than > ACPI. > > -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 16:40:00 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD2516A4CE for ; Wed, 23 Jun 2004 16:40:00 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id CB66F43D2D for ; Wed, 23 Jun 2004 16:40:00 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 85939 invoked by uid 1000); 23 Jun 2004 16:40:01 -0000 Date: Wed, 23 Jun 2004 09:40:01 -0700 (PDT) From: Nate Lawson To: Dan Cojocar In-Reply-To: <20040623064445.GB85230@Zeus.UBBCluj.Ro> Message-ID: <20040623093442.P85911@root.org> References: <20040603124930.GA58885@Zeus.UBBCluj.Ro> <20040617131024.GA7772@Zeus.UBBCluj.Ro> <20040623064445.GB85230@Zeus.UBBCluj.Ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 16:40:01 -0000 On Wed, 23 Jun 2004, Dan Cojocar wrote: > > You'll have to look at the ACPI spec if you want to decode the field > > values. In this case, the numbers are field widths and mean FAN is 1 bit, > > FANL is 16 bits wide. The spec won't tell you what FAN or FANL mean but > > you can sometimes figure it out from the surrounding AML. I looked at a > > similar ASL dump and it appears the FAN and FANL values aren't referenced > > elsewhere. So your fan control needs to be done by something other than > > ACPI. > > > > -Nate > > I'm confused now because i defined in my asl _AC0, _AC1 and > their corespondent _AL0 and _AL1, and Devices for FAN, and now i can > change active status from -1 to 0 or 1. > I enabled debug and i see that my fan1 and fan2 are changing > status from D3 to D0 when the temperature is bigger then AC0, but i'm > not sure i defined correct temperatures for AC0 and AC1, because in my > asl they were absent, and i defined AC0 at 70C and AC1 at 65C. I don't > know if there values are correct, but now the fan is turned on at 65C > and he gets more speed at 70C but it seems that the temperature > is very slow decreased, maybe i'm doing something wrong here :( > You said that it's possible that my fan control is done by > something other than ACPI, how can i establish who is responsible with > my fans? Please try not to top-post, it makes reading the message difficult. You defined your own custom ACPI cooling objects in your ASL. The BIOS manufacturer did not. Therefore, on other OS's that work with the stock ASL (i.e. Windows), fan control is done some other way than through ACPI. Perhaps it's done via SMM. Do the fans ever come on while running with the stock ASL? Or, it's done with a custom driver via SMbus or by directly poking the super I/O chip. You know that "power/heat/hotkey" custom app that comes with just about every laptop? That's what it's doing. If the laptop was more ACPI-compliant, the fans would be defined in your ASL and you wouldn't have to use a custom ASL. As for your custom ASL, it sounds like you got things right. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 19:41:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8509B16A4CE for ; Wed, 23 Jun 2004 19:41:25 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3698A43D5A for ; Wed, 23 Jun 2004 19:41:25 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 86911 invoked by uid 1000); 23 Jun 2004 19:40:40 -0000 Date: Wed, 23 Jun 2004 12:40:40 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040616.135044.85075412.imp@bsdimp.com> Message-ID: <20040623123827.O86825@root.org> References: <20040616171408.0f88c928.liamfoy@sepulcrum.org> <20040616.135044.85075412.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 19:41:25 -0000 On Wed, 16 Jun 2004, M. Warner Losh wrote: > As it relates to acpi, however, there is one bug. First in > acpi_capm_get_info(), if we can't get the battery info, we do: > > if (acpi_battery_get_battinfo(-1, &batt)) { > aip->ai_batt_stat = 0xff; /* unknown */ > aip->ai_batt_life = 0xff; /* unknown */ > aip->ai_batt_time = -1; /* unknown */ > - aip->ai_batteries = 0; > } else { > > instead, this should be: > if (acpi_battery_get_battinfo(-1, &batt)) { > aip->ai_batt_stat = 0xff; /* unknown */ > aip->ai_batt_life = 0xff; /* unknown */ > aip->ai_batt_time = -1; /* unknown */ > + aip->ai_batteries = -1; /* Unknown */ [*] > } else { > > [*] or 0xffffffff instead of -1. 0 is clearly wrong, since it means > no batteries, not the number of batteries cannot be determined. I agree with this. I'd like to use ~0 instead of (u_int)-1. Up to you though. Please commit. > Finally, apm(8) needs the following patch, imho. If drivers are > producing results that produce bad things, they should be fixed, not > apm(8). I don't think that anything does actually produce them. > > Index: apm.c > =================================================================== > RCS file: /cache/ncvs/src/usr.sbin/apm/apm.c,v > retrieving revision 1.32 > diff -u -r1.32 apm.c > --- apm.c 27 May 2004 19:23:27 -0000 1.32 > +++ apm.c 16 Jun 2004 19:45:52 -0000 > @@ -34,6 +34,8 @@ > > #define APMDEV "/dev/apm" > > +#define APM_UNKNOWN 0xff /* Unknown in APM BIOS spec */ > + > #define xh(a) (((a) & 0xff00) >> 8) > #define xl(a) ((a) & 0xff) > #define APMERR(a) xh(a) > @@ -156,7 +158,7 @@ > printf("APM version: %d.%d\n", aip->ai_major, aip->ai_minor); > printf("APM Management: %s\n", aip->ai_status ? "Enabled" : "Disabled"); > printf("AC Line status: "); > - if (aip->ai_acline >= 255) > + if (aip->ai_acline == APM_UNKNOWN) > printf("unknown"); > else if (aip->ai_acline > 1) > printf("invalid value (0x%x)", aip->ai_acline); > @@ -164,7 +166,7 @@ > printf("%s", line_msg[aip->ai_acline]); > printf("\n"); > printf("Battery status: "); > - if (aip->ai_batt_stat >= 255) > + if (aip->ai_batt_stat == APM_UNKNOWN) > printf("unknown"); > else if (aip->ai_batt_stat > 3) > printf("invalid value (0x%x)", aip->ai_batt_stat); > @@ -172,7 +174,7 @@ > printf("%s", batt_msg[aip->ai_batt_stat]); > printf("\n"); > printf("Remaining battery life: "); > - if (aip->ai_batt_life >= 255) > + if (aip->ai_batt_life == APM_UNKNOWN) > printf("unknown\n"); > else if (aip->ai_batt_life <= 100) > printf("%d%%\n", aip->ai_batt_life); > @@ -194,7 +196,7 @@ > } > if (aip->ai_infoversion >= 1) { > printf("Number of batteries: "); > - if (aip->ai_batteries >= 255) > + if (aip->ai_batteries == (u_int) -1) > printf("unknown\n"); > else { > u_int i; > @@ -208,12 +210,12 @@ > continue; > printf("Battery %d:\n", i); > printf("\tBattery status: "); > - if (aps.ap_batt_flag <= 255 && > + if (aps.ap_batt_flag != APM_UNKNOWN && > (aps.ap_batt_flag & APM_BATT_NOT_PRESENT)) { > printf("not present\n"); > continue; > } > - if (aps.ap_batt_stat >= 255) > + if (aps.ap_batt_stat != APM_UNKNOWN) > printf("unknown\n"); > else if (aps.ap_batt_stat > 3) > printf("invalid value (0x%x)\n", > @@ -222,7 +224,7 @@ > printf("%s\n", > batt_msg[aps.ap_batt_stat]); > printf("\tRemaining battery life: "); > - if (aps.ap_batt_life >= 255) > + if (aps.ap_batt_life == (u_int)-1) > printf("unknown\n"); > else if (aps.ap_batt_life <= 100) > printf("%d%%\n", aps.ap_batt_life); Please commit this patch after deciding whether you want to go with ~0 or (u_int)-1. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 19:59:12 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20AA416A4CE for ; Wed, 23 Jun 2004 19:59:12 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E232943D2D for ; Wed, 23 Jun 2004 19:59:11 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 87005 invoked by uid 1000); 23 Jun 2004 19:58:19 -0000 Date: Wed, 23 Jun 2004 12:58:19 -0700 (PDT) From: Nate Lawson To: YONETANI Tomokazu In-Reply-To: <20040619101905.GA55457@les.ath.cx> Message-ID: <20040623125803.N86954@root.org> References: <20040616131055.GA37637@les.ath.cx> <20040618052615.GA48947@les.ath.cx> <20040618192739.W52398@root.org> <20040619101905.GA55457@les.ath.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: cx_usage X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 19:59:12 -0000 On Sat, 19 Jun 2004, YONETANI Tomokazu wrote: > On Fri, Jun 18, 2004 at 07:27:57PM -0700, Nate Lawson wrote: > > On Fri, 18 Jun 2004, YONETANI Tomokazu wrote: > > > On Wed, Jun 16, 2004 at 10:10:55PM +0900, YONETANI Tomokazu wrote: > > > > What do you think about the following changes? > > > > > > > > - print 100% instead of 99% when there's only 1 Cx state, and 0% > > > > when the sum is zero. > > > > - two digits from fractional part of each percentage are shown; > > > > my Laptop PC barely enters into C3 state and hw.acpi.cpu.cx_usage > > > > is almost always "0% 99% 0%" after revision 1.39. it's now shown as > > > > "0.00% 99.96% 0.03%" > > > > > > Actually, cpu_cx_stats[i] * 100 may not fit in u_int and would print > > > incorrect value as values grow. Please try this instead. > > > > Thank you. I committed this with minor changes. > > Thanks. But I found myself stupid: > > whole = cpu_cx_stats[i] * 100; > > cpu_cx_stats[i] needs a cast into u_int64_t, otherwise multiplication > is still performed as 32bit-integer and will overflow before assigned > to `whole', and using u_int64_t variables is worthless. I tend to assume > that there's an automatic upgrade of precision to that of the left-hand > side operand, but it's pretty wrong. I should have noticed this while > testing the patch if I kept the laptop turned on a bit longer. > I'm sorry. > You're correct. I'll commit the fix in a little while. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 20:00:23 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B028916A4F6 for ; Wed, 23 Jun 2004 20:00:23 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0846943D45 for ; Wed, 23 Jun 2004 20:00:23 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdDu9-0003Fq-00; Wed, 23 Jun 2004 21:59:33 +0200 Received: from [217.43.129.99] (helo=liamfoy.ath.cx) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdDu9-0004Lc-00; Wed, 23 Jun 2004 21:59:33 +0200 From: "Liam J. Foy" To: Nate Lawson Message-Id: <20000623205805.4c299e4e.liamfoy@sepulcrum.org> In-Reply-To: <20040623123827.O86825@root.org> References: <20040616171408.0f88c928.liamfoy@sepulcrum.org> <20040616.135044.85075412.imp@bsdimp.com> <20040623123827.O86825@root.org> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 23 Jun 2004 20:00:23 -0000 X-Original-Date: Fri, 23 Jun 2000 20:58:05 +0100 X-List-Received-Date: Wed, 23 Jun 2004 20:00:23 -0000 On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) Nate Lawson wrote: > On Wed, 16 Jun 2004, M. Warner Losh wrote: > > As it relates to acpi, however, there is one bug. First in > > acpi_capm_get_info(), if we can't get the battery info, we do: > > > > if (acpi_battery_get_battinfo(-1, &batt)) { > > aip->ai_batt_stat = 0xff; /* unknown */ > > aip->ai_batt_life = 0xff; /* unknown */ > > aip->ai_batt_time = -1; /* unknown */ > > - aip->ai_batteries = 0; > > } else { > > > > instead, this should be: > > if (acpi_battery_get_battinfo(-1, &batt)) { > > aip->ai_batt_stat = 0xff; /* unknown */ > > aip->ai_batt_life = 0xff; /* unknown */ > > aip->ai_batt_time = -1; /* unknown */ > > + aip->ai_batteries = -1; /* Unknown */ [*] > > } else { > > > > [*] or 0xffffffff instead of -1. 0 is clearly wrong, since it means > > no batteries, not the number of batteries cannot be determined. > > I agree with this. I'd like to use ~0 instead of (u_int)-1. Up to you > though. Please commit. > > > Finally, apm(8) needs the following patch, imho. If drivers are > > producing results that produce bad things, they should be fixed, not > > apm(8). I don't think that anything does actually produce them. > > > > Index: apm.c > > =================================================================== > > RCS file: /cache/ncvs/src/usr.sbin/apm/apm.c,v > > retrieving revision 1.32 > > diff -u -r1.32 apm.c > > --- apm.c 27 May 2004 19:23:27 -0000 1.32 > > +++ apm.c 16 Jun 2004 19:45:52 -0000 > > @@ -34,6 +34,8 @@ > > > > #define APMDEV "/dev/apm" > > > > +#define APM_UNKNOWN 0xff /* Unknown in APM BIOS spec */ > > + > > #define xh(a) (((a) & 0xff00) >> 8) > > #define xl(a) ((a) & 0xff) > > #define APMERR(a) xh(a) > > @@ -156,7 +158,7 @@ > > printf("APM version: %d.%d\n", aip->ai_major, aip->ai_minor); > > printf("APM Management: %s\n", aip->ai_status ? "Enabled" : "Disabled"); > > printf("AC Line status: "); > > - if (aip->ai_acline >= 255) > > + if (aip->ai_acline == APM_UNKNOWN) > > printf("unknown"); > > else if (aip->ai_acline > 1) > > printf("invalid value (0x%x)", aip->ai_acline); > > @@ -164,7 +166,7 @@ > > printf("%s", line_msg[aip->ai_acline]); > > printf("\n"); > > printf("Battery status: "); > > - if (aip->ai_batt_stat >= 255) > > + if (aip->ai_batt_stat == APM_UNKNOWN) > > printf("unknown"); > > else if (aip->ai_batt_stat > 3) > > printf("invalid value (0x%x)", aip->ai_batt_stat); > > @@ -172,7 +174,7 @@ > > printf("%s", batt_msg[aip->ai_batt_stat]); > > printf("\n"); > > printf("Remaining battery life: "); > > - if (aip->ai_batt_life >= 255) > > + if (aip->ai_batt_life == APM_UNKNOWN) > > printf("unknown\n"); > > else if (aip->ai_batt_life <= 100) > > printf("%d%%\n", aip->ai_batt_life); > > @@ -194,7 +196,7 @@ > > } > > if (aip->ai_infoversion >= 1) { > > printf("Number of batteries: "); > > - if (aip->ai_batteries >= 255) > > + if (aip->ai_batteries == (u_int) -1) > > printf("unknown\n"); > > else { > > u_int i; > > @@ -208,12 +210,12 @@ > > continue; > > printf("Battery %d:\n", i); > > printf("\tBattery status: "); > > - if (aps.ap_batt_flag <= 255 && > > + if (aps.ap_batt_flag != APM_UNKNOWN && > > (aps.ap_batt_flag & APM_BATT_NOT_PRESENT)) { > > printf("not present\n"); > > continue; > > } > > - if (aps.ap_batt_stat >= 255) > > + if (aps.ap_batt_stat != APM_UNKNOWN) > > printf("unknown\n"); > > else if (aps.ap_batt_stat > 3) > > printf("invalid value (0x%x)\n", > > @@ -222,7 +224,7 @@ > > printf("%s\n", > > batt_msg[aps.ap_batt_stat]); > > printf("\tRemaining battery life: "); > > - if (aps.ap_batt_life >= 255) > > + if (aps.ap_batt_life == (u_int)-1) > > printf("unknown\n"); > > else if (aps.ap_batt_life <= 100) > > printf("%d%%\n", aps.ap_batt_life); > > Please commit this patch after deciding whether you want to go with ~0 or > (u_int)-1. We decided to go with -1. The apm.c patch currently will not apply due to the re-structure of apm. The following patch will: http://liamfoy.kerneled.org/apm.diff After more digging, apm -l should return 255(stated in man page and acpi spec). The following patch will make it work: --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 @@ -449,7 +449,7 @@ static int bat_units = 0; static struct acpi_cmbat_softc **bat = NULL; - cap = min = -1; + cap = min = 255; batt_stat = ACPI_BATT_STAT_NOT_PRESENT; error = 0; @@ -545,7 +545,7 @@ /* Battery life */ if (valid_units == 0) { - cap = -1; + cap = 255; batt_stat = ACPI_BATT_STAT_NOT_PRESENT; } else { cap = total_cap / valid_units; @@ -649,7 +649,7 @@ } if (!sc->present) { - battinfo->cap = -1; + battinfo->cap = 255; battinfo->min = -1; battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; } else { I think all the patches need commiting. > > -Nate > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- -Liam J. Foy http://liamfoy.kerneled.org "Now I wish it would rain down on me" From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 20:01:03 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F3316A5D9 for ; Wed, 23 Jun 2004 20:01:03 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B012643D60 for ; Wed, 23 Jun 2004 20:00:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i5NJw5gs092102; Wed, 23 Jun 2004 13:58:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 23 Jun 2004 13:58:15 -0600 (MDT) Message-Id: <20040623.135815.22018529.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040623123827.O86825@root.org> References: <20040616171408.0f88c928.liamfoy@sepulcrum.org> <20040616.135044.85075412.imp@bsdimp.com> <20040623123827.O86825@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 20:01:03 -0000 In message: <20040623123827.O86825@root.org> Nate Lawson writes: : On Wed, 16 Jun 2004, M. Warner Losh wrote: : > As it relates to acpi, however, there is one bug. First in : > acpi_capm_get_info(), if we can't get the battery info, we do: : > : > if (acpi_battery_get_battinfo(-1, &batt)) { : > aip->ai_batt_stat = 0xff; /* unknown */ : > aip->ai_batt_life = 0xff; /* unknown */ : > aip->ai_batt_time = -1; /* unknown */ : > - aip->ai_batteries = 0; : > } else { : > : > instead, this should be: : > if (acpi_battery_get_battinfo(-1, &batt)) { : > aip->ai_batt_stat = 0xff; /* unknown */ : > aip->ai_batt_life = 0xff; /* unknown */ : > aip->ai_batt_time = -1; /* unknown */ : > + aip->ai_batteries = -1; /* Unknown */ [*] : > } else { : > : > [*] or 0xffffffff instead of -1. 0 is clearly wrong, since it means : > no batteries, not the number of batteries cannot be determined. : : I agree with this. I'd like to use ~0 instead of (u_int)-1. Up to you : though. Please commit. OK. I like it better than 0xffffffff. Pedantically, it should likely be ~(u_int)0 or something gross like that. : Please commit this patch after deciding whether you want to go with ~0 or : (u_int)-1. I'll try to make this a #define... Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 20:27:55 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2645E16A4CE for ; Wed, 23 Jun 2004 20:27:55 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BEEB43D5C for ; Wed, 23 Jun 2004 20:27:54 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdEL3-0000tZ-00; Wed, 23 Jun 2004 22:27:21 +0200 Received: from [217.43.129.99] (helo=liamfoy.ath.cx) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdEL2-0004i4-00; Wed, 23 Jun 2004 22:27:20 +0200 From: "Liam J. Foy" To: "Liam J. Foy" Message-Id: <20000623212553.19a28a13.liamfoy@sepulcrum.org> In-Reply-To: <20000623205805.4c299e4e.liamfoy@sepulcrum.org> References: <20040616171408.0f88c928.liamfoy@sepulcrum.org> <20040616.135044.85075412.imp@bsdimp.com> <20040623123827.O86825@root.org> <20000623205805.4c299e4e.liamfoy@sepulcrum.org> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 23 Jun 2004 20:27:55 -0000 X-Original-Date: Fri, 23 Jun 2000 21:25:53 +0100 X-List-Received-Date: Wed, 23 Jun 2004 20:27:55 -0000 On Fri, 23 Jun 2000 20:58:05 +0100 "Liam J. Foy" wrote: > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) > Nate Lawson wrote: > > > On Wed, 16 Jun 2004, M. Warner Losh wrote: > > > As it relates to acpi, however, there is one bug. First in > > > acpi_capm_get_info(), if we can't get the battery info, we do: > > > > > > if (acpi_battery_get_battinfo(-1, &batt)) { > > > aip->ai_batt_stat = 0xff; /* unknown */ > > > aip->ai_batt_life = 0xff; /* unknown */ > > > aip->ai_batt_time = -1; /* unknown */ > > > - aip->ai_batteries = 0; > > > } else { > > > > > > instead, this should be: > > > if (acpi_battery_get_battinfo(-1, &batt)) { > > > aip->ai_batt_stat = 0xff; /* unknown */ > > > aip->ai_batt_life = 0xff; /* unknown */ > > > aip->ai_batt_time = -1; /* unknown */ > > > + aip->ai_batteries = -1; /* Unknown */ [*] > > > } else { > > > > > > [*] or 0xffffffff instead of -1. 0 is clearly wrong, since it means > > > no batteries, not the number of batteries cannot be determined. > > > > I agree with this. I'd like to use ~0 instead of (u_int)-1. Up to you > > though. Please commit. > > > > > Finally, apm(8) needs the following patch, imho. If drivers are > > > producing results that produce bad things, they should be fixed, not > > > apm(8). I don't think that anything does actually produce them. > > > > > > Index: apm.c > > > =================================================================== > > > RCS file: /cache/ncvs/src/usr.sbin/apm/apm.c,v > > > retrieving revision 1.32 > > > diff -u -r1.32 apm.c > > > --- apm.c 27 May 2004 19:23:27 -0000 1.32 > > > +++ apm.c 16 Jun 2004 19:45:52 -0000 > > > @@ -34,6 +34,8 @@ > > > > > > #define APMDEV "/dev/apm" > > > > > > +#define APM_UNKNOWN 0xff /* Unknown in APM BIOS spec */ > > > + > > > #define xh(a) (((a) & 0xff00) >> 8) > > > #define xl(a) ((a) & 0xff) > > > #define APMERR(a) xh(a) > > > @@ -156,7 +158,7 @@ > > > printf("APM version: %d.%d\n", aip->ai_major, aip->ai_minor); > > > printf("APM Management: %s\n", aip->ai_status ? "Enabled" : "Disabled"); > > > printf("AC Line status: "); > > > - if (aip->ai_acline >= 255) > > > + if (aip->ai_acline == APM_UNKNOWN) > > > printf("unknown"); > > > else if (aip->ai_acline > 1) > > > printf("invalid value (0x%x)", aip->ai_acline); > > > @@ -164,7 +166,7 @@ > > > printf("%s", line_msg[aip->ai_acline]); > > > printf("\n"); > > > printf("Battery status: "); > > > - if (aip->ai_batt_stat >= 255) > > > + if (aip->ai_batt_stat == APM_UNKNOWN) > > > printf("unknown"); > > > else if (aip->ai_batt_stat > 3) > > > printf("invalid value (0x%x)", aip->ai_batt_stat); > > > @@ -172,7 +174,7 @@ > > > printf("%s", batt_msg[aip->ai_batt_stat]); > > > printf("\n"); > > > printf("Remaining battery life: "); > > > - if (aip->ai_batt_life >= 255) > > > + if (aip->ai_batt_life == APM_UNKNOWN) > > > printf("unknown\n"); > > > else if (aip->ai_batt_life <= 100) > > > printf("%d%%\n", aip->ai_batt_life); > > > @@ -194,7 +196,7 @@ > > > } > > > if (aip->ai_infoversion >= 1) { > > > printf("Number of batteries: "); > > > - if (aip->ai_batteries >= 255) > > > + if (aip->ai_batteries == (u_int) -1) > > > printf("unknown\n"); > > > else { > > > u_int i; > > > @@ -208,12 +210,12 @@ > > > continue; > > > printf("Battery %d:\n", i); > > > printf("\tBattery status: "); > > > - if (aps.ap_batt_flag <= 255 && > > > + if (aps.ap_batt_flag != APM_UNKNOWN && > > > (aps.ap_batt_flag & APM_BATT_NOT_PRESENT)) { > > > printf("not present\n"); > > > continue; > > > } > > > - if (aps.ap_batt_stat >= 255) > > > + if (aps.ap_batt_stat != APM_UNKNOWN) > > > printf("unknown\n"); > > > else if (aps.ap_batt_stat > 3) > > > printf("invalid value (0x%x)\n", > > > @@ -222,7 +224,7 @@ > > > printf("%s\n", > > > batt_msg[aps.ap_batt_stat]); > > > printf("\tRemaining battery life: "); > > > - if (aps.ap_batt_life >= 255) > > > + if (aps.ap_batt_life == (u_int)-1) > > > printf("unknown\n"); > > > else if (aps.ap_batt_life <= 100) > > > printf("%d%%\n", aps.ap_batt_life); > > > > Please commit this patch after deciding whether you want to go with ~0 or > > (u_int)-1. > > We decided to go with -1. The apm.c patch currently will not apply due to > the re-structure of apm. The following patch will: > > http://liamfoy.kerneled.org/apm.diff > > After more digging, apm -l should return 255(stated in man page and acpi spec). > The following patch will make it work: > > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 > @@ -449,7 +449,7 @@ > static int bat_units = 0; > static struct acpi_cmbat_softc **bat = NULL; > > - cap = min = -1; > + cap = min = 255; > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > error = 0; > > @@ -545,7 +545,7 @@ > > /* Battery life */ > if (valid_units == 0) { > - cap = -1; > + cap = 255; > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > } else { > cap = total_cap / valid_units; > @@ -649,7 +649,7 @@ > } > > if (!sc->present) { > - battinfo->cap = -1; > + battinfo->cap = 255; > battinfo->min = -1; > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > } else { Do any of you guys have any opinions/comments on the acpi_cmbat.c patch? > > I think all the patches need commiting. > > > > > -Nate > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > -- > -Liam J. Foy > http://liamfoy.kerneled.org > "Now I wish it would rain down on me" > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- -Liam J. Foy http://liamfoy.kerneled.org "Now I wish it would rain down on me" From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 21:01:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5232316A4CE for ; Wed, 23 Jun 2004 21:01:04 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E0EF043D4C for ; Wed, 23 Jun 2004 21:01:03 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 87308 invoked by uid 1000); 23 Jun 2004 21:00:47 -0000 Date: Wed, 23 Jun 2004 14:00:47 -0700 (PDT) From: Nate Lawson To: "Liam J. Foy" In-Reply-To: <20000623205805.4c299e4e.liamfoy@sepulcrum.org> Message-ID: <20040623135554.V87272@root.org> References: <20040616171408.0f88c928.liamfoy@sepulcrum.org> <20040616.135044.85075412.imp@bsdimp.com> <20040623123827.O86825@root.org> <20000623205805.4c299e4e.liamfoy@sepulcrum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 21:01:04 -0000 On Fri, 23 Jun 2000, Liam J. Foy wrote: > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) > We decided to go with -1. The apm.c patch currently will not apply due to > the re-structure of apm. The following patch will: > > http://liamfoy.kerneled.org/apm.diff Ok, good. That should help Warner. > After more digging, apm -l should return 255(stated in man page and acpi spec). > The following patch will make it work: > > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 > @@ -449,7 +449,7 @@ > static int bat_units = 0; > static struct acpi_cmbat_softc **bat = NULL; > > - cap = min = -1; > + cap = min = 255; > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > error = 0; > > @@ -545,7 +545,7 @@ > > /* Battery life */ > if (valid_units == 0) { > - cap = -1; > + cap = 255; > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > } else { > cap = total_cap / valid_units; > @@ -649,7 +649,7 @@ > } > > if (!sc->present) { > - battinfo->cap = -1; > + battinfo->cap = 255; > battinfo->min = -1; > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > } else { I disagree with this. Capacity and time remaining are both quantities represented by ints that we calculate. The man page should be updated if it's incorrect. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 21:13:15 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1EB016A4CE for ; Wed, 23 Jun 2004 21:13:15 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D8143D2F for ; Wed, 23 Jun 2004 21:13:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i5NLAvXd092869; Wed, 23 Jun 2004 15:10:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 23 Jun 2004 15:11:07 -0600 (MDT) Message-Id: <20040623.151107.13281033.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040623135554.V87272@root.org> References: <20040623123827.O86825@root.org> <20000623205805.4c299e4e.liamfoy@sepulcrum.org> <20040623135554.V87272@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.ORG Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 21:13:15 -0000 In message: <20040623135554.V87272@root.org> Nate Lawson writes: : On Fri, 23 Jun 2000, Liam J. Foy wrote: : > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) : > We decided to go with -1. The apm.c patch currently will not apply due to : > the re-structure of apm. The following patch will: : > : > http://liamfoy.kerneled.org/apm.diff : : Ok, good. That should help Warner. : : > After more digging, apm -l should return 255(stated in man page and acpi spec). : > The following patch will make it work: : > : > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 : > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 : > @@ -449,7 +449,7 @@ : > static int bat_units = 0; : > static struct acpi_cmbat_softc **bat = NULL; : > : > - cap = min = -1; : > + cap = min = 255; : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; : > error = 0; : > : > @@ -545,7 +545,7 @@ : > : > /* Battery life */ : > if (valid_units == 0) { : > - cap = -1; : > + cap = 255; : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; : > } else { : > cap = total_cap / valid_units; : > @@ -649,7 +649,7 @@ : > } : > : > if (!sc->present) { : > - battinfo->cap = -1; : > + battinfo->cap = 255; : > battinfo->min = -1; : > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; : > } else { : : I disagree with this. Capacity and time remaining are both quantities : represented by ints that we calculate. The man page should be updated if : it's incorrect. That's why I've been reluctant to make these changes... Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 21:31:07 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A789716A4CE for ; Wed, 23 Jun 2004 21:31:07 +0000 (GMT) Received: from havoc.eusc.inter.net (havoc.eusc.inter.net [213.73.101.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E0A43D1F for ; Wed, 23 Jun 2004 21:31:07 +0000 (GMT) (envelope-from plexus@snafu.de) Received: from pd9e0e5e1.dip.t-dialin.net ([217.224.229.225] helo=snafu.de) by havoc.eusc.inter.net with asmtp (Exim 3.36 #3) id 1BdFJn-0001p0-00 for acpi@freebsd.org; Wed, 23 Jun 2004 23:30:07 +0200 Message-ID: <40DA1280.7040504@snafu.de> Date: Wed, 23 Jun 2004 23:30:08 +0000 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: kernel panic in atapicam modul if acpi is enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 21:31:07 -0000 Dear list, if have got a ThinkPad R51 with an internal DVDR (acd0: DVDR at ata1-master PIO4). If I compile the kernel with atapicam modul enabled I can only boot without an panic if disabled ACPI at boot time. The message is: kernel type 12 trap stoppend at xpt_find_device... Is this an ACPI issue or not? Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 22:47:33 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA8B16A4CE for ; Wed, 23 Jun 2004 22:47:33 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0790143D3F for ; Wed, 23 Jun 2004 22:47:33 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 87952 invoked by uid 1000); 23 Jun 2004 22:47:17 -0000 Date: Wed, 23 Jun 2004 15:47:17 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040623.151107.13281033.imp@bsdimp.com> Message-ID: <20040623141913.Q87505@root.org> References: <20040623123827.O86825@root.org> <20000623205805.4c299e4e.liamfoy@sepulcrum.org> <20040623.151107.13281033.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@FreeBSD.ORG Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 22:47:33 -0000 On Wed, 23 Jun 2004, M. Warner Losh wrote: > In message: <20040623135554.V87272@root.org> > Nate Lawson writes: > : On Fri, 23 Jun 2000, Liam J. Foy wrote: > : > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) > : > We decided to go with -1. The apm.c patch currently will not apply due to > : > the re-structure of apm. The following patch will: > : > > : > http://liamfoy.kerneled.org/apm.diff > : > : Ok, good. That should help Warner. > : > : > After more digging, apm -l should return 255(stated in man page and acpi spec). > : > The following patch will make it work: > : > > : > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 > : > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 > : > @@ -449,7 +449,7 @@ > : > static int bat_units = 0; > : > static struct acpi_cmbat_softc **bat = NULL; > : > > : > - cap = min = -1; > : > + cap = min = 255; > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > : > error = 0; > : > > : > @@ -545,7 +545,7 @@ > : > > : > /* Battery life */ > : > if (valid_units == 0) { > : > - cap = -1; > : > + cap = 255; > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > : > } else { > : > cap = total_cap / valid_units; > : > @@ -649,7 +649,7 @@ > : > } > : > > : > if (!sc->present) { > : > - battinfo->cap = -1; > : > + battinfo->cap = 255; > : > battinfo->min = -1; > : > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > : > } else { > : > : I disagree with this. Capacity and time remaining are both quantities > : represented by ints that we calculate. The man page should be updated if > : it's incorrect. > > That's why I've been reluctant to make these changes... Let's just update the man page. The use of -1 is the actual behavior and programs have been written that count on this. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 22:53:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2481916A4CE for ; Wed, 23 Jun 2004 22:53:04 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E5C6843D5C for ; Wed, 23 Jun 2004 22:53:03 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 87969 invoked by uid 1000); 23 Jun 2004 22:52:52 -0000 Date: Wed, 23 Jun 2004 15:52:52 -0700 (PDT) From: Nate Lawson To: "Oliver B. Fischer" In-Reply-To: <40DA1280.7040504@snafu.de> Message-ID: <20040623155038.C87505@root.org> References: <40DA1280.7040504@snafu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: kernel panic in atapicam modul if acpi is enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 22:53:04 -0000 On Wed, 23 Jun 2004, Oliver B. Fischer wrote: > Dear list, > > if have got a ThinkPad R51 with an internal DVDR (acd0: DVDR > at ata1-master PIO4). If I compile the kernel > with atapicam modul enabled I can only boot without an panic if disabled > ACPI at boot time. > > The message is: > > kernel type 12 trap > stoppend at xpt_find_device... > > Is this an ACPI issue or not? This is likely not an ACPI issue. Are you running with "options INVARIANTS"? My laptop panics on boot without atapicam but with "options INVARIANTS" due to a use-after-free bug in ata. I'll try to track it down when I have time but I don't know the ata code really well. More of the backtrace would be helpful also. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 23 23:43:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C450C16A4CE for ; Wed, 23 Jun 2004 23:43:25 +0000 (GMT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA9A43D2D for ; Wed, 23 Jun 2004 23:43:25 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([138.89.19.189]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040623234236.CBMY27801.out008.verizon.net@[10.0.3.231]> for ; Wed, 23 Jun 2004 18:42:36 -0500 From: "Alexandre \"Sunny\" Kovalenko" To: freebsd-acpi@freebsd.org In-Reply-To: <20040623093442.P85911@root.org> References: <20040603124930.GA58885@Zeus.UBBCluj.Ro> <20040617131024.GA7772@Zeus.UBBCluj.Ro> <20040623093442.P85911@root.org> Content-Type: text/plain Message-Id: <1088034095.812.4.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 19:41:36 -0400 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [138.89.19.189] at Wed, 23 Jun 2004 18:42:36 -0500 Subject: Re: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 23:43:25 -0000 On Wed, 2004-06-23 at 12:40, Nate Lawson wrote: > On Wed, 23 Jun 2004, Dan Cojocar wrote: > > > You'll have to look at the ACPI spec if you want to decode the field > > > values. In this case, the numbers are field widths and mean FAN is 1 bit, > > > FANL is 16 bits wide. The spec won't tell you what FAN or FANL mean but > > > you can sometimes figure it out from the surrounding AML. I looked at a > > > similar ASL dump and it appears the FAN and FANL values aren't referenced > > > elsewhere. So your fan control needs to be done by something other than > > > ACPI. > > > > > > -Nate > > > > I'm confused now because i defined in my asl _AC0, _AC1 and > > their corespondent _AL0 and _AL1, and Devices for FAN, and now i can > > change active status from -1 to 0 or 1. > > I enabled debug and i see that my fan1 and fan2 are changing > > status from D3 to D0 when the temperature is bigger then AC0, but i'm > > not sure i defined correct temperatures for AC0 and AC1, because in my > > asl they were absent, and i defined AC0 at 70C and AC1 at 65C. I don't > > know if there values are correct, but now the fan is turned on at 65C > > and he gets more speed at 70C but it seems that the temperature > > is very slow decreased, maybe i'm doing something wrong here :( > > You said that it's possible that my fan control is done by > > something other than ACPI, how can i establish who is responsible with > > my fans? > > Please try not to top-post, it makes reading the message difficult. > > You defined your own custom ACPI cooling objects in your ASL. The BIOS > manufacturer did not. Therefore, on other OS's that work with the stock > ASL (i.e. Windows), fan control is done some other way than through ACPI. > Perhaps it's done via SMM. Do the fans ever come on while running with > the stock ASL? Or, it's done with a custom driver via SMbus or by > directly poking the super I/O chip. You know that "power/heat/hotkey" > custom app that comes with just about every laptop? That's what it's > doing. If the laptop was more ACPI-compliant, the fans would be defined > in your ASL and you wouldn't have to use a custom ASL. > > As for your custom ASL, it sounds like you got things right. > > -Nate > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" For whatever it worth: in my laptop fan control was safely tucked into RTEP. I was following the temperature reporting trail to find it there. Alexandre "Sunny" Kovalenko. From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 24 03:02:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE0C716A4CE for ; Thu, 24 Jun 2004 03:02:22 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A380F43D53 for ; Thu, 24 Jun 2004 03:02:22 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 89294 invoked by uid 1000); 24 Jun 2004 03:02:24 -0000 Date: Wed, 23 Jun 2004 20:02:24 -0700 (PDT) From: Nate Lawson To: Dan Cojocar , "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1088034095.812.4.camel@RabbitsDen> Message-ID: <20040623195954.A89232@root.org> References: <20040603124930.GA58885@Zeus.UBBCluj.Ro> <20040617131024.GA7772@Zeus.UBBCluj.Ro> <20040623093442.P85911@root.org> <1088034095.812.4.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 03:02:23 -0000 On Wed, 23 Jun 2004, Alexandre "Sunny" Kovalenko wrote: > On Wed, 2004-06-23 at 12:40, Nate Lawson wrote: > > On Wed, 23 Jun 2004, Dan Cojocar wrote: > > > You said that it's possible that my fan control is done by > > > something other than ACPI, how can i establish who is responsible with > > > my fans? > > > > You defined your own custom ACPI cooling objects in your ASL. The BIOS > > manufacturer did not. Therefore, on other OS's that work with the stock > > ASL (i.e. Windows), fan control is done some other way than through ACPI. > > Perhaps it's done via SMM. Do the fans ever come on while running with > > the stock ASL? Or, it's done with a custom driver via SMbus or by > > directly poking the super I/O chip. You know that "power/heat/hotkey" > > custom app that comes with just about every laptop? That's what it's > > doing. If the laptop was more ACPI-compliant, the fans would be defined > > in your ASL and you wouldn't have to use a custom ASL. > > > > As for your custom ASL, it sounds like you got things right. > > For whatever it worth: in my laptop fan control was safely tucked into > RTEP. I was following the temperature reporting trail to find it there. Just as a test, he should try this Linux app on Linux: http://sourceforge.net/projects/omke/ There's a low-priority TODO to write a similar driver for FreeBSD. It is apparently needed for control of HP and Toshiba Satellite laptops. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 24 09:22:29 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D1816A4CE for ; Thu, 24 Jun 2004 09:22:29 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2EAC43D48 for ; Thu, 24 Jun 2004 09:22:28 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdQQk-0007S3-00; Thu, 24 Jun 2004 11:22:02 +0200 Received: from [172.23.4.135] (helo=config8.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdQQk-0006tp-00; Thu, 24 Jun 2004 11:22:02 +0200 Received: from www-data by config8.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1BdQQj-0003nk-00; Thu, 24 Jun 2004 11:22:01 +0200 To: =?iso-8859-1?Q?Nate_Lawson?= From: Message-Id: <27418837$108806874740da9c8b50d419.89444399@config8.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 27418837 X-Mailer: Webmail X-Routing: UK X-Received: from config8 by 194.119.153.6 with HTTP id 27418837 for nate@root.org; Thu, 24 Jun 2004 11:22:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 24 Jun 2004 11:22:01 +0200 X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.4.135 cc: acpi@FreeBSD.ORG Subject: Re: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 09:22:29 -0000 Nate Lawson wrote on 24.06.2004, 00:47:17: > On Wed, 23 Jun 2004, M. Warner Losh wrote: > > In message: > > Nate Lawson writes: > > : On Fri, 23 Jun 2000, Liam J. Foy wrote: > > : > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) > > : > We decided to go with -1. The apm.c patch currently will not apply due to > > : > the re-structure of apm. The following patch will: > > : > > > : > http://liamfoy.kerneled.org/apm.diff > > : > > : Ok, good. That should help Warner. > > : > > : > After more digging, apm -l should return 255(stated in man page and acpi spec). > > : > The following patch will make it work: > > : > > > : > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 > > : > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 > > : > @@ -449,7 +449,7 @@ > > : > static int bat_units = 0; > > : > static struct acpi_cmbat_softc **bat = NULL; > > : > > > : > - cap = min = -1; > > : > + cap = min = 255; > > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > > : > error = 0; > > : > > > : > @@ -545,7 +545,7 @@ > > : > > > : > /* Battery life */ > > : > if (valid_units == 0) { > > : > - cap = -1; > > : > + cap = 255; > > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > > : > } else { > > : > cap = total_cap / valid_units; > > : > @@ -649,7 +649,7 @@ > > : > } > > : > > > : > if (!sc->present) { > > : > - battinfo->cap = -1; > > : > + battinfo->cap = 255; > > : > battinfo->min = -1; > > : > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > > : > } else { > > : > > : I disagree with this. Capacity and time remaining are both quantities > > : represented by ints that we calculate. The man page should be updated if > > : it's incorrect. > > > > That's why I've been reluctant to make these changes... > > Let's just update the man page. The use of -1 is the actual behavior and > programs have been written that count on this. Right ok. I just gathered that's what needed returning. Anyway I will patch it when I get home and mail the acpi@ list the patch for one of you guys to commit. > > -Nate -- Best Regards, Liam Foy "FreeBSD, the power to serve!" From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 24 16:41:28 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B7FC16A4CE for ; Thu, 24 Jun 2004 16:41:28 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F85343D53 for ; Thu, 24 Jun 2004 16:41:27 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdXHT-0002v4-00; Thu, 24 Jun 2004 18:40:55 +0200 Received: from [217.43.76.39] (helo=liamfoy.ath.cx) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BdXHT-0005Bf-00; Thu, 24 Jun 2004 18:40:55 +0200 Date: Thu, 24 Jun 2004 17:39:26 +0100 From: "Liam J. Foy" To: Message-Id: <20040624173926.47274bc3.liamfoy@sepulcrum.org> In-Reply-To: <27418837$108806874740da9c8b50d419.89444399@config8.schlund.de> References: <27418837$108806874740da9c8b50d419.89444399@config8.schlund.de> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.ORG Subject: Re: apm problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 16:41:28 -0000 On Thu, 24 Jun 2004 11:22:01 +0200 wrote: > > Nate Lawson wrote on 24.06.2004, 00:47:17: > > On Wed, 23 Jun 2004, M. Warner Losh wrote: > > > In message: > > > Nate Lawson writes: > > > : On Fri, 23 Jun 2000, Liam J. Foy wrote: > > > : > On Wed, 23 Jun 2004 12:40:40 -0700 (PDT) > > > : > We decided to go with -1. The apm.c patch currently will not apply due to > > > : > the re-structure of apm. The following patch will: > > > : > > > > : > http://liamfoy.kerneled.org/apm.diff > > > : > > > : Ok, good. That should help Warner. > > > : > > > : > After more digging, apm -l should return 255(stated in man page and acpi spec). > > > : > The following patch will make it work: > > > : > > > > : > --- /usr/src/sys/dev/acpica/acpi_cmbat.c Tue Jun 22 16:40:35 2004 > > > : > +++ /hd2/acpi_cmbat.c Tue Jun 22 17:02:18 2004 > > > : > @@ -449,7 +449,7 @@ > > > : > static int bat_units = 0; > > > : > static struct acpi_cmbat_softc **bat = NULL; > > > : > > > > : > - cap = min = -1; > > > : > + cap = min = 255; > > > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > > > : > error = 0; > > > : > > > > : > @@ -545,7 +545,7 @@ > > > : > > > > : > /* Battery life */ > > > : > if (valid_units == 0) { > > > : > - cap = -1; > > > : > + cap = 255; > > > : > batt_stat = ACPI_BATT_STAT_NOT_PRESENT; > > > : > } else { > > > : > cap = total_cap / valid_units; > > > : > @@ -649,7 +649,7 @@ > > > : > } > > > : > > > > : > if (!sc->present) { > > > : > - battinfo->cap = -1; > > > : > + battinfo->cap = 255; > > > : > battinfo->min = -1; > > > : > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > > > : > } else { > > > : > > > : I disagree with this. Capacity and time remaining are both quantities > > > : represented by ints that we calculate. The man page should be updated if > > > : it's incorrect. > > > > > > That's why I've been reluctant to make these changes... > > > > Let's just update the man page. The use of -1 is the actual behavior and > > programs have been written that count on this. > > Right ok. I just gathered that's what needed returning. Anyway > I will patch it when I get home and mail the acpi@ list the patch > for one of you guys to commit. Here is the man page patch. Can one of you guys commit it? http://liamfoy.kerneled.org/freebsd/apm.8.diff Thanks, > > > > > -Nate > -- > Best Regards, > Liam Foy > "FreeBSD, the power to serve!" -- -Liam J. Foy http://liamfoy.kerneled.org "Now I wish it would rain down on me" From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 26 15:22:05 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A54116A4CE for ; Sat, 26 Jun 2004 15:22:05 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB78843D53 for ; Sat, 26 Jun 2004 15:22:04 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BeF06-0006d2-00 for acpi@freebsd.org; Sat, 26 Jun 2004 17:21:54 +0200 Received: from [217.43.76.38] (helo=liamfoy.ath.cx) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BeF06-0001PD-00 for acpi@freebsd.org; Sat, 26 Jun 2004 17:21:54 +0200 Date: Sat, 26 Jun 2004 16:20:24 +0100 From: "Liam J. Foy" To: acpi@freebsd.org Message-Id: <20040626162024.1ebc2b61.liamfoy@sepulcrum.org> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: apm -t suggestion X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2004 15:22:05 -0000 Hey guys, I was looking at the following code in acpi_cmbat.c (/usr/src/sys/dev/acpica/): [snip] } else { /* Couldn't find valid rate and full battery time */ bat[i]->min = 0; } 0 is what is eventually returned from apm -t when it couldn't find valid rate or full battery time. I think this should be set to -1 (unknown) instead of 0 as we don't have 0 seconds remaining. Either that or it is mentioned in the man page. What do you guys think ? -- -Liam J. Foy http://liamfoy.kerneled.org