From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 24 11:02:05 2005 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 AF09C16A4CE for ; Mon, 24 Jan 2005 11:02:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E6543D49 for ; Mon, 24 Jan 2005 11:02:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0OB25Du018866 for ; Mon, 24 Jan 2005 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0OB24VS018860 for freebsd-acpi@freebsd.org; Mon, 24 Jan 2005 11:02:04 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Jan 2005 11:02:04 GMT Message-Id: <200501241102.j0OB24VS018860@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, 24 Jan 2005 11:02:05 -0000 Current FreeBSD problem reports Critical problems 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/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2004/01/22] i386/61703 acpi ACPI + Sound + Boot = Reboot o [2004/03/17] kern/64365 acpi ACPI problems f [2004/05/25] i386/67189 acpi ACPI S3 reboot computer on Dell Latitude o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) f [2004/06/23] i386/68219 acpi ACPI + snd_maestro3 problem o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi acpi / thermal support o [2004/11/21] kern/74215 acpi [request] add ACPI headers to /usr/includ 8 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 24 11:56:11 2005 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 881CA16A4CE for ; Mon, 24 Jan 2005 11:56:11 +0000 (GMT) Received: from haven.hypernet.ch (hypernet.ch [212.55.218.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9430E43D31 for ; Mon, 24 Jan 2005 11:56:10 +0000 (GMT) (envelope-from chris@hypernet.ch) Received-SPF: pass (haven.hypernet.ch: localhost is always allowed.) client-ip=127.0.0.1; envelope-from=; helo=localhost; Received: from localhost (localhost [127.0.0.1]) by haven.hypernet.ch (8.12.11/8.12.11) with ESMTP id j0OBu3fh022825 for ; Mon, 24 Jan 2005 12:56:07 +0100 (MET) (envelope-from chris@hypernet.ch) Date: Mon, 24 Jan 2005 12:56:03 +0100 (MET) From: Christoph Steigmeier X-X-Sender: chris@haven To: freebsd-acpi@freebsd.org Message-ID: <20050124125133.W59714@haven> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-AntiVirus: checked by AntiVir Milter (version: 1.1; AVE: 6.29.0.8; VDF: 6.29.0.76; host: haven.hypernet.ch) Subject: Asus M6N(e) Petition to request ASUS to fix Battery status related errors in DSDT 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, 24 Jan 2005 11:56:11 -0000 Hello http://www.petitiononline.com/M6NBIOS/petition.html Regards Chris From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 24 17:56:42 2005 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 3568C16A4CE for ; Mon, 24 Jan 2005 17:56:42 +0000 (GMT) Received: from rogue.ncsl.nist.gov (rogue.ncsl.nist.gov [129.6.101.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 812E243D58 for ; Mon, 24 Jan 2005 17:56:41 +0000 (GMT) (envelope-from ian.soboroff@nist.gov) Received: from rogue.ncsl.nist.gov.nist.gov (localhost.localdomain [127.0.0.1]) by rogue.ncsl.nist.gov (8.12.11/8.12.11) with ESMTP id j0OHufl3010695 for ; Mon, 24 Jan 2005 12:56:41 -0500 From: Ian Soboroff To: freebsd-acpi@freebsd.org Date: Mon, 24 Jan 2005 12:56:41 -0500 Message-ID: <9cfoefevhgm.fsf@rogue.ncsl.nist.gov> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Resume problem with mouse, 5.3 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, 24 Jan 2005 17:56:42 -0000 I'm running 5.3-RELEASE, with a patch to the kernel that lets the video suspend properly. ACPI suspend and resume work fine for me, except that my mouse doesn't respond on resume. I have to 'killall -HUP moused' to wake it up. Is there a fix for this, or can I at least automate the killall? I've tried creating /etc/rc.suspend and /etc/rc.resume as mentioned in the handbook, but they don't seem to get run at all. My laptop, if this helps at all, is a Fujitsu P-2110. In general it works great with FreeBSD (and Linux too), ACPI in general works fine although I wish the battery would last as long as under APM suspend under Linux. (APM suspend never worked for me in FreeBSD.) Sorry if it's a newbie question. Ian From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 24 22:13:40 2005 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 198A816A4CE for ; Mon, 24 Jan 2005 22:13:40 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6635743D49 for ; Mon, 24 Jan 2005 22:13:39 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-250-186-188.dsl.wotnoh.ameritech.net [68.250.186.188]) (authenticated bits=0)j0OLmXmQ093321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 24 Jan 2005 16:48:34 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-acpi@freebsd.org Date: Mon, 24 Jan 2005 17:16:43 -0500 User-Agent: KMail/1.7 References: <9cfoefevhgm.fsf@rogue.ncsl.nist.gov> In-Reply-To: <9cfoefevhgm.fsf@rogue.ncsl.nist.gov> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart122964180.CAR2GsaVPk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501241716.52836.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com Subject: Re: Resume problem with mouse, 5.3 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, 24 Jan 2005 22:13:40 -0000 --nextPart122964180.CAR2GsaVPk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 24 January 2005 12:56 pm, Ian Soboroff wrote: > I'm running 5.3-RELEASE, with a patch to the kernel that lets the > video suspend properly. ACPI suspend and resume work fine for me, > except that my mouse doesn't respond on resume. I have to 'killall > -HUP moused' to wake it up. > > Is there a fix for this, or can I at least automate the killall? I've > tried creating /etc/rc.suspend and /etc/rc.resume as mentioned in the > handbook, but they don't seem to get run at all. > > My laptop, if this helps at all, is a Fujitsu P-2110. In general it > works great with FreeBSD (and Linux too), ACPI in general works fine > although I wish the battery would last as long as under APM suspend > under Linux. (APM suspend never worked for me in FreeBSD.) > > Sorry if it's a newbie question. > > Ian > I've got this exact same system. You need to add the following to=20 your /boot/device.hints to fix the mouse resume issue: hint.psm.0.flags=3D"0x3000" Also the issue about poor battery life under ACPI S3 suspend (I believe you= r=20 APM terminology is incorrect since APM suspend has good battery life, but=20 other stuff breaks) is that certain devices aren't shutdown fully since the= y=20 aren't in the 2110's DSDT and the drivers don't shut them down as the shoul= d. =20 To get a significantly better battery life you will need to search through= =20 the archives of this list and look for the acpi_video DPMS patch posted by= =20 jhb. This will make things much better, but there are still a few things=20 that need to be fixed in the drivers. =2D-=20 Anish Mistry --nextPart122964180.CAR2GsaVPk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB9XPUxqA5ziudZT0RAvd1AKCzhnjthb+PnRjl5J2xCw2d2n9XAwCdElFj +QMefx2Lzvxe2DGce2nrVEo= =yugN -----END PGP SIGNATURE----- --nextPart122964180.CAR2GsaVPk-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 25 04:25:20 2005 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 17D9916A4CE for ; Tue, 25 Jan 2005 04:25:20 +0000 (GMT) Received: from omsk.mushinsky.net (omsk.mushinsky.net [66.114.66.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57FF943D58 for ; Tue, 25 Jan 2005 04:25:19 +0000 (GMT) (envelope-from imush@mail.ru) Received: from omsk.mushinsky.net (localhost [127.0.0.1]) by omsk.mushinsky.net (8.13.1/8.13.1) with ESMTP id j0P4PLcF001090 for ; Mon, 24 Jan 2005 23:25:21 -0500 (EST) (envelope-from imush@mail.ru) Received: from localhost (localhost [[UNIX: localhost]]) by omsk.mushinsky.net (8.13.1/8.13.1/Submit) id j0P4PLY3001089 for freebsd-acpi@freebsd.org; Mon, 24 Jan 2005 23:25:21 -0500 (EST) (envelope-from imush@mail.ru) X-Authentication-Warning: omsk.mushinsky.net: itz set sender to imush@mail.ru using -f From: Isaac Mushinsky To: freebsd-acpi@freebsd.org Date: Mon, 24 Jan 2005 23:25:20 -0500 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501242325.21013.imush@mail.ru> Subject: newbie question - how to read temerature 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, 25 Jan 2005 04:25:20 -0000 I have Dell Precision 530 2x1.7 gHz Xeon. Trying to replace the Dell's noisy fans I wanted to make sure the CPU temperatures are normal. But I can find no way to read the temperatures at all. ASL dumped with acpidump does not compile. So as not to run too much text in the mail, here are the outputs: (compiled with ACPI_DEBUG) dmesg: http://omsk.mushinsky.net/acpi/dmesg acpidump -t -d: http://omsk.mushinsky.net/acpi/asl iasl errors: http://omsk.mushinsky.net/acpi/iasl finally, $ sysctl -a hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% Is it possible at all to monitor temperature on this box? If not ACPI, is there some other way? Dell's BIOS setup utility does not provide temperature either, so even at the cost of rebooting I cannot tell what it is. Sorry for dumb questions, I have never had to deal with this before. Thanks for any help, itz From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 25 05:01:54 2005 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 40A4916A4CE for ; Tue, 25 Jan 2005 05:01:54 +0000 (GMT) Received: from sccimhc92.asp.att.net (sccimhc92.asp.att.net [63.240.76.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E27A443D49 for ; Tue, 25 Jan 2005 05:01:53 +0000 (GMT) (envelope-from freebsd@nbritton.org) Received: from [192.168.1.10] (12-223-129-46.client.insightbb.com[12.223.129.46]) by sccimhc92.asp.att.net (sccimhc92) with ESMTP id <20050125050153i92009uv4ge>; Tue, 25 Jan 2005 05:01:53 +0000 Message-ID: <41F5D2C0.2080504@nbritton.org> Date: Mon, 24 Jan 2005 23:01:52 -0600 From: Nikolas Britton User-Agent: Mozilla Thunderbird 1.0 (X11/20041230) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Isaac Mushinsky References: <200501242325.21013.imush@mail.ru> In-Reply-To: <200501242325.21013.imush@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: newbie question - how to read temerature 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, 25 Jan 2005 05:01:54 -0000 Isaac Mushinsky wrote: >I have Dell Precision 530 2x1.7 gHz Xeon. Trying to replace the Dell's noisy >fans I wanted to make sure the CPU temperatures are normal. But I can find no >way to read the temperatures at all. ASL dumped with acpidump does not >compile. > > > > I Have a Dell 530 Workstation (1.4GHz Xeon) and AFAIK it has NO capabilitys for hardware monitoring. From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 25 15:18:41 2005 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 1C32316A4CE for ; Tue, 25 Jan 2005 15:18:41 +0000 (GMT) Received: from mailfe05.swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332C243D54 for ; Tue, 25 Jan 2005 15:18:40 +0000 (GMT) (envelope-from soeren@whiteswan.dk) X-T2-Posting-ID: oO7KdwR4nTMcCnUFr0bZ8g== Received: from whiteswan.dk ([83.72.1.74] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 4.2.7) with SMTP id 82609281 for freebsd-acpi@freebsd.org; Tue, 25 Jan 2005 16:18:38 +0100 Received: (qmail 11752 invoked from network); 25 Jan 2005 15:18:38 -0000 Received: from 192.168.2.2 by bluebird.whiteswan.dk (envelope-from , uid 82) with qmail-scanner-1.24 (clamdscan: 0.80/533. spamassassin: 3.0.2. Clear:RC:1(192.168.2.2):. Processed in 0.587383 secs); 25 Jan 2005 15:18:38 -0000 X-Qmail-Scanner-Mail-From: soeren@whiteswan.dk via bluebird.whiteswan.dk X-Qmail-Scanner: 1.24 (Clear:RC:1(192.168.2.2):. Processed in 0.587383 secs) Received: from unknown (HELO ?127.0.0.1?) (192.168.2.2) by whiteswan.dk with SMTP; 25 Jan 2005 15:18:37 -0000 Message-ID: <41F66366.4060208@whiteswan.dk> Date: Tue, 25 Jan 2005 16:19:02 +0100 From: Soeren Larsen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Steigmeier References: <20050124125133.W59714@haven> In-Reply-To: <20050124125133.W59714@haven> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Asus M6N(e) Petition to request ASUS to fix Battery statusrelated errors in DSDT 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, 25 Jan 2005 15:18:41 -0000 Christoph Steigmeier wrote: > http://www.petitiononline.com/M6NBIOS/petition.html Signed. Will you do us a favor and let us know if ASUS makes a move on this? Regards, Soeren Larsen From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 25 15:39:16 2005 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 3B9F016A4CE for ; Tue, 25 Jan 2005 15:39:16 +0000 (GMT) Received: from rogue.ncsl.nist.gov (rogue.ncsl.nist.gov [129.6.101.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id B071143D46 for ; Tue, 25 Jan 2005 15:39:15 +0000 (GMT) (envelope-from ian.soboroff@nist.gov) Received: from rogue.ncsl.nist.gov.nist.gov (localhost.localdomain [127.0.0.1])j0PFdEjK016579; Tue, 25 Jan 2005 10:39:15 -0500 From: Ian Soboroff To: Anish Mistry References: <9cfoefevhgm.fsf@rogue.ncsl.nist.gov> <200501241716.52836.mistry.7@osu.edu> Date: Tue, 25 Jan 2005 10:39:14 -0500 In-Reply-To: <200501241716.52836.mistry.7@osu.edu> (Anish Mistry's message of "Mon, 24 Jan 2005 17:16:43 -0500") Message-ID: <9cfmzuxplgd.fsf@rogue.ncsl.nist.gov> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 25 Jan 2005 15:39:16 -0000 Anish Mistry writes: > Also the issue about poor battery life under ACPI S3 suspend (I > believe your APM terminology is incorrect since APM suspend has good > battery life, but other stuff breaks) is that certain devices aren't > shutdown fully since they aren't in the 2110's DSDT and the drivers > don't shut them down as the should. To get a significantly better > battery life you will need to search through the archives of this > list and look for the acpi_video DPMS patch posted by jhb. This > will make things much better, but there are still a few things that > need to be fixed in the drivers. I am running with the acpi_video patch, and I can have the laptop in S3 suspend for about a weekend. (This is with the high-cap main battery and an expansion bay battery, btw.) APM suspend indeed breaks something as I could never resume from it. There was a recent patch mentioned which I am planning to try as well. I know I should be able to achieve better suspended battery life, since I could go a week or two in APM suspend from Linux. (Before I get labelled a Linux troll, I'm a recent convert to FreeBSD on my laptop and like it a lot so far... slimmer memory footprint and much better documented. ACPI suspend never worked for me under Linux, so APM there is all I have to compare with. Battery drain under suspend means I have to carry around a power cord again, and that's no fun. I'm happy to test stuff as time permits.) Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 25 19:32:43 2005 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 71B9516A4CF for ; Tue, 25 Jan 2005 19:32:43 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B9D43D2F for ; Tue, 25 Jan 2005 19:32:43 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Tue, 25 Jan 2005 11:32:41 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8F9145D08; Tue, 25 Jan 2005 11:32:40 -0800 (PST) To: Ian Soboroff In-reply-to: Your message of "Tue, 25 Jan 2005 10:39:14 EST." <9cfmzuxplgd.fsf@rogue.ncsl.nist.gov> Date: Tue, 25 Jan 2005 11:32:40 -0800 From: "Kevin Oberman" Message-Id: <20050125193240.8F9145D08@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 25 Jan 2005 19:32:43 -0000 > From: Ian Soboroff > Date: Tue, 25 Jan 2005 10:39:14 -0500 > Sender: owner-freebsd-acpi@freebsd.org > > Anish Mistry writes: > > > Also the issue about poor battery life under ACPI S3 suspend (I > > believe your APM terminology is incorrect since APM suspend has good > > battery life, but other stuff breaks) is that certain devices aren't > > shutdown fully since they aren't in the 2110's DSDT and the drivers > > don't shut them down as the should. To get a significantly better > > battery life you will need to search through the archives of this > > list and look for the acpi_video DPMS patch posted by jhb. This > > will make things much better, but there are still a few things that > > need to be fixed in the drivers. > > I am running with the acpi_video patch, and I can have the laptop in > S3 suspend for about a weekend. (This is with the high-cap main > battery and an expansion bay battery, btw.) APM suspend indeed breaks > something as I could never resume from it. > > There was a recent patch mentioned which I am planning to try as > well. I know I should be able to achieve better suspended battery > life, since I could go a week or two in APM suspend from Linux. > > (Before I get labelled a Linux troll, I'm a recent convert to FreeBSD > on my laptop and like it a lot so far... slimmer memory footprint and > much better documented. ACPI suspend never worked for me under Linux, > so APM there is all I have to compare with. Battery drain under > suspend means I have to carry around a power cord again, and that's no > fun. I'm happy to test stuff as time permits.) Look in the archives for acpi_pwr5.diff. The posting is by njl@ (Nate Lawson). It will improve power management capability for PCI devices. (It puts them in standby mode on a suspend to RAM.) -- 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 From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 26 03:39:28 2005 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 7947416A4CE for ; Wed, 26 Jan 2005 03:39:28 +0000 (GMT) Received: from imss.phys.ntu.edu.tw (imss.phys.ntu.edu.tw [140.112.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF2743D1D for ; Wed, 26 Jan 2005 03:39:23 +0000 (GMT) (envelope-from takashi.inoue@uni-tuebingen.de) Received: from imss.phys.ntu.edu.tw (localhost.localdomain [127.0.0.1]) by localhost.phys.ntu.edu.tw (Postfix) with ESMTP id 4F56F1F384 for ; Wed, 26 Jan 2005 11:39:18 +0800 (CST) Received: from [127.0.0.1] (unknown [140.112.102.113])by imss.phys.ntu.edu.t w (Postfix) with ESMTP id 3B6D11F376for ; Wed, 26 Jan 2005 11:39:18 +0800 (CST) Message-ID: <41F710E4.6040407@uni-tuebingen.de> Date: Wed, 26 Jan 2005 11:39:16 +0800 From: Takashi Inoue User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/ 20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-imss-version: 2.12 X-imss-result: Passed X-imss-scores: Clean:19.08379 C:20 M:2 S:5 R:5 X-imss-settings: Baseline:3 C:2 M:2 S:3 R:3 (0.0500 0.1000) Subject: ATA failure at resume on ThinkPad X40 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, 26 Jan 2005 03:39:28 -0000 Hi friends, I am using 5.3R on ThinkPad X40. When it resume from ACPI S3 sleep, an ATA failure occur as: ---------------------------------------- ioapic_suspend: not implemented! ad0: FAILURE - ATA_IDENTIFY timed out ad0: WARNING - removed from configuration ---------------------------------------- Then, I cannot do even shutdown. Therefore I don't use suspend/resume on my ThinkPad now. It is pity. Does anyone know a reason and solution of it? Or, does anyone here use ACPI S3 successfully on X40? Disabling apic helps. But I prefer to use apic because of better response. Any infomation and comment is welcome. Thanks. Cheers, Takashi From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 26 11:33:12 2005 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 8E08916A4CF for ; Wed, 26 Jan 2005 11:33:12 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC1AF43D4C for ; Wed, 26 Jan 2005 11:33:11 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1CtlQ1-0003Jj-00; Wed, 26 Jan 2005 12:33:05 +0100 Date: Wed, 26 Jan 2005 12:33:05 +0100 To: Isaac Mushinsky Message-ID: <20050126113305.GA12500@poupinou.org> References: <200501242325.21013.imush@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501242325.21013.imush@mail.ru> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-acpi@freebsd.org Subject: Re: newbie question - how to read temerature 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, 26 Jan 2005 11:33:12 -0000 On Mon, Jan 24, 2005 at 11:25:20PM -0500, Isaac Mushinsky wrote: > I have Dell Precision 530 2x1.7 gHz Xeon. Trying to replace the Dell's noisy > fans I wanted to make sure the CPU temperatures are normal. But I can find no > way to read the temperatures at all. ASL dumped with acpidump does not > compile. > > So as not to run too much text in the mail, here are the outputs: > > (compiled with ACPI_DEBUG) > > dmesg: http://omsk.mushinsky.net/acpi/dmesg > acpidump -t -d: http://omsk.mushinsky.net/acpi/asl > iasl errors: http://omsk.mushinsky.net/acpi/iasl Yep. That's a strange bug. Its because actually a device is named 'DMA' which is a reserved word (though I'm pretty sure this is allowed in ACPI spec). Just changing that one like that: --- asl 2005/01/26 11:20:57 1.1 +++ asl 2005/01/26 11:25:47 @@ -1663,7 +1663,7 @@ Name (_UID, 0x0A) OperationRegion (P40C, PCI_Config, 0x60, 0x04) OperationRegion (P41C, PCI_Config, 0x68, 0x04) - Device (DMA) + Device (DMA1) { Name (_HID, EisaId ("PNP0200")) Method (_CRS, 0, NotSerialized) I think this is a bug in iasl. Anyway, recompiling your asl will not help you though for your problem. So I dont think its usefull to override by your own DSDT. > finally, > $ sysctl -a hw.acpi > hw.acpi.supported_sleep_state: S1 S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.reset_video: 1 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > There is no thermal zone in this ASL. So no hope to get it via ACPI. But, IIRC, there is a support under Linux, but for i8k models, which use a propritary, non documented BIOS interface from Dell. I think this is the case with the Precision. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 03:33:49 2005 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 EEF0D16A4CE for ; Thu, 27 Jan 2005 03:33:49 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 193E443D31 for ; Thu, 27 Jan 2005 03:33:47 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-250-186-188.dsl.wotnoh.ameritech.net [68.250.186.188]) (authenticated bits=0)j0R38QmQ053838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 26 Jan 2005 22:08:27 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Kevin Oberman Date: Wed, 26 Jan 2005 22:36:36 -0500 User-Agent: KMail/1.7 References: <20050125193240.8F9145D08@ptavv.es.net> In-Reply-To: <20050125193240.8F9145D08@ptavv.es.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7208063.0TRPpiditP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501262236.53148.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 27 Jan 2005 03:33:50 -0000 --nextPart7208063.0TRPpiditP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 25 January 2005 02:32 pm, Kevin Oberman wrote: > > From: Ian Soboroff > > Date: Tue, 25 Jan 2005 10:39:14 -0500 > > Sender: owner-freebsd-acpi@freebsd.org > > > > Anish Mistry writes: > > > Also the issue about poor battery life under ACPI S3 suspend (I > > > believe your APM terminology is incorrect since APM suspend has good > > > battery life, but other stuff breaks) is that certain devices aren't > > > shutdown fully since they aren't in the 2110's DSDT and the drivers > > > don't shut them down as the should. To get a significantly better > > > battery life you will need to search through the archives of this > > > list and look for the acpi_video DPMS patch posted by jhb. This > > > will make things much better, but there are still a few things that > > > need to be fixed in the drivers. > > > > I am running with the acpi_video patch, and I can have the laptop in > > S3 suspend for about a weekend. (This is with the high-cap main > > battery and an expansion bay battery, btw.) APM suspend indeed breaks > > something as I could never resume from it. > > > > There was a recent patch mentioned which I am planning to try as > > well. I know I should be able to achieve better suspended battery > > life, since I could go a week or two in APM suspend from Linux. > > > > (Before I get labelled a Linux troll, I'm a recent convert to FreeBSD > > on my laptop and like it a lot so far... slimmer memory footprint and > > much better documented. ACPI suspend never worked for me under Linux, > > so APM there is all I have to compare with. Battery drain under > > suspend means I have to carry around a power cord again, and that's no > > fun. I'm happy to test stuff as time permits.) > > Look in the archives for acpi_pwr5.diff. The posting is by njl@ (Nate > Lawson). It will improve power management capability for PCI > devices. (It puts them in standby mode on a suspend to RAM.) I'm running current that has the power patch already merged, and just did s= ome=20 tests. It doesn't help any for this system unfortunately. I'm not sure=20 what else to do to improve S3 from draining the battery. =2D-=20 Anish Mistry --nextPart7208063.0TRPpiditP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB+GHVxqA5ziudZT0RAswCAJ9qESeAMkkDK1Vjrz331v0UezsmfACcDjFH y2jbzGiEgQ8grkr21baDoPo= =GD2H -----END PGP SIGNATURE----- --nextPart7208063.0TRPpiditP-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 03:40:37 2005 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 D91D216A4CE for ; Thu, 27 Jan 2005 03:40:37 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BEBC43D4C for ; Thu, 27 Jan 2005 03:40:37 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 26 Jan 2005 19:40:36 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 632D25D09; Wed, 26 Jan 2005 19:40:36 -0800 (PST) To: Anish Mistry In-reply-to: Your message of "Wed, 26 Jan 2005 22:36:36 EST." <200501262236.53148.mistry.7@osu.edu> Date: Wed, 26 Jan 2005 19:40:36 -0800 From: "Kevin Oberman" Message-Id: <20050127034036.632D25D09@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 27 Jan 2005 03:40:38 -0000 > From: Anish Mistry > Date: Wed, 26 Jan 2005 22:36:36 -0500 > > --nextPart7208063.0TRPpiditP > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > On Tuesday 25 January 2005 02:32 pm, Kevin Oberman wrote: > > > From: Ian Soboroff > > > Date: Tue, 25 Jan 2005 10:39:14 -0500 > > > Sender: owner-freebsd-acpi@freebsd.org > > > > > > Anish Mistry writes: > > > > Also the issue about poor battery life under ACPI S3 suspend (I > > > > believe your APM terminology is incorrect since APM suspend has good > > > > battery life, but other stuff breaks) is that certain devices aren't > > > > shutdown fully since they aren't in the 2110's DSDT and the drivers > > > > don't shut them down as the should. To get a significantly better > > > > battery life you will need to search through the archives of this > > > > list and look for the acpi_video DPMS patch posted by jhb. This > > > > will make things much better, but there are still a few things that > > > > need to be fixed in the drivers. > > > > > > I am running with the acpi_video patch, and I can have the laptop in > > > S3 suspend for about a weekend. (This is with the high-cap main > > > battery and an expansion bay battery, btw.) APM suspend indeed breaks > > > something as I could never resume from it. > > > > > > There was a recent patch mentioned which I am planning to try as > > > well. I know I should be able to achieve better suspended battery > > > life, since I could go a week or two in APM suspend from Linux. > > > > > > (Before I get labelled a Linux troll, I'm a recent convert to FreeBSD > > > on my laptop and like it a lot so far... slimmer memory footprint and > > > much better documented. ACPI suspend never worked for me under Linux, > > > so APM there is all I have to compare with. Battery drain under > > > suspend means I have to carry around a power cord again, and that's no > > > fun. I'm happy to test stuff as time permits.) > > > > Look in the archives for acpi_pwr5.diff. The posting is by njl@ (Nate > > Lawson). It will improve power management capability for PCI > > devices. (It puts them in standby mode on a suspend to RAM.) > I'm running current that has the power patch already merged, and just did > some tests. It doesn't help any for this system unfortunately. I'm not > sure what else to do to improve S3 from draining the battery. > -- > Anish Mistry You have all the patches I am aware of that should help power. Sorry. Maybe someone else has an idea. -- 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 From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 19:56:43 2005 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 B426A16A4CE; Thu, 27 Jan 2005 19:56:43 +0000 (GMT) Received: from phoenix.gargantuan.com (phoenix.gargantuan.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FD543D5F; Thu, 27 Jan 2005 19:56:41 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id F3FE3495; Thu, 27 Jan 2005 14:56:39 -0500 (EST) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 92F29287; Thu, 27 Jan 2005 14:56:33 -0500 (EST) Date: Thu, 27 Jan 2005 14:56:33 -0500 From: "Michael W. Oliver" To: Jung-uk Kim Message-ID: <20050127195633.GA32179@gargantuan.com> Mail-Followup-To: Jung-uk Kim , freebsd-amd64@freebsd.org, acpi@freebsd.org References: <1b1b33f10501270752473093ea@mail.gmail.com> <200501271359.30721.jkim@niksun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <200501271359.30721.jkim@niksun.com> X-WWW-URL: http://michael.gargantuan.com X-GPG-PGP-Public-Key: $X-WWW-URL/gnupg/pubkey.asc X-GPG-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Mailing-Address0: 8008 Apache Lane X-Mailing-Address1: Lakeland, FL X-Mailing-Address2: 33810-2172 X-Mailing-Address3: United States of America X-Guide-Questions: http://www.catb.org/~esr/faqs/smart-questions.html X-Guide-Netiquette: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: sgs_public_dcc_server: phoenix.gargantuan.com 1199; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, score=-105.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.1 X-Spam-Pyzor: Reported 0 times. cc: acpi@freebsd.org cc: freebsd-amd64@freebsd.org Subject: AMD64 CPU and ACPI (was Re: Configuration of Compaq R3000) 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, 27 Jan 2005 19:56:43 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005-01-27T13:59:29-0500, Jung-uk Kim wrote: > On Thursday 27 January 2005 10:52 am, Kelly Black wrote: > > Hello, > Did you use 'acpi_ppc' driver? > http://www.spa.is.uec.ac.jp/~nfukuda/software/ > You need this driver to run your laptop at full speed. CPU speed will=20 > be automatically adjusted by CPU load. However, it may take few=20 > seconds to get to the speed. You can set the speed manually by: > sysctl hw.acpi.cpu.px_control=3D0 > Please read comment in the acpi_ppc.c for more info. Whoo-hoo!!! This works on my machine (Sager 4750V) so far, and gives wonderful information: hw.acpi.cpu.px_control: -1 hw.acpi.cpu.px_highest: 0 hw.acpi.cpu.px_lowest: 2 hw.acpi.cpu.px_current: 1 hw.acpi.cpu.px_supported: 2200 1800 800 hw.acpi.cpu.px_usage: 4.62% 25.70% 69.66% (running `make clean' in /usr/ports just to push it a little) This is great! Thanks so much for posting this! This completely makes sense now that I would see the CPU speed reported as ~801MHz when the machine would boot up. I can't thank you enough. What are the chances that this could be imported into current? I am running... # uname -a FreeBSD gambit.gargantuan.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Mon Jan 10 18:33:07 EST 2005 mwoliver@gambit.gargantuan.com:/usr/obj/usr/src/sys/GAMBIT amd64 > Unfortunately if you run this laptop under heavy CPU load, CPU will=20 > heat up pretty fast and 'acpi_ec' will adjust delay to prevent=20 > excessive heat. You can ignore this behavior by hacking acpi_ec.c, I=20 > believe but it's really bad idea. I do see some ACPI errors on my laptop when I boot it up, such as: (dmesg -a | grep -i acpi): acpi_cmbat0: battery initialization start acpi_acad0: acline initialization start acpi_tz0: _CRT value is absurd, ignored (154.8C) acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_ec0: info: new max delay is 70 us acpi_ec0: info: new max delay is 100 us acpi_cmbat0: battery initialization failed, giving up <-- ugh! acpi_ec0: info: new max delay is 130 us acpi_ec0: info: new max delay is 170 us acpi_tz0: _CRT value is absurd, ignored (154.8C) acpi_tz0: _CRT value is absurd, ignored (154.8C) acpi_ec0: info: new max delay is 900 us acpi_ec0: info: new max delay is 11000 us acpi_tz0: _CRT value is absurd, ignored (154.8C) acpi_tz0: _CRT value is absurd, ignored (154.8C) acpidump stuff is here: http://michael.gargantuan.com/sager_4750v/acpidump.asl http://michael.gargantuan.com/sager_4750v/dsdt.out http://michael.gargantuan.com/sager_4750v/sysctl_hw.acpi > Laptop is not for number crunching after all. ;-) ooops! ;) --=20 Mike Oliver [see complete headers for contact information] --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB+UdxsWv7q8X6o8kRAvfFAJ9tljqGbXALfrM8n2ehKOQ34y20LwCfUDJ0 57YQ3eM50tbmS8PklRL85pA= =+nS0 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 20:31:19 2005 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 646BD16A4CE for ; Thu, 27 Jan 2005 20:31:19 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C972D43D3F for ; Thu, 27 Jan 2005 20:31:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j0RKVP2Y013413; Thu, 27 Jan 2005 15:31:25 -0500 Message-ID: <41F94F90.2020006@root.org> Date: Thu, 27 Jan 2005 12:31:12 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050125193240.8F9145D08@ptavv.es.net> In-Reply-To: <20050125193240.8F9145D08@ptavv.es.net> Content-Type: multipart/mixed; boundary="------------010609090008080106080905" cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 27 Jan 2005 20:31:19 -0000 This is a multi-part message in MIME format. --------------010609090008080106080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kevin Oberman wrote: >>From: Ian Soboroff >>I am running with the acpi_video patch, and I can have the laptop in >>S3 suspend for about a weekend. (This is with the high-cap main >>battery and an expansion bay battery, btw.) APM suspend indeed breaks >>something as I could never resume from it. >> >>There was a recent patch mentioned which I am planning to try as >>well. I know I should be able to achieve better suspended battery >>life, since I could go a week or two in APM suspend from Linux. >> >>(Before I get labelled a Linux troll, I'm a recent convert to FreeBSD >>on my laptop and like it a lot so far... slimmer memory footprint and >>much better documented. ACPI suspend never worked for me under Linux, >>so APM there is all I have to compare with. Battery drain under >>suspend means I have to carry around a power cord again, and that's no >>fun. I'm happy to test stuff as time permits.) > > > Look in the archives for acpi_pwr5.diff. The posting is by njl@ (Nate > Lawson). It will improve power management capability for PCI > devices. (It puts them in standby mode on a suspend to RAM.) Attached, for convenience. BTW, does anyone have problems introduced when running with this patch or do you think it's safe for MFC? -- Nate --------------010609090008080106080905 Content-Type: text/plain; name="acpi_pwr5.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_pwr5.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.186.2.6 diff -u -r1.186.2.6 acpi.c --- sys/dev/acpica/acpi.c 7 Nov 2004 20:24:05 -0000 1.186.2.6 +++ sys/dev/acpica/acpi.c 30 Nov 2004 20:32:31 -0000 @@ -59,6 +59,10 @@ #include #include +#include "pci_if.h" +#include +#include + MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); /* Hooks for the ACPI CA debugging infrastructure */ @@ -87,10 +91,14 @@ static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static int acpi_suspend(device_t dev); +static int acpi_resume(device_t dev); static int acpi_shutdown(device_t dev); static device_t acpi_add_child(device_t bus, int order, const char *name, int unit); static int acpi_print_child(device_t bus, device_t child); +static void acpi_probe_nomatch(device_t bus, device_t child); +static void acpi_driver_added(device_t dev, driver_t *driver); static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_write_ivar(device_t dev, device_t child, int index, @@ -110,10 +118,14 @@ static ACPI_STATUS acpi_device_eval_obj(device_t bus, device_t dev, ACPI_STRING pathname, ACPI_OBJECT_LIST *parameters, ACPI_BUFFER *ret); +static int acpi_device_pwr_for_sleep(device_t bus, device_t dev, + int *dstate); static ACPI_STATUS acpi_device_scan_cb(ACPI_HANDLE h, UINT32 level, void *context, void **retval); static ACPI_STATUS acpi_device_scan_children(device_t bus, device_t dev, int max_depth, acpi_scan_cb_t user_fn, void *arg); +static int acpi_set_powerstate_method(device_t bus, device_t child, + int state); static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); @@ -145,12 +157,14 @@ DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_shutdown, acpi_shutdown), DEVMETHOD(device_detach, bus_generic_detach), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, acpi_suspend), + DEVMETHOD(device_resume, acpi_resume), /* Bus interface */ DEVMETHOD(bus_add_child, acpi_add_child), DEVMETHOD(bus_print_child, acpi_print_child), + DEVMETHOD(bus_probe_nomatch, acpi_probe_nomatch), + DEVMETHOD(bus_driver_added, acpi_driver_added), DEVMETHOD(bus_read_ivar, acpi_read_ivar), DEVMETHOD(bus_write_ivar, acpi_write_ivar), DEVMETHOD(bus_get_resource_list, acpi_get_rlist), @@ -160,7 +174,6 @@ DEVMETHOD(bus_release_resource, acpi_release_resource), DEVMETHOD(bus_child_pnpinfo_str, acpi_child_pnpinfo_str_method), DEVMETHOD(bus_child_location_str, acpi_child_location_str_method), - DEVMETHOD(bus_driver_added, bus_generic_driver_added), DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), @@ -169,8 +182,12 @@ /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), DEVMETHOD(acpi_evaluate_object, acpi_device_eval_obj), + DEVMETHOD(acpi_pwr_for_sleep, acpi_device_pwr_for_sleep), DEVMETHOD(acpi_scan_children, acpi_device_scan_children), + /* PCI emulation */ + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), + /* ISA emulation */ DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), @@ -212,6 +229,12 @@ static int acpi_serialize_methods; TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); +/* Power devices off and on in suspend and resume. XXX Remove once tested. */ +static int acpi_do_powerstate = 1; +TUNABLE_INT("debug.acpi.do_powerstate", &acpi_do_powerstate); +SYSCTL_INT(_debug_acpi, OID_AUTO, do_powerstate, CTLFLAG_RW, + &acpi_do_powerstate, 1, "Turn off devices when suspending."); + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -570,6 +593,72 @@ } static int +acpi_suspend(device_t dev) +{ + struct acpi_softc *sc; + device_t child, *devlist; + int error, i, numdevs, pstate; + + /* First give child devices a chance to suspend. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Now, set them into the appropriate power state, usually D3. If the + * device has an _SxD method for the next sleep state, use that power + * state instead. + */ + sc = device_get_softc(dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + /* If the device is not attached, we've powered it down elsewhere. */ + child = devlist[i]; + if (!device_is_attached(child)) + continue; + + /* + * Default to D3 for all sleep states. The _SxD method is optional + * so set the powerstate even if it's absent. + */ + pstate = PCI_POWERSTATE_D3; + error = acpi_device_pwr_for_sleep(device_get_parent(child), + child, &pstate); + if ((error == 0 || error == ESRCH) && acpi_do_powerstate) + pci_set_powerstate(child, pstate); + } + free(devlist, M_TEMP); + error = 0; + + return (error); +} + +static int +acpi_resume(device_t dev) +{ + ACPI_HANDLE handle; + int i, numdevs; + device_t child, *devlist; + + /* + * Put all devices in D0 before resuming them. Call _S0D on each one + * since some systems expect this. + */ + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + handle = acpi_get_handle(child); + if (handle) + AcpiEvaluateObject(handle, "_S0D", NULL, NULL); + if (device_is_attached(child) && acpi_do_powerstate) + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + free(devlist, M_TEMP); + + return (bus_generic_resume(dev)); +} + +static int acpi_shutdown(device_t dev) { @@ -624,6 +713,45 @@ return (retval); } +/* + * If this device is an ACPI child but no one claimed it, attempt + * to power it off. We'll power it back up when a driver is added. + * + * XXX Disabled for now since many necessary devices (like fdc and + * ATA) don't claim the devices we created for them but still expect + * them to be powered up. + */ +static void +acpi_probe_nomatch(device_t bus, device_t child) +{ + + /* pci_set_powerstate(child, PCI_POWERSTATE_D3); */ +} + +/* + * If a new driver has a chance to probe a child, first power it up. + * + * XXX Disabled for now (see acpi_probe_nomatch for details). + */ +static void +acpi_driver_added(device_t dev, driver_t *driver) +{ + device_t child, *devlist; + int i, numdevs; + + DEVICE_IDENTIFY(driver, dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + if (device_get_state(child) == DS_NOTPRESENT) { + /* pci_set_powerstate(child, PCI_POWERSTATE_D0); */ + if (device_probe_and_attach(child) != 0) + ; /* pci_set_powerstate(child, PCI_POWERSTATE_D3); */ + } + } + free(devlist, M_TEMP); +} + /* Location hint for devctl(8) */ static int acpi_child_location_str_method(device_t cbdev, device_t child, char *buf, @@ -1064,6 +1192,57 @@ return (AcpiEvaluateObject(h, pathname, parameters, ret)); } +static int +acpi_device_pwr_for_sleep(device_t bus, device_t dev, int *dstate) +{ + struct acpi_softc *sc; + ACPI_HANDLE handle; + ACPI_STATUS status; + char sxd[8]; + int error; + + sc = device_get_softc(bus); + handle = acpi_get_handle(dev); + + /* + * XXX If we find these devices, don't try to power them down. + * The serial and IRDA ports on my T23 hang the system when + * set to D3 and it appears that such legacy devices may + * need special handling in their drivers. + */ + if (handle == NULL || + acpi_MatchHid(handle, "PNP0500") || + acpi_MatchHid(handle, "PNP0501") || + acpi_MatchHid(handle, "PNP0502") || + acpi_MatchHid(handle, "PNP0510") || + acpi_MatchHid(handle, "PNP0511")) + return (ENXIO); + + /* + * Override next state with the value from _SxD, if present. If no + * dstate argument was provided, don't fetch the return value. + */ + snprintf(sxd, sizeof(sxd), "_S%dD", sc->acpi_sstate); + if (dstate) + status = acpi_GetInteger(handle, sxd, dstate); + else + status = AcpiEvaluateObject(handle, sxd, NULL, NULL); + + switch (status) { + case AE_OK: + error = 0; + break; + case AE_NOT_FOUND: + error = ESRCH; + break; + default: + error = ENXIO; + break; + } + + return (error); +} + /* Callback arg for our implementation of walking the namespace. */ struct acpi_device_scan_ctx { acpi_scan_cb_t user_fn; @@ -1138,6 +1317,34 @@ acpi_device_scan_cb, &ctx, NULL)); } +/* + * Even though ACPI devices are not PCI, we use the PCI approach for setting + * device power states since it's close enough to ACPI. + */ +static int +acpi_set_powerstate_method(device_t bus, device_t child, int state) +{ + ACPI_HANDLE h; + ACPI_STATUS status; + int error; + + error = 0; + h = acpi_get_handle(child); + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) + return (EINVAL); + if (h == NULL) + return (0); + + /* Ignore errors if the power methods aren't present. */ + status = acpi_pwr_switch_consumer(h, state); + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND + && status != AE_BAD_PARAMETER) + device_printf(bus, "failed to set ACPI power state D%d on %s: %s\n", + state, acpi_name(h), AcpiFormatException(status)); + + return (error); +} + static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { Index: sys/dev/acpica/acpi_if.m =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_if.m,v retrieving revision 1.2 diff -u -r1.2 acpi_if.m --- sys/dev/acpica/acpi_if.m 15 Jul 2004 16:29:08 -0000 1.2 +++ sys/dev/acpica/acpi_if.m 30 Nov 2004 20:32:31 -0000 @@ -109,6 +109,26 @@ }; # +# Get the highest power state (D0-D3) that is usable for a device when +# suspending/resuming. If a bus calls this when suspending a device, it +# must also call it when resuming. +# +# device_t bus: parent bus for the device +# +# device_t dev: check this device's appropriate power state +# +# int *dstate: if successful, contains the highest valid sleep state +# +# Returns: 0 on success, ESRCH if device has no special state, or +# some other error value. +# +METHOD int pwr_for_sleep { + device_t bus; + device_t dev; + int *dstate; +}; + +# # Rescan a subtree and optionally reattach devices to handles. Users # specify a callback that is called for each ACPI_HANDLE of type Device # that is a child of "dev". Index: sys/dev/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.264 diff -u -r1.264 pci.c --- sys/dev/pci/pci.c 2 Jul 2004 13:42:36 -0000 1.264 +++ sys/dev/pci/pci.c 30 Nov 2004 20:33:15 -0000 @@ -60,6 +60,10 @@ #include "pcib_if.h" #include "pci_if.h" +#include +#include +#include "acpi_if.h" + static uint32_t pci_mapbase(unsigned mapreg); static int pci_maptype(unsigned mapreg); static int pci_mapsize(unsigned testval); @@ -169,15 +173,15 @@ SYSCTL_NODE(_hw, OID_AUTO, pci, CTLFLAG_RD, 0, "PCI bus tuning parameters"); static int pci_enable_io_modes = 1; -TUNABLE_INT("hw.pci.enable_io_modes", (int *)&pci_enable_io_modes); +TUNABLE_INT("hw.pci.enable_io_modes", &pci_enable_io_modes); SYSCTL_INT(_hw_pci, OID_AUTO, enable_io_modes, CTLFLAG_RW, &pci_enable_io_modes, 1, "Enable I/O and memory bits in the config register. Some BIOSes do not\n\ enable these bits correctly. We'd like to do this all the time, but there\n\ are some peripherals that this causes problems with."); -static int pci_do_powerstate = 0; -TUNABLE_INT("hw.pci.do_powerstate", (int *)&pci_do_powerstate); +static int pci_do_powerstate = 1; +TUNABLE_INT("hw.pci.do_powerstate", &pci_do_powerstate); SYSCTL_INT(_hw_pci, OID_AUTO, do_powerstate, CTLFLAG_RW, &pci_do_powerstate, 0, "Power down devices into D3 state when no driver attaches to them.\n\ @@ -1015,43 +1019,78 @@ int pci_suspend(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int dstate, error, i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_save(child, dinfo, 0); } + + /* Suspend devices before potentially powering them down. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Always set the device to D3. If ACPI suggests a different + * power state, use it instead. If ACPI is not present, the + * firmware is responsible for managing device power. Skip + * children who aren't attached since they are powered down + * separately. Only manage type 0 devices for now. + */ + for (i = 0; acpi_dev && i < numdevs; i++) { + child = devlist[i]; + dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (device_is_attached(child) && dinfo->cfg.hdrtype == 0) { + dstate = PCI_POWERSTATE_D3; + ACPI_PWR_FOR_SLEEP(acpi_dev, child, &dstate); + pci_set_powerstate(child, dstate); + } + } free(devlist, M_TEMP); - return (bus_generic_suspend(dev)); + return (0); } int pci_resume(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Restore the pci configuration space for each child. + * Set each child to D0 and restore its PCI configuration space. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { + /* + * Notify ACPI we're going to D0 but ignore the result. If + * ACPI is not present, the firmware is responsible for + * managing device power. Only manage type 0 devices for now. + */ child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (acpi_dev && device_is_attached(child) && + dinfo->cfg.hdrtype == 0) { + ACPI_PWR_FOR_SLEEP(acpi_dev, child, NULL); + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + + /* Now the device is powered up, restore its config space. */ pci_cfg_restore(child, dinfo); } free(devlist, M_TEMP); --------------010609090008080106080905-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 20:36:11 2005 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 4963216A4CE for ; Thu, 27 Jan 2005 20:36:11 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id DED4843D39 for ; Thu, 27 Jan 2005 20:36:10 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j0RKa8vE011582; Thu, 27 Jan 2005 15:36:09 -0500 Message-ID: <41F950B8.8000602@root.org> Date: Thu, 27 Jan 2005 12:36:08 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Ducrot References: <200501242325.21013.imush@mail.ru> <20050126113305.GA12500@poupinou.org> In-Reply-To: <20050126113305.GA12500@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: Isaac Mushinsky Subject: Re: newbie question - how to read temerature 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, 27 Jan 2005 20:36:11 -0000 Bruno Ducrot wrote: > On Mon, Jan 24, 2005 at 11:25:20PM -0500, Isaac Mushinsky wrote: > >>I have Dell Precision 530 2x1.7 gHz Xeon. Trying to replace the Dell's noisy >>fans I wanted to make sure the CPU temperatures are normal. But I can find no >>way to read the temperatures at all. ASL dumped with acpidump does not >>compile. >> >>So as not to run too much text in the mail, here are the outputs: >> >>(compiled with ACPI_DEBUG) >> >>dmesg: http://omsk.mushinsky.net/acpi/dmesg >>acpidump -t -d: http://omsk.mushinsky.net/acpi/asl >>iasl errors: http://omsk.mushinsky.net/acpi/iasl >> >>finally, >>$ sysctl -a hw.acpi >>hw.acpi.supported_sleep_state: S1 S3 S4 S5 >>hw.acpi.power_button_state: S5 >>hw.acpi.sleep_button_state: S1 >>hw.acpi.lid_switch_state: NONE >>hw.acpi.standby_state: S1 >>hw.acpi.suspend_state: S3 >>hw.acpi.sleep_delay: 1 >>hw.acpi.s4bios: 0 >>hw.acpi.verbose: 0 >>hw.acpi.reset_video: 1 >>hw.acpi.cpu.cx_supported: C1/0 >>hw.acpi.cpu.cx_lowest: C1 >>hw.acpi.cpu.cx_usage: 100.00% >> > > > There is no thermal zone in this ASL. So no hope to get it via ACPI. > But, IIRC, there is a support under Linux, but for i8k models, which use > a propritary, non documented BIOS interface from Dell. I think this is > the case with the Precision. Yes, Dell chose not to export thermal info through ACPI for this laptop. Mark Santrcoos (marks@) wrote a Dell SMM driver that probably duplicates the Linux driver Bruno mentions. Perhaps he can post it for you to try. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 20:43:01 2005 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 40A6716A4CE; Thu, 27 Jan 2005 20:43:01 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C839E43D45; Thu, 27 Jan 2005 20:43:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j0RKhB2Y027131; Thu, 27 Jan 2005 15:43:11 -0500 Message-ID: <41F95252.8070600@root.org> Date: Thu, 27 Jan 2005 12:42:58 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael W. Oliver" References: <1b1b33f10501270752473093ea@mail.gmail.com> <200501271359.30721.jkim@niksun.com> <20050127195633.GA32179@gargantuan.com> In-Reply-To: <20050127195633.GA32179@gargantuan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 CPU and ACPI (was Re: Configuration of Compaq R3000) 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, 27 Jan 2005 20:43:01 -0000 Michael W. Oliver wrote: > On 2005-01-27T13:59:29-0500, Jung-uk Kim wrote: >>Did you use 'acpi_ppc' driver? >>http://www.spa.is.uec.ac.jp/~nfukuda/software/ > >>You need this driver to run your laptop at full speed. CPU speed will >>be automatically adjusted by CPU load. However, it may take few >>seconds to get to the speed. You can set the speed manually by: > > Whoo-hoo!!! This works on my machine (Sager 4750V) so far, and gives > wonderful information: > > hw.acpi.cpu.px_control: -1 > hw.acpi.cpu.px_highest: 0 > hw.acpi.cpu.px_lowest: 2 > hw.acpi.cpu.px_current: 1 > hw.acpi.cpu.px_supported: 2200 1800 800 > hw.acpi.cpu.px_usage: 4.62% 25.70% 69.66% > > (running `make clean' in /usr/ports just to push it a little) > > This is great! Thanks so much for posting this! This completely makes > sense now that I would see the CPU speed reported as ~801MHz when the > machine would boot up. I can't thank you enough. > > What are the chances that this could be imported into current? I am > running... I've been working on a cpufreq driver for about 6 months now. Work unfortunately has made progress too slow. I have taken a vacation day to work on FreeBSD and plan to import a stripped down version (no throttling support) very soon. The driver is a general cpufreq framework and two hardware drivers, one for SpeedStep ICH and one for ACPI Px states (like acpi_ppc but a separate implementation). Other drivers, like SpeedStep Centrino and Powernow, can easily be hooked into the framework by their maintainers and imported into the general tree. I've wanted to keep them as ports for now so that I could prototype the framework before importing it. That way we wouldn't have to restructure millions of cpu hardware drivers after the fact. The short answer is that a similar capability should be imported soon. >>Unfortunately if you run this laptop under heavy CPU load, CPU will >>heat up pretty fast and 'acpi_ec' will adjust delay to prevent >>excessive heat. You can ignore this behavior by hacking acpi_ec.c, I >>believe but it's really bad idea. > > > I do see some ACPI errors on my laptop when I boot it up, such as: > > (dmesg -a | grep -i acpi): > acpi_cmbat0: battery initialization start > acpi_acad0: acline initialization start > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > acpi_ec0: info: new max delay is 70 us > acpi_ec0: info: new max delay is 100 us > acpi_cmbat0: battery initialization failed, giving up <-- ugh! > acpi_ec0: info: new max delay is 130 us > acpi_ec0: info: new max delay is 170 us > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_ec0: info: new max delay is 900 us > acpi_ec0: info: new max delay is 11000 us > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_tz0: _CRT value is absurd, ignored (154.8C) This all indicates your embedded controller is not responding. It's important to figure out why. Can you post a link to your full dmesg too? > acpidump stuff is here: > http://michael.gargantuan.com/sager_4750v/acpidump.asl > http://michael.gargantuan.com/sager_4750v/dsdt.out > http://michael.gargantuan.com/sager_4750v/sysctl_hw.acpi Thanks, I'll eventually take a look at this but hopefully you understand that I've set aside bugfixing for a short while to complete longer term projects. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 20:56:23 2005 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 3F68816A4CE for ; Thu, 27 Jan 2005 20:56:23 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50A243D1F for ; Thu, 27 Jan 2005 20:56:22 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id D384D25F72; Thu, 27 Jan 2005 21:56:21 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D1AA125F71; Thu, 27 Jan 2005 21:56:19 +0100 (CET) Received: (from marks@localhost) by birch.ripe.net (8.12.10/8.11.6) id j0RKuJ5p030318; Thu, 27 Jan 2005 21:56:19 +0100 Date: Thu, 27 Jan 2005 21:56:19 +0100 From: Mark Santcroos To: Nate Lawson Message-ID: <20050127205619.GA32002@ripe.net> References: <200501242325.21013.imush@mail.ru> <20050126113305.GA12500@poupinou.org> <41F950B8.8000602@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F950B8.8000602@root.org> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.067406 / -5.9 X-RIPE-Signature: a9507a814b491a33fa6aac0a7c9fa91f cc: freebsd-acpi@freebsd.org cc: Isaac Mushinsky Subject: Re: newbie question - how to read temerature 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, 27 Jan 2005 20:56:23 -0000 On Thu, Jan 27, 2005 at 12:36:08PM -0800, Nate Lawson wrote: > Yes, Dell chose not to export thermal info through ACPI for this laptop. > Mark Santrcoos (marks@) wrote a Dell SMM driver that probably > duplicates the Linux driver Bruno mentions. Perhaps he can post it for > you to try. Yes, probably on the laptop hdd I recently crashed though :( Still recovering from that and don't know if I will see any of that stuff back at all. Let me get back on this later. Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 21:06:50 2005 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 0F36C16A4CE; Thu, 27 Jan 2005 21:06:50 +0000 (GMT) Received: from phoenix.gargantuan.com (phoenix.gargantuan.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BA643D46; Thu, 27 Jan 2005 21:06:49 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 781E5638; Thu, 27 Jan 2005 16:06:48 -0500 (EST) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id AD231287; Thu, 27 Jan 2005 16:06:41 -0500 (EST) Date: Thu, 27 Jan 2005 16:06:41 -0500 From: "Michael W. Oliver" To: Nate Lawson Message-ID: <20050127210641.GB32179@gargantuan.com> Mail-Followup-To: Nate Lawson , Jung-uk Kim , acpi@freebsd.org, freebsd-amd64@freebsd.org References: <1b1b33f10501270752473093ea@mail.gmail.com> <200501271359.30721.jkim@niksun.com> <20050127195633.GA32179@gargantuan.com> <41F95252.8070600@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <41F95252.8070600@root.org> X-WWW-URL: http://michael.gargantuan.com X-GPG-PGP-Public-Key: $X-WWW-URL/gnupg/pubkey.asc X-GPG-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Mailing-Address0: 8008 Apache Lane X-Mailing-Address1: Lakeland, FL X-Mailing-Address2: 33810-2172 X-Mailing-Address3: United States of America X-Guide-Questions: http://www.catb.org/~esr/faqs/smart-questions.html X-Guide-Netiquette: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: sgs_public_dcc_server: phoenix.gargantuan.com 1199; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, score=-105.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.1 X-Spam-Pyzor: Reported 0 times. cc: acpi@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 CPU and ACPI (was Re: Configuration of Compaq R3000) 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, 27 Jan 2005 21:06:50 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005-01-27T12:42:58-0800, Nate Lawson wrote: > Michael W. Oliver wrote: > I've been working on a cpufreq driver for about 6 months now. Work=20 > unfortunately has made progress too slow. I have taken a vacation day=20 > to work on FreeBSD and plan to import a stripped down version (no=20 > throttling support) very soon. As always, your support is much appreciated Nate. You do fine work. > The driver is a general cpufreq framework and two hardware drivers, one= =20 > for SpeedStep ICH and one for ACPI Px states (like acpi_ppc but a=20 > separate implementation). Other drivers, like SpeedStep Centrino and=20 > Powernow, can easily be hooked into the framework by their maintainers=20 > and imported into the general tree. I've wanted to keep them as ports=20 > for now so that I could prototype the framework before importing it.=20 > That way we wouldn't have to restructure millions of cpu hardware=20 > drivers after the fact. > The short answer is that a similar capability should be imported soon. Excellent! > >I do see some ACPI errors on my laptop when I boot it up, such as: > >(dmesg -a | grep -i acpi): > >acpi_cmbat0: battery initialization start > >acpi_acad0: acline initialization start > >acpi_tz0: _CRT value is absurd, ignored (154.8C) > >acpi_acad0: On Line > >acpi_acad0: acline initialization done, tried 1 times > >acpi_ec0: info: new max delay is 70 us > >acpi_ec0: info: new max delay is 100 us > >acpi_cmbat0: battery initialization failed, giving up <-- ugh! > >acpi_ec0: info: new max delay is 130 us > >acpi_ec0: info: new max delay is 170 us > >acpi_tz0: _CRT value is absurd, ignored (154.8C) > >acpi_tz0: _CRT value is absurd, ignored (154.8C) > >acpi_ec0: info: new max delay is 900 us > >acpi_ec0: info: new max delay is 11000 us > >acpi_tz0: _CRT value is absurd, ignored (154.8C) > >acpi_tz0: _CRT value is absurd, ignored (154.8C) > This all indicates your embedded controller is not responding. It's=20 > important to figure out why. Can you post a link to your full dmesg too? You betcha. http://michael.gargantuan.com/sager_4750v/dmesg.txt http://michael.gargantuan.com/sager_4750v/usbdevs.txt http://michael.gargantuan.com/sager_4750v/pciconf.txt Almost everything on this laptop works with FreeBSD. In fact, I have more hardware support with 64bit FreeBSD than I do with 64bit Windows! > >acpidump stuff is here: > >http://michael.gargantuan.com/sager_4750v/acpidump.asl > >http://michael.gargantuan.com/sager_4750v/dsdt.out > >http://michael.gargantuan.com/sager_4750v/sysctl_hw.acpi > Thanks, I'll eventually take a look at this but hopefully you understand= =20 > that I've set aside bugfixing for a short while to complete longer term= =20 > projects. Totally understandable Nate, take your time. I am not going anywhere ;) --=20 Mike Oliver [see complete headers for contact information] --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB+VfhsWv7q8X6o8kRAm2CAJ0UkDpUmGgsvmrVniYtczhLMzfHwgCeKumg EdxBnYbttU6hi3kGkXc+jKE= =UG4n -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 21:20:06 2005 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 640B616A4CE for ; Thu, 27 Jan 2005 21:20:06 +0000 (GMT) Received: from rogue.ncsl.nist.gov (rogue.ncsl.nist.gov [129.6.101.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id D92FF43D49 for ; Thu, 27 Jan 2005 21:20:05 +0000 (GMT) (envelope-from ian.soboroff@nist.gov) Received: from rogue.ncsl.nist.gov.nist.gov (localhost.localdomain [127.0.0.1])j0RLJxuq031068; Thu, 27 Jan 2005 16:19:59 -0500 From: Ian Soboroff To: Nate Lawson References: <20050125193240.8F9145D08@ptavv.es.net> <41F94F90.2020006@root.org> Date: Thu, 27 Jan 2005 16:19:59 -0500 In-Reply-To: <41F94F90.2020006@root.org> (Nate Lawson's message of "Thu, 27 Jan 2005 12:31:12 -0800") Message-ID: <9cfzmyutvr4.fsf@rogue.ncsl.nist.gov> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 27 Jan 2005 21:20:06 -0000 Nate Lawson writes: > Attached, for convenience. BTW, does anyone have problems introduced > when running with this patch or do you think it's safe for MFC? Thanks... I had to Google that up (found in freebsd-mobile). It seems safe to me so far. I haven't tested suspending with devices such as PC Cards, USB, or Firewire devices plugged in. As far as effectiveness goes, Anish says that it hasn't helped suspend time. I can test it this weekend (same laptop model, but I've felt that it did better than not having it). That just means that the power draw during suspend on our laptops isn't covered by this patch. Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 21:20:17 2005 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 4539716A4CE for ; Thu, 27 Jan 2005 21:20:17 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D1643D3F for ; Thu, 27 Jan 2005 21:20:15 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 27 Jan 2005 13:20:14 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4414C5D04; Thu, 27 Jan 2005 13:20:14 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Thu, 27 Jan 2005 12:31:12 PST." <41F94F90.2020006@root.org> Date: Thu, 27 Jan 2005 13:20:14 -0800 From: "Kevin Oberman" Message-Id: <20050127212014.4414C5D04@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: Resume problem with mouse, 5.3 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, 27 Jan 2005 21:20:17 -0000 > Date: Thu, 27 Jan 2005 12:31:12 -0800 > From: Nate Lawson > > This is a multi-part message in MIME format. > --------------010609090008080106080905 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Kevin Oberman wrote: > >>From: Ian Soboroff > >>I am running with the acpi_video patch, and I can have the laptop in > >>S3 suspend for about a weekend. (This is with the high-cap main > >>battery and an expansion bay battery, btw.) APM suspend indeed breaks > >>something as I could never resume from it. > >> > >>There was a recent patch mentioned which I am planning to try as > >>well. I know I should be able to achieve better suspended battery > >>life, since I could go a week or two in APM suspend from Linux. > >> > >>(Before I get labelled a Linux troll, I'm a recent convert to FreeBSD > >>on my laptop and like it a lot so far... slimmer memory footprint and > >>much better documented. ACPI suspend never worked for me under Linux, > >>so APM there is all I have to compare with. Battery drain under > >>suspend means I have to carry around a power cord again, and that's no > >>fun. I'm happy to test stuff as time permits.) > > > > > > Look in the archives for acpi_pwr5.diff. The posting is by njl@ (Nate > > Lawson). It will improve power management capability for PCI > > devices. (It puts them in standby mode on a suspend to RAM.) > > Attached, for convenience. BTW, does anyone have problems introduced > when running with this patch or do you think it's safe for MFC? I have had no problems at all, and I have heard from a few other, none of whom have had a problem. I have not tested as to whether it really improves power consumption, but it does not seem to cause any problems. At least one person has sent a note that it really did not make a difference for him, though. But I have no reason to think that it should not be MFC'd. -- 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 From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 27 23:21:13 2005 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 913F516A4CE for ; Thu, 27 Jan 2005 23:21:13 +0000 (GMT) Received: from f7.mail.ru (f7.mail.ru [194.67.57.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0388543D46 for ; Thu, 27 Jan 2005 23:21:13 +0000 (GMT) (envelope-from imush@mail.ru) Received: from mail by f7.mail.ru with local id 1CuIwp-00041S-00 for freebsd-acpi@freebsd.org; Fri, 28 Jan 2005 02:21:11 +0300 Received: from [166.84.149.254] by win.mail.ru with HTTP; Thu, 27 Jan 2005 18:21:11 -0500 From: Isaac Mushinsky To: freebsd-acpi@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [166.84.149.254] Date: Thu, 27 Jan 2005 18:21:11 -0500 In-Reply-To: <41F950B8.8000602@root.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Subject: Re[2]: newbie question - how to read temerature X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Isaac Mushinsky List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 23:21:13 -0000 Thanks for all the advice (no solution in sight though). By the way, this is not a laptop; it's a desktop workstation. -----Original Message----- From: Nate Lawson To: Bruno Ducrot Date: Thu, 27 Jan 2005 12:36:08 -0800 Subject: Re: newbie question - how to read temerature > > Bruno Ducrot wrote: > > On Mon, Jan 24, 2005 at 11:25:20PM -0500, Isaac Mushinsky wrote: > > > >>I have Dell Precision 530 2x1.7 gHz Xeon. Trying to replace the Dell's noisy > >>fans I wanted to make sure the CPU temperatures are normal. But I can find no > >>way to read the temperatures at all. ASL dumped with acpidump does not > >>compile. > >> > >>So as not to run too much text in the mail, here are the outputs: > >> > >>(compiled with ACPI_DEBUG) > >> > >>dmesg: http://omsk.mushinsky.net/acpi/dmesg > >>acpidump -t -d: http://omsk.mushinsky.net/acpi/asl > >>iasl errors: http://omsk.mushinsky.net/acpi/iasl > >> > >>finally, > >>$ sysctl -a hw.acpi > >>hw.acpi.supported_sleep_state: S1 S3 S4 S5 > >>hw.acpi.power_button_state: S5 > >>hw.acpi.sleep_button_state: S1 > >>hw.acpi.lid_switch_state: NONE > >>hw.acpi.standby_state: S1 > >>hw.acpi.suspend_state: S3 > >>hw.acpi.sleep_delay: 1 > >>hw.acpi.s4bios: 0 > >>hw.acpi.verbose: 0 > >>hw.acpi.reset_video: 1 > >>hw.acpi.cpu.cx_supported: C1/0 > >>hw.acpi.cpu.cx_lowest: C1 > >>hw.acpi.cpu.cx_usage: 100.00% > >> > > > > > > There is no thermal zone in this ASL. So no hope to get it via ACPI. > > But, IIRC, there is a support under Linux, but for i8k models, which use > > a propritary, non documented BIOS interface from Dell. I think this is > > the case with the Precision. > > Yes, Dell chose not to export thermal info through ACPI for this laptop. > Mark Santrcoos (marks@) wrote a Dell SMM driver that probably > duplicates the Linux driver Bruno mentions. Perhaps he can post it for > you to try. > > -- > Nate > From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 01:39:18 2005 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 8558916A4CE for ; Fri, 28 Jan 2005 01:39:18 +0000 (GMT) Received: from dexter.starfire.mn.org (starfire.skypoint.net [66.93.17.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id A212A43D4C for ; Fri, 28 Jan 2005 01:39:17 +0000 (GMT) (envelope-from john@dexter.starfire.mn.org) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id j0S1dEv25653 for freebsd-acpi@freebsd.org; Thu, 27 Jan 2005 19:39:14 -0600 (CST) (envelope-from john) Date: Thu, 27 Jan 2005 19:39:14 -0600 From: John To: freebsd-acpi@freebsd.org Message-ID: <20050127193914.A25626@starfire.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: Trying to debug acpi.ko - missing db_readline link 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: Fri, 28 Jan 2005 01:39:18 -0000 I'm trying to follow the procedures for debugging ACPI, and I've followed the instructions to create a module with debugging enabled, but I can't load it - I get the following error message: link_elf: symbol db_readline undefined KLD file acpi.ko - could not finalize loading Anyone able to kick-start me to the next level? -- John Lind john@starfire.MN.ORG From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 02:19:25 2005 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 F220B16A4CE for ; Fri, 28 Jan 2005 02:19:24 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 783A843D45 for ; Fri, 28 Jan 2005 02:19:24 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j0S2F0bs018702; Thu, 27 Jan 2005 21:15:03 -0500 Message-ID: <41F9A127.2050708@root.org> Date: Thu, 27 Jan 2005 18:19:19 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John References: <20050127193914.A25626@starfire.mn.org> In-Reply-To: <20050127193914.A25626@starfire.mn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Trying to debug acpi.ko - missing db_readline link 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: Fri, 28 Jan 2005 02:19:25 -0000 John wrote: > I'm trying to follow the procedures for debugging ACPI, and I've > followed the instructions to create a module with debugging enabled, > but I can't load it - I get the following error message: > > link_elf: symbol db_readline undefined > KLD file acpi.ko - could not finalize loading > > Anyone able to kick-start me to the next level? You need to build the kernel with options KDB (and also options DDB or GDB if you want to use either of them). -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 02:27:59 2005 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 41C8316A4CE for ; Fri, 28 Jan 2005 02:27:59 +0000 (GMT) Received: from imss.phys.ntu.edu.tw (imss.phys.ntu.edu.tw [140.112.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 723A143D2D for ; Fri, 28 Jan 2005 02:27:56 +0000 (GMT) (envelope-from takashi.inoue@uni-tuebingen.de) Received: from imss.phys.ntu.edu.tw (localhost.localdomain [127.0.0.1]) by localhost.phys.ntu.edu.tw (Postfix) with ESMTP id 84A601F414 for ; Fri, 28 Jan 2005 10:26:04 +0800 (CST) Received: from [127.0.0.1] (unknown [140.112.102.113])by imss.phys.ntu.edu.t w (Postfix) with ESMTP id 70D7F1F411for ; Fri, 28 Jan 2005 10:26:04 +0800 (CST) Message-ID: <41F9A2BA.7010409@uni-tuebingen.de> Date: Fri, 28 Jan 2005 10:26:02 +0800 From: Takashi Inoue User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/ 20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-imss-version: 2.12 X-imss-result: Passed X-imss-scores: Clean:57.75657 C:20 M:2 S:5 R:5 X-imss-settings: Baseline:3 C:2 M:2 S:3 R:3 (0.0500 0.1000) Subject: ATA failure at resume on ThinkPad X40 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: Fri, 28 Jan 2005 02:27:59 -0000 Hi friends, I'll move to freebsd-mobile ML. It seems nothing to do with ACPI. Thanks. Takashi >Hi friends, > >I am using 5.3R on ThinkPad X40. >When it resume from ACPI S3 sleep, an ATA failure occur as: >---------------------------------------- >ioapic_suspend: not implemented! >ad0: FAILURE - ATA_IDENTIFY timed out >ad0: WARNING - removed from configuration >---------------------------------------- >Then, I cannot do even shutdown. >Therefore I don't use suspend/resume on my ThinkPad now. >It is pity. Does anyone know a reason and solution of it? >Or, does anyone here use ACPI S3 successfully on X40? >Disabling apic helps. But I prefer to use apic because of better response. >Any infomation and comment is welcome. Thanks. > >Cheers, >Takashi > From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 12:49:39 2005 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 52B6216A4CE for ; Fri, 28 Jan 2005 12:49:39 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1047B43D49 for ; Fri, 28 Jan 2005 12:49:39 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1CuVZ8-0005b4-00; Fri, 28 Jan 2005 13:49:34 +0100 Date: Fri, 28 Jan 2005 13:49:34 +0100 To: Isaac Mushinsky Message-ID: <20050128124934.GB12500@poupinou.org> References: <41F950B8.8000602@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-acpi@freebsd.org Subject: Re: newbie question - how to read temerature 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: Fri, 28 Jan 2005 12:49:39 -0000 On Thu, Jan 27, 2005 at 06:21:11PM -0500, Isaac Mushinsky wrote: > Thanks for all the advice (no solution in sight though). By the way, this is not a laptop; it's a desktop workstation. > Oops... Well, I had an old Dell desktop. Got thermal stuff with 'classic' sensors (a LM75 IIRC, via piix4), but this was under Linux. Never tested with FreeBSD (it was too late, somehow). -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 16:17:36 2005 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 194F316A4CE for ; Fri, 28 Jan 2005 16:17:36 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD3BB43D58 for ; Fri, 28 Jan 2005 16:17:35 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j0SGHXl6031349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jan 2005 08:17:34 -0800 Message-ID: <41FA652F.1020501@root.org> Date: Fri, 28 Jan 2005 08:15:43 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Ducrot References: <41F950B8.8000602@root.org> <20050128124934.GB12500@poupinou.org> In-Reply-To: <20050128124934.GB12500@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: Isaac Mushinsky Subject: Re: newbie question - how to read temerature 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: Fri, 28 Jan 2005 16:17:36 -0000 Bruno Ducrot wrote: > On Thu, Jan 27, 2005 at 06:21:11PM -0500, Isaac Mushinsky wrote: > >>Thanks for all the advice (no solution in sight though). By the way, this is not a laptop; it's a desktop workstation. >> > > Oops... Well, I had an old Dell desktop. Got thermal stuff > with 'classic' sensors (a LM75 IIRC, via piix4), but this was under > Linux. Never tested with FreeBSD (it was too late, somehow). I think we have something similar via the SMBUS drivers but no personal experience. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 28 17:54:30 2005 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 8FECC16A4CE for ; Fri, 28 Jan 2005 17:54:30 +0000 (GMT) Received: from dexter.starfire.mn.org (starfire.skypoint.net [66.93.17.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 156C543D39 for ; Fri, 28 Jan 2005 17:54:29 +0000 (GMT) (envelope-from john@dexter.starfire.mn.org) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id j0SHsQD30478 for freebsd-acpi@freebsd.org; Fri, 28 Jan 2005 11:54:26 -0600 (CST) (envelope-from john) Date: Fri, 28 Jan 2005 11:54:26 -0600 From: John To: freebsd-acpi@freebsd.org Message-ID: <20050128115426.A30470@starfire.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: ACPI problems with Compaq Armada M700 - stuck on debugging 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: Fri, 28 Jan 2005 17:54:30 -0000 With regard to the ACPI problems I'm having with my Compaq Armada M700: I know this is a far-from-new laptop, and I'm not going to be expecting a whole ton of support, because there's probably only a half-dozen or so people in the world that will actually care when it's all said and done, but it is my laptop, and the only one I'll probably have for quite awhile, and I'd like to get it back to the way it was pre-ACPI. What I'm looking for from someone is a suggestion on how to move forward with the debugging (or work-around, if it is intuitively obvious to someone more familiar with the operations of acpi), because I am wedged pretty tightly right now. Back in the bad old days of apm, I actually had pretty much what I needed. shutdown (or halt) -p worked, I got CPU throttling with power, the battery monitoring worked, and I could use my PCMCIA WiFi card. Suspend and resume didn't work, but I could live with that. I mention this mainly to support the idea that this doesn't seem to be an inherent hardware problem, but hopefully something that can be solved through software (or the disabling thereof). Now, with FreeBSD 5.3-STABLE, when I put in a PCMCIA WiFi card (the same one that worked with FreeBSD 4.10, or anyone else's that I've borrowed), the system locks up. Sometimes I get a panic, but usually not. Without DDB/KDB, the system would freeze at the panic - with DDB/KDB, I at least am able to poke around a little. Unfortuantely, if it doesn't panic, I can't do anything. I've downloaded the asl file, and tried two different ways of modifying it, with results no different from the original DSDT. The two ways I tried were 1) inserting meaningless "Return (0x00)" statements to make the iasl compiler happy, or 2) rewriting the code so that it doesn't expect return values which are just discarded, anyway. With either method, I'm able to get the iasl error output down to the following: Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20041119 [Jan 9 2005] Copyright (C) 2000 - 2004 Intel Corporation Supports ACPI Specification Revision 2.0c M700-fixed-ft.asl 2358: Store (Package (0x00) {}, Local0) Warning 2018 - Effective AML package length is zero ^ M700-fixed-ft.asl 2395: Store (Package (0x00) {}, Local0) Warning 2018 - Effective AML package length is zero ^ ASL Input: M700-fixed-ft.asl - 6441 lines, 196749 bytes, 3691 keywords AML Output: DSDT.aml - 29368 bytes 867 named objects 2824 executable opcodes Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 1453 Optimizations The .asl files are available at http://starfire.skypoint.net/~john/acpi/M700-fixed-ft.asl and http://starfire.skypoint.net/~john/acpi/M700-original-ft.asl (though "fixed" is pretty optomisitic at this point!) There was once a "fixed" DSDT by David Hollis out there on sourceforge, but it got cleaned up and hasn't been seen since - I've corresponded with Mr. Hollis, and he doesn't have it, nor can me make any suggestions in addition to what I've done to the asl. Without ACPI, I can put my card in and remove it and it works fine, but I'm obviously without the ACPI (or apm) functionality. I've followed the debug procedures as far as I can, but when I do a Ctrl+Alt+Esc, nothing happens. Either the system panics and falls into db> by itself, or I'm so locked up that I can't get there. In fact, the system is so locked up that I have to pull the battery out to get it back - nothing else phases it. I have managed to get into db> a couple of times as the result of the panic, and the interrupt counts do not look like a "storm" to me, so I'm really puzzled. When it has paniced, it has been at PRECISELY the same instruction in the cbb0 process, which cannot be a coincidence. I missed the interrupt data the first time I got into db> because of a mismatch between the handbook man pages, Here's what happened on four consecutive attempts - which I tried to make as identical and deterministic as possible: === first try pearl# umount /home pearl# sync;sync;sync pearl# wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Fatal trap 19: non-maskable interrupt trap while in kernel mode instruction pointer = 0x8:0xc049a634 stack pointer = 0x10:0xcea8aba4 frame pointer = 0x10:0xcea8abb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1 def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 38 (cbb0) [thread pid 38 tid 100044 ] Stopped at wi_cmd+0x10c: jmp wi_cmd+0x112 db> show interrupts no such command db> trace (traced pid38, cbb0) db> continue (lock up - nothing works - not even Ctrl+Alt+Esc) (pulled the card - now it says it got the Ctrl+Alt+Esc) reset (lock up - nothing works - had to pull the battery) === second try pearl# umount /home pearl# kenv acpi.debug.disable=all pearl# sync;sync;sync pearl# wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 (total lock up - nothing works - not even pulling the card - had to pull the battery) (undocked to pull the batter - then got the same fatal trap as above) Fatal trap 19: non-maskable interrupt trap while in kernel mode instruction pointer = 0x8:0xc049a634 stack pointer = 0x10:0xcea8aba4 frame pointer = 0x10:0xcea8abb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1 def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 38 (cbb0) [thread pid 38 tid 100044 ] Stopped at wi_cmd+0x10c: jmp wi_cmd+0x112 db> show intrcnt irq0: clk 16983 irq1: atkbd0 275 irq8: rtc 21739 irq9: acpi0 3 irq11: cbb0, cbb1+++ 26 irq13: npx0 1 irq14: ata0 7788 db> show irqs irq0: clk (pid 12) irq1: atkbd0 (pid 13) {NEED} irq3: sio1 (pid 14) irq4: sio0 (pid 15) irq5: (pid 16) irq6: fdc0 (pid 17) {ENTROPY} irq7: ppc0 (pid 18) irq8: rtc (pid 19) irq9: acpi0 (pid 20) {NEED} irq10: (pid 21) irq11: cbb0, cbb1+++ (pid 22) {NEED} irq12: psm0 (pid 23) irq13: (pid 24) irq14: ata0 (pid 25) {ENTROPY} irq15: ata1 (pid 26) {ENTROPY} db> reset (total lockup - had to remove battery) === third try pearl# umount /home pearl# sync;sync;sync pearl# wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 (total lockup - nothing from Ctrl+Alt+Esc, pulling the card, docking or undocking, suspend or power switches, Ctrl+Alt+Del - had to pull battery and start over) === fourth try pearl# umount /home pearl# sync;sync;sync pearl# wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Even though I am not consistently able to get into the debug mode and look at things, from the time that I did and figured out the new commands, they do not appear excessive. === fifth try I added makeoptoin DEBUG=-g option KDB option DDB and then did a "make buildkernel KERNCONF=PEARL ACPI_DEBUG=1" and then a "make installkernel KERNCONF=PEARL" to get the kernel I am running with kdb/ddb in it. Well, apparently adding ACPI_DEBUG=1 to the "master" make doesn't work - the sysctl debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" sysctl debug.acpi.level="ACPI_LV_ERROR" didn't do anything - so I manually rebuilt the acpi module according to the handbook instructions, and it came out bigger, so I tried again - this time I get Jan 28 11:07:56 pearl kernel: ACPI set debug layer 'ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS' Jan 28 11:07:56 pearl kernel: ACPI set debug layer 'ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS' level 'ACPI_LV_ERROR' when I run those commands, but when I put the card in, all I STILL get is a lockup. === sixth try As before, but with kenv acpi.debug.disable=all, which I am pretty sure worked, but didn't really change much. I still the got wi0 message, but this time, I got the panic again, same pid and instruction, though with slightly different hex values due to the larger kernel and modules, and when I did a "show intrcnt" it didn't list acpi at all, which makes me think the disable worked, even though I still got the panic. === The question So - it's almost like the mere PRESENCE of the acpi module is precipitating this panic / lockup, and I'm not sure how to proceed. Since the disable and debug output requests aren't showing anything, I don't have much to go on. There is one other weird thing - when I start without ACPI, it pauses longer when unsuccessfully attempting to identify the CD-ROM. When I start with ACPI, the unsuccessful attempt goes much faster. Probably unimportant in this context, but thought I'd mention it. Once I get past this problem, I'd like to go back and revisit why I can boot from my CD-ROM but not see it from a running system. With FreeBSD 4.9 - I could boot from it and install from it, but then not see it after booting from the hard drive. There's probably some acpi interaction going on here, too, but that's minor compare to locking up my poor laptop. The remainder of this messages is just three dmesg outputs - one with the original DSDT, one with my DSDT, and one with acpi disabled. === dmesg, no acpi Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #2: Tue Jan 18 08:59:26 CST 2005 john@dauntless.starfire.mn.org:/usr/obj/usr/src/sys/PEARL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (646.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 335478784 (319 MB) avail memory = 322830336 (307 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0x50000000-0x53ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: mem 0x41100000-0x41100fff irq 11 at device 4.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x41180000-0x41180fff irq 11 at device 4.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x3420-0x342f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0x3400-0x341f irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Atmel UHB124 hub, class 9/0, rev 1.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered pci0: at device 7.3 (no driver attached) pcm0: port 0x3000-0x30ff irq 11 at device 8.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] fxp0: port 0x3440-0x347f mem 0x41200000-0x4121ffff,0x41280000-0x41280fff irq 11 at device 9.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:59:38:93:d6 pci0: at device 9.1 (no driver attached) fxp1: port 0x3480-0x34bf mem 0x41400000-0x414fffff,0x41380000-0x41380fff irq 11 at device 16.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:d0:b7:28:17:69 cpu0 on motherboard orm0: at iomem 0xd4000-0xd4fff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) sio4: at port 0x100-0x107,0x3e8-0x3ef irq 3 drq 5 on isa0 sio4: type 16550A unknown: can't assign resources (port) Timecounter "TSC" frequency 646827076 Hz quality 800 Timecounters tick every 10.000 msec ad0: 5729MB [12416/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s2a Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...4 2 1 1 0 0 done No buffers busy after final sync Uptime: 1h21m49s Rebooting... === dmesg, no original DSDT Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #2: Tue Jan 18 08:59:26 CST 2005 john@dauntless.starfire.mn.org:/usr/obj/usr/src/sys/PEARL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (646.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 335478784 (319 MB) avail memory = 322822144 (307 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0x50000000-0x53ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: mem 0x41100000-0x41100fff irq 11 at device 4.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x41180000-0x41180fff irq 11 at device 4.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x3420-0x342f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0x3400-0x341f irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Atmel UHB124 hub, class 9/0, rev 1.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered pci0: at device 7.3 (no driver attached) pcm0: port 0x3000-0x30ff irq 11 at device 8.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] fxp0: port 0x3440-0x347f mem 0x41200000-0x4121ffff,0x41280000-0x41280fff irq 11 at device 9.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:59:38:93:d6 pci0: at device 9.1 (no driver attached) fxp1: port 0x3480-0x34bf mem 0x41400000-0x414fffff,0x41380000-0x41380fff irq 11 at device 16.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:d0:b7:28:17:69 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] sio1: port 0x100-0x107,0x3e8-0x3ef irq 3 drq 5 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77a,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xd4000-0xd4fff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 646825891 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 5729MB [12416/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s2a === dmesg, no my DSDT Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #2: Tue Jan 18 08:59:26 CST 2005 john@dauntless.starfire.mn.org:/usr/obj/usr/src/sys/PEARL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (646.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 335478784 (319 MB) avail memory = 322822144 (307 MB) ACPI: overriding DSDT/SSDT with custom table ACPI-0377: *** Info: Table [DSDT] replaced by host OS npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0x50000000-0x53ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: mem 0x41100000-0x41100fff irq 11 at device 4.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x41180000-0x41180fff irq 11 at device 4.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x3420-0x342f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0x3400-0x341f irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Atmel UHB124 hub, class 9/0, rev 1.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered pci0: at device 7.3 (no driver attached) pcm0: port 0x3000-0x30ff irq 11 at device 8.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] fxp0: port 0x3440-0x347f mem 0x41200000-0x4121ffff,0x41280000-0x41280fff irq 11 at device 9.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:59:38:93:d6 pci0: at device 9.1 (no driver attached) fxp1: port 0x3480-0x34bf mem 0x41400000-0x414fffff,0x41380000-0x41380fff irq 11 at device 16.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:d0:b7:28:17:69 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] sio1: port 0x100-0x107,0x3e8-0x3ef irq 3 drq 5 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77a,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xd4000-0xd4fff,0xd0000-0xd17ff,0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 646826788 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 5729MB [12416/15/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s2a Thanks! -- John Lind john@starfire.MN.ORG From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 29 09:26:01 2005 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 C94DE16A4CE for ; Sat, 29 Jan 2005 09:26:01 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3B6943D55 for ; Sat, 29 Jan 2005 09:26:00 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j0T9Pw2q065018; Sat, 29 Jan 2005 11:25:59 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 02880-03; Sat, 29 Jan 2005 11:25:54 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j0SItIjT005080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2005 20:55:18 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id j0SItLrF009963; Fri, 28 Jan 2005 20:55:21 +0200 (EET) (envelope-from ru) Date: Fri, 28 Jan 2005 20:55:21 +0200 From: Ruslan Ermilov To: Nate Lawson Message-ID: <20050128185521.GA9924@ip.net.ua> References: <41F950B8.8000602@root.org> <20050128124934.GB12500@poupinou.org> <41FA652F.1020501@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <41FA652F.1020501@root.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: freebsd-acpi@FreeBSD.org cc: Isaac Mushinsky Subject: Re: newbie question - how to read temerature 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, 29 Jan 2005 09:26:01 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 28, 2005 at 08:15:43AM -0800, Nate Lawson wrote: > Bruno Ducrot wrote: > >On Thu, Jan 27, 2005 at 06:21:11PM -0500, Isaac Mushinsky wrote: > > > >>Thanks for all the advice (no solution in sight though). By the way, th= is=20 > >>is not a laptop; it's a desktop workstation. > >> > > > >Oops... Well, I had an old Dell desktop. Got thermal stuff > >with 'classic' sensors (a LM75 IIRC, via piix4), but this was under > >Linux. Never tested with FreeBSD (it was too late, somehow). >=20 > I think we have something similar via the SMBUS drivers but no personal= =20 > experience. >=20 ports/sysutils/xmbmon Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB+oqYqRfpzJluFF4RAsB1AJ9OPzgkDSi+rONrnvjYx/z4rhZSpACdG3ZZ nBEZdOSjv/ngo3/wGThuqm0= =Jrdd -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--