From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 6 11:02:17 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1B1716A4CE for ; Mon, 6 Dec 2004 11:02:17 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF9B343D1F for ; Mon, 6 Dec 2004 11:02:17 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iB6B2HOZ027286 for ; Mon, 6 Dec 2004 11:02:17 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iB6B2HEl027280 for freebsd-acpi@freebsd.org; Mon, 6 Dec 2004 11:02:17 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Dec 2004 11:02:17 GMT Message-Id: <200412061102.iB6B2HEl027280@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, 06 Dec 2004 11:02:17 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/07] kern/53008 acpi [PATCH] genwakecode generates errornously 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 11 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 6 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 6 23:05:05 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C1BD16A4CE; Mon, 6 Dec 2004 23:05:05 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14D1C43D49; Mon, 6 Dec 2004 23:05:05 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB6N53C4011033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Dec 2004 15:05:04 -0800 Message-ID: <41B4E577.9060502@root.org> Date: Mon, 06 Dec 2004 15:04:23 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: suspend/resume improved? 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, 06 Dec 2004 23:05:05 -0000 I made a commit over the weekend to -current that may fix some suspend/resume driver issues for people. Please test and let me know if it helps. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 7 01:28:58 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EDD016A4CE for ; Tue, 7 Dec 2004 01:28:58 +0000 (GMT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3BB43D5E for ; Tue, 7 Dec 2004 01:28:57 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id iB71SvOJ075133; Mon, 6 Dec 2004 19:28:57 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <41B50754.10604@centtech.com> Date: Mon, 06 Dec 2004 19:28:52 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41B4E577.9060502@root.org> In-Reply-To: <41B4E577.9060502@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 07 Dec 2004 01:28:58 -0000 Nate Lawson wrote: > I made a commit over the weekend to -current that may fix some > suspend/resume driver issues for people. Please test and let me know if > it helps. Will these changes also apply to -stable users? Nate - I'd like to help you debug some S3 issues - I've read the ACPI debugging page and I'll start playing with what I can - but is there anything in particular I should work with? I'm running 5.3-STABLE with the acpi patches that were posted about a month ago to the -acpi list. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology When in doubt, mumble; when in trouble, delegate; when in charge, ponder ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 7 01:49:49 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD3E816A4CE for ; Tue, 7 Dec 2004 01:49:48 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CF2743D7B for ; Tue, 7 Dec 2004 01:49:48 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB71nkC4015962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Dec 2004 17:49:47 -0800 Message-ID: <41B50C12.6070103@root.org> Date: Mon, 06 Dec 2004 17:49:06 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> In-Reply-To: <41B50754.10604@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 07 Dec 2004 01:49:49 -0000 Eric Anderson wrote: > Nate Lawson wrote: > >> I made a commit over the weekend to -current that may fix some >> suspend/resume driver issues for people. Please test and let me know >> if it helps. > > Will these changes also apply to -stable users? In about a day when I MFC. > Nate - I'd like to help you debug some S3 issues - I've read the ACPI > debugging page and I'll start playing with what I can - but is there > anything in particular I should work with? I'm running 5.3-STABLE with > the acpi patches that were posted about a month ago to the -acpi list. It's pretty straightforward but arduous work. First strip down your system, removing all drivers except for the hard drive and keyboard (no USB, network, etc.) Don't run X. Try S3. If it works, add back in drivers until it fails. If it fails, try to find out where it fails. Does it truly make it to sleep or does it immediately resume? Add the beep code Warner posted a while back to the resume code and see if you get a beep. If you get a beep but a dead system, it's something in driver resume. Try to enable the network driver and ssh into your system after resume. If it works, it's a video driver problem and you need to mess with resuming the VESA BIOS. Don't run DRM with X. A lot of this is in the ACPI section of the handbook (which no one appears to have seen for some reason). More info about specific issues can be found on my web page: http://www.root.org/~nate/freebsd/acpi-todo.html -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 7 02:14:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BD7C16A4CE for ; Tue, 7 Dec 2004 02:14:22 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E1BC43D45 for ; Tue, 7 Dec 2004 02:14:21 +0000 (GMT) (envelope-from imp@harmony.village.org) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iB72CBXc059778; Mon, 6 Dec 2004 19:12:11 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Mon, 06 Dec 2004 19:12:11 -0700 (MST) Message-Id: <20041206.191211.74690236.imp@harmony.village.org> To: nate@root.org From: Warner Losh In-Reply-To: <41B50C12.6070103@root.org> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 07 Dec 2004 02:14:22 -0000 > sleep or does it immediately resume? Add the beep code Warner posted a > while back to the resume code and see if you get a beep. If you get a I was just posting takawata-san's code that he added to my system at AsiaBSDcon :-) Warner From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 7 06:58:59 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECCF616A4CF for ; Tue, 7 Dec 2004 06:58:59 +0000 (GMT) Received: from smtp9.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A18D443D53 for ; Tue, 7 Dec 2004 06:58:59 +0000 (GMT) (envelope-from aurelien.nephtali@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0907.wanadoo.fr (SMTP Server) with SMTP id BDA3F1C0016B; Tue, 7 Dec 2004 07:58:58 +0100 (CET) Received: from [192.168.2.30] (ca-sqy-11-15.w80-8.abo.wanadoo.fr [80.8.64.15]) by mwinf0907.wanadoo.fr (SMTP Server) with ESMTP id 91E521C00169; Tue, 7 Dec 2004 07:58:58 +0100 (CET) Message-ID: <41B554B1.7070508@wanadoo.fr> Date: Tue, 07 Dec 2004 07:58:57 +0100 From: Aurelien Nephtali User-Agent: Mozilla Thunderbird 0.9 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> In-Reply-To: <41B50C12.6070103@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 07 Dec 2004 06:59:00 -0000 Nate Lawson wrote: > > It's pretty straightforward but arduous work. First strip down your > system, removing all drivers except for the hard drive and keyboard (no > USB, network, etc.) Don't run X. Try S3. If it works, add back in > drivers until it fails. > > If it fails, try to find out where it fails. Does it truly make it to > sleep or does it immediately resume? Add the beep code Warner posted a > while back to the resume code and see if you get a beep. If you get a > beep but a dead system, it's something in driver resume. Try to enable > the network driver and ssh into your system after resume. If it works, > it's a video driver problem and you need to mess with resuming the VESA > BIOS. Don't run DRM with X. > > A lot of this is in the ACPI section of the handbook (which no one > appears to have seen for some reason). More info about specific issues > can be found on my web page: > > http://www.root.org/~nate/freebsd/acpi-todo.html > I will follow this procedure since resume still doesn't work on my system (Compaq Presario 2157EA). But I have a question : the speaker is correctly detected [1] but the system never produced a "beep" and spkrtest neither. So I think using the Warner "beep-code" won't help me much ? Thanks. [1] naboo% ls -l /dev/speaker crw------- 1 root wheel 240, 0 Dec 7 07:57 /dev/speaker naboo% dmesg | grep spea speaker0: port 0x61 on acpi0 -- NEPHTALI 'dak' Aurelien From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 00:26:27 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 674C216A4CE for ; Wed, 8 Dec 2004 00:26:27 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 177E743D67 for ; Wed, 8 Dec 2004 00:26:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB80QHC4016635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Dec 2004 16:26:20 -0800 Message-ID: <41B5CFDB.4090203@root.org> Date: Tue, 07 Dec 2004 07:44:27 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aurelien Nephtali References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <41B554B1.7070508@wanadoo.fr> In-Reply-To: <41B554B1.7070508@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 00:26:27 -0000 Aurelien Nephtali wrote: > Nate Lawson wrote: > >> >> It's pretty straightforward but arduous work. First strip down your >> system, removing all drivers except for the hard drive and keyboard >> (no USB, network, etc.) Don't run X. Try S3. If it works, add back >> in drivers until it fails. >> >> If it fails, try to find out where it fails. Does it truly make it to >> sleep or does it immediately resume? Add the beep code Warner posted >> a while back to the resume code and see if you get a beep. If you get >> a beep but a dead system, it's something in driver resume. Try to >> enable the network driver and ssh into your system after resume. If >> it works, it's a video driver problem and you need to mess with >> resuming the VESA BIOS. Don't run DRM with X. >> >> A lot of this is in the ACPI section of the handbook (which no one >> appears to have seen for some reason). More info about specific >> issues can be found on my web page: >> >> http://www.root.org/~nate/freebsd/acpi-todo.html >> > > I will follow this procedure since resume still doesn't work on my > system (Compaq Presario 2157EA). > > But I have a question : the speaker is correctly detected [1] but the > system never produced a "beep" and spkrtest neither. So I think using > the Warner "beep-code" won't help me much ? The beep code is very heavy-handed. It just writes directly to the speaker port in real mode so it really doesn't matter what devices you have configured. That's why it's for debug only. Warner, could you commit the patch under an appropriate kernel option (ACPI_DEBUG_BEEP or something)? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 08:11:41 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4067B16A4CE for ; Wed, 8 Dec 2004 08:11:41 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BAE43D45 for ; Wed, 8 Dec 2004 08:11:40 +0000 (GMT) (envelope-from aurelien.nephtali@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so129942rnz for ; Wed, 08 Dec 2004 00:11:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Lk+mKQiAB1KZuxkf2pU607UaOX4n/Ql0M4LtkQYWrHBGLvytJ7BLYOvqP6AofXtjSmCnenSMSspgQO60EAZzuys99Ex4wiCncL+BRDMy2KvIxsB2CqHltoyaxOAuJ91Y0kRzm4Uh6l/JfOxZMZBXo8tp43d2MCHUqUcgTZKsZWQ= Received: by 10.38.8.44 with SMTP id 44mr310499rnh; Wed, 08 Dec 2004 00:11:28 -0800 (PST) Received: by 10.38.179.60 with HTTP; Wed, 8 Dec 2004 00:11:27 -0800 (PST) Message-ID: <5334c8b04120800112e8a398a@mail.gmail.com> Date: Wed, 8 Dec 2004 09:11:27 +0100 From: Aurelien Nephtali To: Nate Lawson In-Reply-To: <41B5CFDB.4090203@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <41B554B1.7070508@wanadoo.fr> <41B5CFDB.4090203@root.org> cc: acpi@freebsd.org Subject: Re: suspend/resume improved? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aurelien Nephtali List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 08:11:41 -0000 On Tue, 07 Dec 2004 07:44:27 -0800, Nate Lawson wrote: > The beep code is very heavy-handed. It just writes directly to the > speaker port in real mode so it really doesn't matter what devices you > have configured. That's why it's for debug only. Warner, could you > commit the patch under an appropriate kernel option (ACPI_DEBUG_BEEP or > something)? Just to test, I've disabled the sound (commented out 'device sound' and 'device snd_t4dwave' from my kernel config file) and the speaker now works! I've remove everything from the system as you said, but the system still doesn't wake up from suspend... the LCD stays black (with or without reset_video=1) and the keyboard doesn't seem to respond since a CTRL+ALT+SUPPR doesn't reboot the system... I've done my tests under console mode, not X11. -- Aurelien 'dak' Nephtali From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 09:58:49 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF2C116A4CE for ; Wed, 8 Dec 2004 09:58:49 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 521C643D53 for ; Wed, 8 Dec 2004 09:58:49 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id 1D388DBC0F; Wed, 8 Dec 2004 10:58:48 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id EF9B08C196; Wed, 8 Dec 2004 10:58:47 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id D77EF8C07F; Wed, 8 Dec 2004 10:58:47 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 3F4F5D46A8; Wed, 8 Dec 2004 10:58:47 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id iB89wlhp084385; Wed, 8 Dec 2004 10:58:47 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id iB89wk98001359; Wed, 8 Dec 2004 10:58:46 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id iB89wjHl001358; Wed, 8 Dec 2004 10:58:45 +0100 (CET) (envelope-from q@uni.de) Date: Wed, 8 Dec 2004 10:58:45 +0100 From: Ulrich Spoerlein To: Nate Lawson Message-ID: <20041208095845.GA896@galgenberg.net> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <41B50C12.6070103@root.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 09:58:50 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 06.12.2004 at 17:49:06 -0800, Nate Lawson wrote: > It's pretty straightforward but arduous work. First strip down your=20 > system, removing all drivers except for the hard drive and keyboard (no= =20 > USB, network, etc.) Don't run X. Try S3. If it works, add back in=20 > drivers until it fails. > [Resume not working] What can I do, if entering S3 immediately reboots the Laptop (Dell Inspiron 8600c)? Any output I could capture before it resets itself? Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBttBVmArGtfDbn0QRAigIAKDbBABcfoq9I8xTRJjYdbiHklVRDgCfWhJE bownxZmH761cFulo1ghb+Po= =ZI+f -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 20:38:41 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B08B216A4CE for ; Wed, 8 Dec 2004 20:38:41 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B9A43D5D for ; Wed, 8 Dec 2004 20:38:41 +0000 (GMT) (envelope-from vladimir@math.uic.edu) Received: from cat.math.uic.edu (c-24-12-126-199.client.comcast.net[24.12.126.199]) by comcast.net (rwcrmhc11) with SMTP id <2004120820383801300dqof9e>; Wed, 8 Dec 2004 20:38:38 +0000 Received: (qmail 1265 invoked by uid 31415); 8 Dec 2004 20:38:38 -0000 Date: Wed, 8 Dec 2004 14:38:38 -0600 From: Vladimir Egorin To: Nate Lawson Message-ID: <20041208203838.GA1218@math.uic.edu> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B50C12.6070103@root.org> User-Agent: Mutt/1.5.6i cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 20:38:41 -0000 On Mon, Dec 06, 2004 at 05:49:06PM -0800, Nate Lawson wrote: > Eric Anderson wrote: > >Nate Lawson wrote: > > > >>I made a commit over the weekend to -current that may fix some > >>suspend/resume driver issues for people. Please test and let me know > >>if it helps. > > > >Will these changes also apply to -stable users? > > In about a day when I MFC. > > >Nate - I'd like to help you debug some S3 issues - I've read the ACPI > >debugging page and I'll start playing with what I can - but is there > >anything in particular I should work with? I'm running 5.3-STABLE with > >the acpi patches that were posted about a month ago to the -acpi list. > > It's pretty straightforward but arduous work. First strip down your > system, removing all drivers except for the hard drive and keyboard (no > USB, network, etc.) Don't run X. Try S3. If it works, add back in > drivers until it fails. > > If it fails, try to find out where it fails. Does it truly make it to > sleep or does it immediately resume? Add the beep code Warner posted a > while back to the resume code and see if you get a beep. If you get a > beep but a dead system, it's something in driver resume. Try to enable > the network driver and ssh into your system after resume. If it works, > it's a video driver problem and you need to mess with resuming the VESA > BIOS. Don't run DRM with X. Thanks for these instructions. I hoped for a while to get suspend/resume working on my desktop (Asus P4P8X, P4 2.0). I've finally narrowed the problem to sk driver (for a built-in ethernet). Any attempt to use the network after resume (even typing "ifconfig") results in a hard lockup, I cannot enter the debugger from the console. -- Vladimir From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 20:51:47 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58CAC16A4CE for ; Wed, 8 Dec 2004 20:51:47 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1888D43D2D for ; Wed, 8 Dec 2004 20:51:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB8KpjC4015369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2004 12:51:46 -0800 Message-ID: <41B76960.7030006@root.org> Date: Wed, 08 Dec 2004 12:51:44 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Egorin References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208203838.GA1218@math.uic.edu> In-Reply-To: <20041208203838.GA1218@math.uic.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 20:51:47 -0000 Vladimir Egorin wrote: > On Mon, Dec 06, 2004 at 05:49:06PM -0800, Nate Lawson wrote: > > Eric Anderson wrote: > > >Nate Lawson wrote: > > > > > >>I made a commit over the weekend to -current that may fix some > > >>suspend/resume driver issues for people. Please test and let me know > > >>if it helps. > > > > > >Will these changes also apply to -stable users? > > > > In about a day when I MFC. > > > > >Nate - I'd like to help you debug some S3 issues - I've read the ACPI > > >debugging page and I'll start playing with what I can - but is there > > >anything in particular I should work with? I'm running 5.3-STABLE with > > >the acpi patches that were posted about a month ago to the -acpi list. > > > > It's pretty straightforward but arduous work. First strip down your > > system, removing all drivers except for the hard drive and keyboard (no > > USB, network, etc.) Don't run X. Try S3. If it works, add back in > > drivers until it fails. > > > > If it fails, try to find out where it fails. Does it truly make it to > > sleep or does it immediately resume? Add the beep code Warner posted a > > while back to the resume code and see if you get a beep. If you get a > > beep but a dead system, it's something in driver resume. Try to enable > > the network driver and ssh into your system after resume. If it works, > > it's a video driver problem and you need to mess with resuming the VESA > > BIOS. Don't run DRM with X. > > Thanks for these instructions. I hoped for a while to get > suspend/resume working on my desktop (Asus P4P8X, P4 2.0). > I've finally narrowed the problem to sk driver (for a built-in > ethernet). Any attempt to use the network after resume (even > typing "ifconfig") results in a hard lockup, I cannot enter the > debugger from the console. Unfortunately, I can't help debug driver problems. Your best bet is to send your report to the freebsd-current list. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 20:58:29 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B56EA16A4CE for ; Wed, 8 Dec 2004 20:58:29 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B7F743D68 for ; Wed, 8 Dec 2004 20:58:29 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB8KwRC4015541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2004 12:58:28 -0800 Message-ID: <41B76AF2.3040204@root.org> Date: Wed, 08 Dec 2004 12:58:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> In-Reply-To: <20041208095845.GA896@galgenberg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 20:58:29 -0000 Ulrich Spoerlein wrote: > On Mon, 06.12.2004 at 17:49:06 -0800, Nate Lawson wrote: > >>It's pretty straightforward but arduous work. First strip down your >>system, removing all drivers except for the hard drive and keyboard (no >>USB, network, etc.) Don't run X. Try S3. If it works, add back in >>drivers until it fails. >>[Resume not working] > > What can I do, if entering S3 immediately reboots the Laptop (Dell > Inspiron 8600c)? Any output I could capture before it resets itself? > > Ulrich Spoerlein Add an infinite loop at various points in the suspend process until it hangs but doesn't reset. Start with the end of the first function below and work your way backwards. Once you identify the exact place the reset occurs, we can figure out why. Use boot -s to keep from having to fsck on each reset or hang. AcpiEnterSleepState():sys/contrib/dev/acpica/hwsleep.c acpi_sleep_machdep():sys/i386/acpica/acpi_wakeup.c acpi_SetSleepState():sys/dev/acpica/acpi.c. C infinite loop: foo: goto foo; ASM infinite loop: foo: jmp foo -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 21:01:45 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 797A816A4CE for ; Wed, 8 Dec 2004 21:01:45 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1470443D46 for ; Wed, 8 Dec 2004 21:01:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB8L1iC4015595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2004 13:01:44 -0800 Message-ID: <41B76BB6.3090902@root.org> Date: Wed, 08 Dec 2004 13:01:42 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aurelien Nephtali References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <41B554B1.7070508@wanadoo.fr> <41B5CFDB.4090203@root.org> <5334c8b04120800112e8a398a@mail.gmail.com> In-Reply-To: <5334c8b04120800112e8a398a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 21:01:45 -0000 Aurelien Nephtali wrote: > On Tue, 07 Dec 2004 07:44:27 -0800, Nate Lawson wrote: > > >>The beep code is very heavy-handed. It just writes directly to the >>speaker port in real mode so it really doesn't matter what devices you >>have configured. That's why it's for debug only. Warner, could you >>commit the patch under an appropriate kernel option (ACPI_DEBUG_BEEP or >>something)? > > > Just to test, I've disabled the sound (commented out 'device sound' > and 'device snd_t4dwave' from my kernel config file) and the speaker > now works! > > I've remove everything from the system as you said, but the system > still doesn't wake up from suspend... the LCD stays black (with or > without reset_video=1) and > the keyboard doesn't seem to respond since a CTRL+ALT+SUPPR doesn't reboot > the system... I've done my tests under console mode, not X11. Try X also. For some video cards, it has a better chance of reinitializing things than the console. Is the system live? Does capslock work? Does the hdd light flash when you hit the button to wake the system? Can you ping it from another host or see output from a serial console of it attempting to resume? Did you add Warner/Takanori's beep patch and hear it beep while starting to resume? This test is the most important to see if the wake code is even getting called or your system doesn't even start resuming. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 8 21:32:17 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40A0F16A4CE for ; Wed, 8 Dec 2004 21:32:17 +0000 (GMT) Received: from smtp9.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F24D343D4C for ; Wed, 8 Dec 2004 21:32:16 +0000 (GMT) (envelope-from aurelien.nephtali@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0912.wanadoo.fr (SMTP Server) with SMTP id AE7151C00610; Wed, 8 Dec 2004 22:32:15 +0100 (CET) Received: from [192.168.2.30] (ca-sqy-5-33.w80-8.abo.wanadoo.fr [80.8.58.33]) by mwinf0912.wanadoo.fr (SMTP Server) with ESMTP id 7DBE71C0060B; Wed, 8 Dec 2004 22:32:15 +0100 (CET) Message-ID: <41B772DF.4010005@wanadoo.fr> Date: Wed, 08 Dec 2004 22:32:15 +0100 From: Aurelien Nephtali User-Agent: Mozilla Thunderbird 0.9 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <41B554B1.7070508@wanadoo.fr> <41B5CFDB.4090203@root.org> <5334c8b04120800112e8a398a@mail.gmail.com> <41B76BB6.3090902@root.org> In-Reply-To: <41B76BB6.3090902@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: suspend/resume improved? 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, 08 Dec 2004 21:32:17 -0000 Nate Lawson wrote: > Try X also. For some video cards, it has a better chance of > reinitializing things than the console. Is the system live? Does > capslock work? Does the hdd light flash when you hit the button to wake > the system? Can you ping it from another host or see output from a > serial console of it attempting to resume? > > Did you add Warner/Takanori's beep patch and hear it beep while starting > to resume? This test is the most important to see if the wake code is > even getting called or your system doesn't even start resuming. > It does the same thing under X. The laptop can't be ping'ed when resumed, the system does not seem to be alive and the HDD ligh does not light at all. I would like to test the beep patch but I can't find it anywhere ... :/ -- NEPHTALI 'dak' Aurelien TEK2 - Promo 2008 06.19.84.90.10 From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 9 07:48:32 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5225116A4CE for ; Thu, 9 Dec 2004 07:48:32 +0000 (GMT) Received: from muse.clarku.edu (calliope.clarku.edu [140.232.1.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id F068943D3F for ; Thu, 9 Dec 2004 07:48:29 +0000 (GMT) (envelope-from ipartola@clarku.edu) Received: from [140.232.148.83] (thalia.clarku.edu [140.232.1.65]) by muse.clarku.edu (Postfix) with ESMTP id 4F8B51CE355 for ; Thu, 9 Dec 2004 02:48:29 -0500 (EST) Message-ID: <41B8034E.3060900@clarku.edu> Date: Thu, 09 Dec 2004 02:48:30 -0500 From: Igor Partola User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Dell Inspiron 8600 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, 09 Dec 2004 07:48:32 -0000 Good time of day, everyone. I have had this laptop for a while now and the only thing that is keeping me from switching to FreeBSD as my normal desktop environment is the ACPI. As usual S1 is supported while S3 is not. I've tried applying the latest patch but I saw no improvement. I tried running 5.1 on this machine a while ago and there more features seemed to be supported. Hitting fn + F3 brought me to BIOS and closing the lid turned off the screen (I believe that was after I issued acpiconf -d as root). This functionality in 5.3 seems to be missing and I see now way to turn off the screen (xset does not work as it does not turn off backlight. I don't like this way anyways since I like console a lot). When I issue acpiconf -s 3 I see that the laptop is preparing to go in suspend and the power indicator light actually starts dimming but after a second the fan starts going like a jet and the system reboots. I tried stripping the system of off all the unnecessary stuff (or so I think) but got the same effect. DSDT seems to be fine (5 Warnings, 4 of them about _S0C, one about _WAK). I overrode it with a working one but nothing changed. I would appreciate if someone gave me a piece of either hope or advice on how to work with this. Respect Igor I am kind of new to the whole patching thing so some of the patches for some reason don't apply on my sys tree (generate .rej). Is there a manual on how to patch things properly? Are all patches created equal? From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 09:33:26 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0A5016A4CE for ; Fri, 10 Dec 2004 09:33:26 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F01D843D3F for ; Fri, 10 Dec 2004 09:33:25 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 82B72D4567; Fri, 10 Dec 2004 10:33:24 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 5A0218FE26; Fri, 10 Dec 2004 10:33:24 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 3D66F889BA; Fri, 10 Dec 2004 10:33:24 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id BC88AD4567; Fri, 10 Dec 2004 10:33:23 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id iBA9XNGc033879; Fri, 10 Dec 2004 10:33:23 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id iBA9XNJ7001496; Fri, 10 Dec 2004 10:33:23 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id iBA9XLTC001495; Fri, 10 Dec 2004 10:33:21 +0100 (CET) (envelope-from q@uni.de) Date: Fri, 10 Dec 2004 10:33:21 +0100 From: Ulrich Spoerlein To: Igor Partola Message-ID: <20041210093321.GB793@galgenberg.net> References: <41B8034E.3060900@clarku.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline In-Reply-To: <41B8034E.3060900@clarku.edu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-acpi@freebsd.org Subject: Re: Dell Inspiron 8600 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, 10 Dec 2004 09:33:26 -0000 --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09.12.2004 at 02:48:30 -0500, Igor Partola wrote: > I tried running 5.1 on this machine a while ago and there more features= =20 > seemed to be supported. Hitting fn + F3 brought me to BIOS and closing=20 > the lid turned off the screen (I believe that was after I issued=20 > acpiconf -d as root). This functionality in 5.3 seems to be missing and= =20 > I see now way to turn off the screen (xset does not work as it does not= =20 > turn off backlight. I don't like this way anyways since I like console a= =20 > lot). This works like a charm: acpi_video_load=3DYES in /boot/loader.conf And this in /etc/devd.conf notify 10 { match "system" "ACPI"; match "subsystem" "Lid"; action "/sbin/sysctl hw.acpi.video.lcd0.active=3D$notify"; }; This will turn on/off the LCD when the lid-key is pressed. I also added this, which turns off the LCD when pressing suspend: notify 10 { match "system" "ACPI"; match "subsystem" "Button"; match "notify" "0x01"; action "/sbin/sysctl hw.acpi.video.lcd0.active=3D0"; }; Turning the LCD back on, when resuming, needs to be done manually. I think /etc/rc.{suspend,resume} is a better place for this. > When I issue acpiconf -s 3 I see that the laptop is preparing to go in=20 > suspend and the power indicator light actually starts dimming but after= =20 > a second the fan starts going like a jet and the system reboots. I tried= =20 > stripping the system of off all the unnecessary stuff (or so I think)=20 > but got the same effect. Nate suggested some things I could try to narrow this problem done. I'll give them a try over the weekend. Stay tuned! :) Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --MnLPg7ZWsaic7Fhd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBuW1hmArGtfDbn0QRAgMAAKDI41dmjhljcxmc/LPmqlza7sMUvwCg72tf TzY2xF+dOwxKULhK3TuWgmk= =FAhX -----END PGP SIGNATURE----- --MnLPg7ZWsaic7Fhd-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 13:12:23 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CD0716A4CE; Fri, 10 Dec 2004 13:12:23 +0000 (GMT) Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEBC43D49; Fri, 10 Dec 2004 13:12:23 +0000 (GMT) (envelope-from freebsd@mhueck.demon.nl) Received: from [213.51.128.136] (port=37769 helo=smtp5.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1CckZG-0003a2-Om; Fri, 10 Dec 2004 14:12:18 +0100 Received: from cc731484-a.groni1.gr.home.nl ([217.120.199.34]:2500 helo=me) by smtp5.home.nl with esmtp (Exim 4.30) id 1CckZE-00037p-Mp; Fri, 10 Dec 2004 14:12:16 +0100 From: "M. Hueck" To: Date: Fri, 10 Dec 2004 14:10:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTem1ReocLk7rxrTzWZxOlWqLYvoQAHXyGg In-Reply-To: <20041210093321.GB793@galgenberg.net> X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean Message-Id: <20041210131223.2AEBC43D49@mx1.FreeBSD.org> cc: freebsd-acpi@freebsd.org Subject: Dell Inspiron 8200 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, 10 Dec 2004 13:12:23 -0000 Hello, I have a Dell Inspiron 8200 laptop running FreeBSD 5.3 and I have one thing that I'd like to get working: Turning off the LCD including backlight. I noticed a post earlier today for a 8600 that had acpi_video_load="YES" in /boot/loader.conf. I added this and rebooted. Then when I type sysctl hw.acpi.video.lcd0.active=0 The LCD turns off for about a second, then comes back on. I'd like a small script or something like that that turns off the lcd and leaves it off until I hit a (specific?) key. Thanks, M. Hueck From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 13:36:18 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 981F716A4CE for ; Fri, 10 Dec 2004 13:36:18 +0000 (GMT) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3F143D31 for ; Fri, 10 Dec 2004 13:36:17 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mailhost.tao.org.uk (Postfix) with ESMTP id 612DC7523 for ; Fri, 10 Dec 2004 13:36:16 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 100) id 52DE5408B; Fri, 10 Dec 2004 13:36:15 +0000 (GMT) Date: Fri, 10 Dec 2004 13:36:15 +0000 From: Josef Karthauser To: freebsd-acpi@freebsd.org Message-ID: <20041210133615.GA1482@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: S3 on a Sony VGN-A290 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, 10 Dec 2004 13:36:18 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Grump. I leave my new Sony in S3 and come back to it in the morning to find that it's run out of battery :/. I thought that S3 was a low energy state. Anyone else got a similar machine? Is it a problem with the machine or our ACPI? (I'm running RELENG_5 on it). Joe ps. I remember some talk a while ago about a native S4 implementation - FreeBSD suspend to disk. Has there been any progress in this direction? --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iEYEARECAAYFAkG5pk4ACgkQXVIcjOaxUBbZyACeMSTHTQUAR27EE5939Hf5TutY 2HMAoImPOegWoFrdB+NNVoxg96UJ/eR3 =CafW -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 17:17:29 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B942C16A4CF; Fri, 10 Dec 2004 17:17:29 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3022B43D55; Fri, 10 Dec 2004 17:17:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBAHFp0r032835; Fri, 10 Dec 2004 10:15:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 10 Dec 2004 10:16:05 -0700 (MST) Message-Id: <20041210.101605.32502955.imp@bsdimp.com> To: joe@freebsd.org From: "M. Warner Losh" In-Reply-To: <20041210133615.GA1482@genius.tao.org.uk> References: <20041210133615.GA1482@genius.tao.org.uk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 17:17:29 -0000 In message: <20041210133615.GA1482@genius.tao.org.uk> Josef Karthauser writes: : Grump. I leave my new Sony in S3 and come back to it in the morning to : find that it's run out of battery :/. I thought that S3 was a low : energy state. Anyone else got a similar machine? Is it a problem with : the machine or our ACPI? (I'm running RELENG_5 on it). It is a Low energy state. However, it isn't a NO energy state. Warner From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 17:27:57 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BD816A4CE; Fri, 10 Dec 2004 17:27:57 +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 215C443D48; Fri, 10 Dec 2004 17:27:57 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from bigguy.am-productions.biz (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)iBAH6ZWp066553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 10 Dec 2004 12:06:36 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-acpi@freebsd.org Date: Fri, 10 Dec 2004 12:31:00 -0500 User-Agent: KMail/1.7 References: <20041210133615.GA1482@genius.tao.org.uk> In-Reply-To: <20041210133615.GA1482@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1729139.BVVGGGJJhT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412101231.10146.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: Josef Karthauser Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 17:27:57 -0000 --nextPart1729139.BVVGGGJJhT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 10 December 2004 08:36 am, Josef Karthauser wrote: > Grump. I leave my new Sony in S3 and come back to it in the morning to > find that it's run out of battery :/. I thought that S3 was a low > energy state. Anyone else got a similar machine? Is it a problem with > the machine or our ACPI? (I'm running RELENG_5 on it). > > Joe > > ps. I remember some talk a while ago about a native S4 implementation - > FreeBSD suspend to disk. Has there been any progress in this direction? This depends on what the ACPI on your systems does. It sounds like it is=20 similar to my P2110 and that the video adpater isn't turned off,=20 eventhough the backlight goes off when the system goes into S3. I'm using= =20 the acpi_video DPMS patch posted a while back and significantly reduces=20 the power drain while in S3, but there must still be some devices that=20 aren't getting powered down since the power drain when compared to Windows= =20 2000, is still much higher. For example in Windows I can leave the system= =20 suspended on battery for 2 days and only see a few percent drop in the=20 battery level, where as FreeBSD 6-CURRENT I can only leave it suspended=20 for about a day before it kills off the battery. The PCI power state transition code recently added didn't show any affect,= =20 but that was with an older kernel, I'll try again this weekend and double=20 check the compenets are actually entering D3. =2D-=20 Anish Mistry --nextPart1729139.BVVGGGJJhT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBud1exqA5ziudZT0RAjfHAKCJN70/yEbSI5RXvB8h9hrzbCsU8gCgxSL9 kuMxCyv59TBtNok9FGqD+Vw= =+K4i -----END PGP SIGNATURE----- --nextPart1729139.BVVGGGJJhT-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 17:39:16 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFDB816A4CE for ; Fri, 10 Dec 2004 17:39:16 +0000 (GMT) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CEAA43D1D for ; Fri, 10 Dec 2004 17:39:15 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mailhost.tao.org.uk (Postfix) with ESMTP id 4557C7523; Fri, 10 Dec 2004 17:39:14 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 100) id 39129408B; Fri, 10 Dec 2004 17:39:13 +0000 (GMT) Date: Fri, 10 Dec 2004 17:39:13 +0000 From: Josef Karthauser To: Anish Mistry Message-ID: <20041210173913.GI1615@genius.tao.org.uk> References: <20041210133615.GA1482@genius.tao.org.uk> <200412101231.10146.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9iyR+p8Z2cn535Lj" Content-Disposition: inline In-Reply-To: <200412101231.10146.mistry.7@osu.edu> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@freebsd.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 17:39:17 -0000 --9iyR+p8Z2cn535Lj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 10, 2004 at 12:31:00PM -0500, Anish Mistry wrote: > On Friday 10 December 2004 08:36 am, Josef Karthauser wrote: > > Grump. I leave my new Sony in S3 and come back to it in the morning to > > find that it's run out of battery :/. I thought that S3 was a low > > energy state. Anyone else got a similar machine? Is it a problem with > > the machine or our ACPI? (I'm running RELENG_5 on it). > > > > Joe > > > > ps. I remember some talk a while ago about a native S4 implementation - > > FreeBSD suspend to disk. Has there been any progress in this direction? > This depends on what the ACPI on your systems does. It sounds like it is= =20 > similar to my P2110 and that the video adpater isn't turned off,=20 > eventhough the backlight goes off when the system goes into S3. I'm usin= g=20 > the acpi_video DPMS patch posted a while back and significantly reduces= =20 > the power drain while in S3, but there must still be some devices that=20 > aren't getting powered down since the power drain when compared to Window= s=20 > 2000, is still much higher. For example in Windows I can leave the syste= m=20 > suspended on battery for 2 days and only see a few percent drop in the=20 > battery level, where as FreeBSD 6-CURRENT I can only leave it suspended= =20 > for about a day before it kills off the battery. > The PCI power state transition code recently added didn't show any affect= ,=20 > but that was with an older kernel, I'll try again this weekend and double= =20 > check the compenets are actually entering D3. Interesting. I'm running RELENG_5 on this machine, is there any way that I could test any code? In particular the acpi_video DPMS patch you mention; is that compatible with 5? I've got the following ACPI modules loaded: 4 1 0xc09f3000 4d98 acpi_video.ko 5 16 0xc09f8000 53828 acpi.ko 6 1 0xc0a4c000 25b4 acpi_sony.ko The acpi_sony one I (trivially) ported to 5 myself. This is the list of acpi sysctl variables that appear: debug.acpi.acpi_ca_version: 0x20040527 debug.acpi.semaphore_debug: 0 dev.acpi.0.%desc: SONY dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_acad.0.%desc: AC Adapter dev.acpi_acad.0.%driver: acpi_acad dev.acpi_acad.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_.ACAD dev.acpi_acad.0.%parent: acpi0 dev.acpi_acad.0.%pnpinfo: _HID=3DACPI0003 _UID=3D0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=3D\_SB_.PWRB dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.%pnpinfo: _HID=3DPNP0C0C _UID=3D0 dev.acpi_button.0.wake: 1 dev.acpi_cmbat.0.%desc: Control Method Battery dev.acpi_cmbat.0.%driver: acpi_cmbat dev.acpi_cmbat.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_.BAT1 dev.acpi_cmbat.0.%parent: acpi0 dev.acpi_cmbat.0.%pnpinfo: _HID=3DPNP0C0A _UID=3D0 dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x1c dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_ dev.acpi_ec.0.%parent: acpi0 dev.acpi_ec.0.%pnpinfo: _HID=3DPNP0C09 _UID=3D0 dev.acpi_ec.0.wake: 0 dev.acpi_lid.0.%desc: Control Method Lid Switch dev.acpi_lid.0.%driver: acpi_lid dev.acpi_lid.0.%location: handle=3D\_SB_.LID_ dev.acpi_lid.0.%parent: acpi0 dev.acpi_lid.0.%pnpinfo: _HID=3DPNP0C0D _UID=3D0 dev.acpi_sony.0.%desc: Sony notebook controller dev.acpi_sony.0.%driver: acpi_sony dev.acpi_sony.0.%location: handle=3D\_SB_.PCI0.SBRG.SNC_ dev.acpi_sony.0.%parent: acpi0 dev.acpi_sony.0.%pnpinfo: _HID=3DSNY5001 _UID=3D0 dev.acpi_sony.0.brightness: 0 dev.acpi_sony.0.cdp: 0 dev.acpi_sony.0.ctr: 0 dev.acpi_sony.0.pcr: 0 dev.acpi_sony.0.wdp: 1280 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=3D\_SB_.PCI0.SBRG.SYSR dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.0.%pnpinfo: _HID=3DPNP0C02 _UID=3D1 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=3D\_SB_.PCI0.SBRG.FWH_ dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.1.%pnpinfo: _HID=3DPNP0C02 _UID=3D3 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=3D\_SB_.PCI0.SBRG.OSYS dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.2.%pnpinfo: _HID=3DPNP0C02 _UID=3D2 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%parent: acpi0 dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=3D\_TZ_.ATF0 dev.acpi_tz.0.%parent: acpi0 dev.acpi_tz.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.atdma.0.%parent: acpi0 dev.atkbdc.0.%parent: acpi0 dev.atpic.0.%parent: acpi0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%parent: acpi0 dev.cpu.0.%parent: acpi0 dev.npxisa.0.%parent: acpi0 dev.pcib.0.%parent: acpi0 dev.psmcpnp.0.%parent: acpi0 hw.acpi.acline: 1 hw.acpi.battery.info_expire: 5 hw.acpi.battery.life: 100 hw.acpi.battery.state: 2 hw.acpi.battery.time: -1 hw.acpi.battery.units: 1 hw.acpi.cpu.cx_lowest: C2 hw.acpi.cpu.cx_supported: C1/1 C2/1 hw.acpi.cpu.cx_usage: 0.00% 100.00% hw.acpi.cpu.throttle_max: 8 hw.acpi.cpu.throttle_state: 8 hw.acpi.lid_switch_state: S3 hw.acpi.power_button_state: S5 hw.acpi.reset_video: 1 hw.acpi.s4bios: 0 hw.acpi.sleep_button_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.standby_state: S1 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.suspend_state: S3 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._CRT: 99.9C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._PSV: 89.9C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.temperature: 44.9C hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.verbose: 0 machdep.acpi_root: 1004528 machdep.acpi_timer_freq: 3579545 if that helps. Regards, Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --9iyR+p8Z2cn535Lj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iEYEARECAAYFAkG530AACgkQXVIcjOaxUBYdFQCcD5ZDCR1f+hfptHHE4g+cKx8/ H9AAoIxMuf7GHHYFWqE+ri5+4brOCqsW =i+JG -----END PGP SIGNATURE----- --9iyR+p8Z2cn535Lj-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 17:45:36 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E4E16A4CE; Fri, 10 Dec 2004 17:45:36 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F407743D68; Fri, 10 Dec 2004 17:45:35 +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; Fri, 10 Dec 2004 09:45:35 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DF64B5D04; Fri, 10 Dec 2004 09:45:34 -0800 (PST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: "M. Warner Losh" In-reply-to: Your message of "Fri, 10 Dec 2004 10:16:05 MST." <20041210.101605.32502955.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_10231918290" Date: Fri, 10 Dec 2004 09:45:34 -0800 From: "Kevin Oberman" Message-Id: <20041210174534.DF64B5D04@ptavv.es.net> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: joe@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 17:45:36 -0000 This is a multipart MIME message. --==_Exmh_10231918290 Content-Type: text/plain; charset=us-ascii > Date: Fri, 10 Dec 2004 10:16:05 -0700 (MST) > From: "M. Warner Losh" > Sender: owner-freebsd-acpi@freebsd.org > > In message: <20041210133615.GA1482@genius.tao.org.uk> > Josef Karthauser writes: > : Grump. I leave my new Sony in S3 and come back to it in the morning to > : find that it's run out of battery :/. I thought that S3 was a low > : energy state. Anyone else got a similar machine? Is it a problem with > : the machine or our ACPI? (I'm running RELENG_5 on it). > > It is a Low energy state. However, it isn't a NO energy state. What version are you running? I think that Nate has added support for PCI power states to current and will probably be MFCing them soon. I have been testing them for about 2 weeks. You also want to use jhb's acpi_video_dpms patch if the back-light on your display does not turn off. This is a BIG power sink. I'll attach a copy that is clean against stable of yesterday (and probably today). Be sure that you load acpi_video! -- 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 --==_Exmh_10231918290-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:04:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36B9416A4CE for ; Fri, 10 Dec 2004 18:04:52 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8626D43D54 for ; Fri, 10 Dec 2004 18:04:51 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id ACCADD4657; Fri, 10 Dec 2004 19:04:50 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 8A4B7AB3EB; Fri, 10 Dec 2004 19:04:50 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 66F1CA7DD8; Fri, 10 Dec 2004 19:04:50 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id DAB45D4657; Fri, 10 Dec 2004 19:04:49 +0100 (CET) Received: from igor.q.local (igor.q.local [192.168.0.147]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id iBAI4n7e081419; Fri, 10 Dec 2004 19:04:49 +0100 (CET) (envelope-from q@uni.de) Received: from igor.q.local (localhost.q.local [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id iBAI4nk3001143; Fri, 10 Dec 2004 19:04:49 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id iBAI4kw8001142; Fri, 10 Dec 2004 19:04:46 +0100 (CET) (envelope-from q@uni.de) Date: Fri, 10 Dec 2004 19:04:46 +0100 From: Ulrich Spoerlein To: Nate Lawson Message-ID: <20041210180446.GA768@galgenberg.net> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> <41B76AF2.3040204@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <41B76AF2.3040204@root.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 10 Dec 2004 18:04:52 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 08.12.2004 at 12:58:26 -0800, Nate Lawson wrote: > Add an infinite loop at various points in the suspend process until it=20 > hangs but doesn't reset. Start with the end of the first function below= =20 > and work your way backwards. Once you identify the exact place the=20 > reset occurs, we can figure out why. Use boot -s to keep from having to= =20 > fsck on each reset or hang. >=20 > AcpiEnterSleepState():sys/contrib/dev/acpica/hwsleep.c Line 444 is the culprit: ACPI_FLUSH_CPU_CACHE (); Status =3D AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK, ACPI_REGISTER_PM1= A_CONTROL, PM1AControl); if (ACPI_FAILURE (Status)) { return_ACPI_STATUS (Status); } Putting the loop before AcpiHwRegisterWrite will enter infinite loop, putting it after it -> Reset Running with ACPI_DEBUG, this is the last thing I see (hand transcribed) acpi_lid0: wake_prep enabled for \_SB.LID (S3) acpi_button0: wake_prep enabled for \_SB.PBTN (S3) unknown: wake_prep disabled wake for \_SB.PCI0.USB0 (S3) unknown: wake_prep disabled wake for \_SB.PCI0.USB1 (S3) unknown: wake_prep disabled wake for \_SB.PCI0.USB2 (S3) unknown: wake_prep disabled wake for \_SB.PCI0.USB3 (S3) =3D=3D acpi_printcpu() debug dump =3D=3D gdt[0077:c0610620] idt[07ff:c06109e0] ldt[0030] tr[0020] efl[00000092] eax[00000001] ebx[c0e31080] ecx[c0da569c] edx[0009e227] esi[00000000] edi[00000003] ebp[c5c72af8] esp[c5c72adc] cr0[8005003b] cr2[08049ed4] cr3[03e25000] cr4[00000691] cs[0008] ds[0010] es[0010] fs[0018] gs[008f] ss[0010] ASL and DSDT can be found here http://www.galgenberg.net/~q/freebsd/ Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBueU+mArGtfDbn0QRArNYAJsHnryDXZIoG3KTv36p1Fq+5G1eEQCfZ5TY rr+hYZztZO0bYOC0Hw7Lyp8= =jRlY -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:08:02 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60D8616A4CE; Fri, 10 Dec 2004 18:08:02 +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 80E0E43D54; Fri, 10 Dec 2004 18:08:00 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from bigguy.am-productions.biz (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)iBAHkcWp066609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 10 Dec 2004 12:46:38 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Josef Karthauser Date: Fri, 10 Dec 2004 13:10:55 -0500 User-Agent: KMail/1.7 References: <20041210133615.GA1482@genius.tao.org.uk> <200412101231.10146.mistry.7@osu.edu> <20041210173913.GI1615@genius.tao.org.uk> In-Reply-To: <20041210173913.GI1615@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1253840.kC6a2beUkk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412101311.02615.mistry.7@osu.edu> X-Spam-Status: No, hits=0.6 required=5.0 tests=J_CHICKENPOX_42 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: S3 on a Sony VGN-A290 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, 10 Dec 2004 18:08:02 -0000 --nextPart1253840.kC6a2beUkk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 10 December 2004 12:39 pm, you wrote: > On Fri, Dec 10, 2004 at 12:31:00PM -0500, Anish Mistry wrote: > > On Friday 10 December 2004 08:36 am, Josef Karthauser wrote: > > > Grump. I leave my new Sony in S3 and come back to it in the morning > > > to find that it's run out of battery :/. I thought that S3 was a > > > low energy state. Anyone else got a similar machine? Is it a > > > problem with the machine or our ACPI? (I'm running RELENG_5 on it). > > > > > > Joe > > > > > > ps. I remember some talk a while ago about a native S4 > > > implementation - FreeBSD suspend to disk. Has there been any > > > progress in this direction? > > > > This depends on what the ACPI on your systems does. It sounds like it > > is similar to my P2110 and that the video adpater isn't turned off, > > eventhough the backlight goes off when the system goes into S3. I'm > > using the acpi_video DPMS patch posted a while back and significantly > > reduces the power drain while in S3, but there must still be some > > devices that aren't getting powered down since the power drain when > > compared to Windows 2000, is still much higher. For example in > > Windows I can leave the system suspended on battery for 2 days and > > only see a few percent drop in the battery level, where as FreeBSD > > 6-CURRENT I can only leave it suspended for about a day before it > > kills off the battery. > > The PCI power state transition code recently added didn't show any > > affect, but that was with an older kernel, I'll try again this weekend > > and double check the compenets are actually entering D3. > > Interesting. > > I'm running RELENG_5 on this machine, is there any way that I could test > any code? In particular the acpi_video DPMS patch you mention; is that > compatible with 5? > > I've got the following ACPI modules loaded: > > 4 1 0xc09f3000 4d98 acpi_video.ko > 5 16 0xc09f8000 53828 acpi.ko > 6 1 0xc0a4c000 25b4 acpi_sony.ko > > The acpi_sony one I (trivially) ported to 5 myself. > > This is the list of acpi sysctl variables that appear: > > debug.acpi.acpi_ca_version: 0x20040527 > debug.acpi.semaphore_debug: 0 > dev.acpi.0.%desc: SONY > dev.acpi.0.%driver: acpi > dev.acpi.0.%parent: nexus0 > dev.acpi_acad.0.%desc: AC Adapter > dev.acpi_acad.0.%driver: acpi_acad > dev.acpi_acad.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_.ACAD > dev.acpi_acad.0.%parent: acpi0 > dev.acpi_acad.0.%pnpinfo: _HID=3DACPI0003 _UID=3D0 > dev.acpi_button.0.%desc: Power Button > dev.acpi_button.0.%driver: acpi_button > dev.acpi_button.0.%location: handle=3D\_SB_.PWRB > dev.acpi_button.0.%parent: acpi0 > dev.acpi_button.0.%pnpinfo: _HID=3DPNP0C0C _UID=3D0 > dev.acpi_button.0.wake: 1 > dev.acpi_cmbat.0.%desc: Control Method Battery > dev.acpi_cmbat.0.%driver: acpi_cmbat > dev.acpi_cmbat.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_.BAT1 > dev.acpi_cmbat.0.%parent: acpi0 > dev.acpi_cmbat.0.%pnpinfo: _HID=3DPNP0C0A _UID=3D0 > dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x1c > dev.acpi_ec.0.%driver: acpi_ec > dev.acpi_ec.0.%location: handle=3D\_SB_.PCI0.SBRG.EC0_ > dev.acpi_ec.0.%parent: acpi0 > dev.acpi_ec.0.%pnpinfo: _HID=3DPNP0C09 _UID=3D0 > dev.acpi_ec.0.wake: 0 > dev.acpi_lid.0.%desc: Control Method Lid Switch > dev.acpi_lid.0.%driver: acpi_lid > dev.acpi_lid.0.%location: handle=3D\_SB_.LID_ > dev.acpi_lid.0.%parent: acpi0 > dev.acpi_lid.0.%pnpinfo: _HID=3DPNP0C0D _UID=3D0 > dev.acpi_sony.0.%desc: Sony notebook controller > dev.acpi_sony.0.%driver: acpi_sony > dev.acpi_sony.0.%location: handle=3D\_SB_.PCI0.SBRG.SNC_ > dev.acpi_sony.0.%parent: acpi0 > dev.acpi_sony.0.%pnpinfo: _HID=3DSNY5001 _UID=3D0 > dev.acpi_sony.0.brightness: 0 > dev.acpi_sony.0.cdp: 0 > dev.acpi_sony.0.ctr: 0 > dev.acpi_sony.0.pcr: 0 > dev.acpi_sony.0.wdp: 1280 > dev.acpi_sysresource.0.%desc: System Resource > dev.acpi_sysresource.0.%driver: acpi_sysresource > dev.acpi_sysresource.0.%location: handle=3D\_SB_.PCI0.SBRG.SYSR > dev.acpi_sysresource.0.%parent: acpi0 > dev.acpi_sysresource.0.%pnpinfo: _HID=3DPNP0C02 _UID=3D1 > dev.acpi_sysresource.1.%desc: System Resource > dev.acpi_sysresource.1.%driver: acpi_sysresource > dev.acpi_sysresource.1.%location: handle=3D\_SB_.PCI0.SBRG.FWH_ > dev.acpi_sysresource.1.%parent: acpi0 > dev.acpi_sysresource.1.%pnpinfo: _HID=3DPNP0C02 _UID=3D3 > dev.acpi_sysresource.2.%desc: System Resource > dev.acpi_sysresource.2.%driver: acpi_sysresource > dev.acpi_sysresource.2.%location: handle=3D\_SB_.PCI0.SBRG.OSYS > dev.acpi_sysresource.2.%parent: acpi0 > dev.acpi_sysresource.2.%pnpinfo: _HID=3DPNP0C02 _UID=3D2 > dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz > dev.acpi_timer.0.%driver: acpi_timer > dev.acpi_timer.0.%location: unknown > dev.acpi_timer.0.%parent: acpi0 > dev.acpi_timer.0.%pnpinfo: unknown > dev.acpi_tz.0.%desc: Thermal Zone > dev.acpi_tz.0.%driver: acpi_tz > dev.acpi_tz.0.%location: handle=3D\_TZ_.ATF0 > dev.acpi_tz.0.%parent: acpi0 > dev.acpi_tz.0.%pnpinfo: _HID=3Dnone _UID=3D0 > dev.atdma.0.%parent: acpi0 > dev.atkbdc.0.%parent: acpi0 > dev.atpic.0.%parent: acpi0 > dev.attimer.0.%parent: acpi0 > dev.attimer.1.%parent: acpi0 > dev.cpu.0.%parent: acpi0 > dev.npxisa.0.%parent: acpi0 > dev.pcib.0.%parent: acpi0 > dev.psmcpnp.0.%parent: acpi0 > hw.acpi.acline: 1 > hw.acpi.battery.info_expire: 5 > hw.acpi.battery.life: 100 > hw.acpi.battery.state: 2 > hw.acpi.battery.time: -1 > hw.acpi.battery.units: 1 > hw.acpi.cpu.cx_lowest: C2 > hw.acpi.cpu.cx_supported: C1/1 C2/1 > hw.acpi.cpu.cx_usage: 0.00% 100.00% > hw.acpi.cpu.throttle_max: 8 > hw.acpi.cpu.throttle_state: 8 > hw.acpi.lid_switch_state: S3 > hw.acpi.power_button_state: S5 > hw.acpi.reset_video: 1 > hw.acpi.s4bios: 0 > hw.acpi.sleep_button_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.standby_state: S1 > hw.acpi.supported_sleep_state: S3 S4 S5 > hw.acpi.suspend_state: S3 > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._CRT: 99.9C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._PSV: 89.9C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.temperature: 44.9C > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.verbose: 0 > machdep.acpi_root: 1004528 > machdep.acpi_timer_freq: 3579545 > http://www.freebsd.org/~jhb/patches/acpi_video_dpms.patch It applies to the acpi_video module. =2D-=20 Anish Mistry --nextPart1253840.kC6a2beUkk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBuea2xqA5ziudZT0RAmlIAKDWDNIWrL+6gF/rGf8FGAubwjOMEwCcD4c4 Ae4pwrkA2CpStGHdkM1gbH0= =lmi3 -----END PGP SIGNATURE----- --nextPart1253840.kC6a2beUkk-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:09:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6933C16A4D3 for ; Fri, 10 Dec 2004 18:09:22 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FFD543D54 for ; Fri, 10 Dec 2004 18:09:22 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Fri, 10 Dec 2004 10:09:21 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 55D275D04 for ; Fri, 10 Dec 2004 10:09:21 -0800 (PST) To: freebsd-acpi@freebsd.org In-reply-to: Your message of "Fri, 10 Dec 2004 09:45:34 PST." <20041210174534.DF64B5D04@ptavv.es.net> Date: Fri, 10 Dec 2004 10:09:21 -0800 From: "Kevin Oberman" Message-Id: <20041210180921.55D275D04@ptavv.es.net> Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 18:09:22 -0000 > Date: Fri, 10 Dec 2004 09:45:34 -0800 > From: "Kevin Oberman" > Sender: owner-freebsd-acpi@freebsd.org > > This is a multipart MIME message. > > --==_Exmh_10231918290 > Content-Type: text/plain; charset=us-ascii > > > Date: Fri, 10 Dec 2004 10:16:05 -0700 (MST) > > From: "M. Warner Losh" > > Sender: owner-freebsd-acpi@freebsd.org > > > > In message: <20041210133615.GA1482@genius.tao.org.uk> > > Josef Karthauser writes: > > : Grump. I leave my new Sony in S3 and come back to it in the morning to > > : find that it's run out of battery :/. I thought that S3 was a low > > : energy state. Anyone else got a similar machine? Is it a problem with > > : the machine or our ACPI? (I'm running RELENG_5 on it). > > > > It is a Low energy state. However, it isn't a NO energy state. > > What version are you running? I think that Nate has added support for PCI > power states to current and will probably be MFCing them soon. I have > been testing them for about 2 weeks. > > You also want to use jhb's acpi_video_dpms patch if the back-light on > your display does not turn off. This is a BIG power sink. I'll attach > a copy that is clean against -stable of yesterday (and probably > today). Be sure that you load acpi_video! The mail list stripped off the attachment. And I see that current is running ACPI power code that is updated from what I have and shows no date to MFC. Still turning off the back-light is a MUCH bigger power saver than almost anything else you can do. I am appending the patch this time, so it should make it. ==== //depot/projects/power/sys/dev/acpica/acpi_video.c#2 - /home/john/work/p4/power/sys/dev/acpica/acpi_video.c ==== @@ -1,5 +1,6 @@ /*- * Copyright (c) 2002-2003 Taku YAMAMOTO + * Copyright (c) 2004 Benjamin Close * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -35,10 +36,33 @@ #include #include #include +#ifdef __i386__ +#include +#endif #include "acpi.h" #include +#ifdef __i386__ +#define USE_DPMS + +/* + * VESA DPMS States + */ +#define DPMS_ON 0x00 +#define DPMS_STANDBY 0x01 +#define DPMS_SUSPEND 0x02 +#define DPMS_OFF 0x04 +#define DPMS_REDUCEDON 0x08 + +#define VBE_DPMS_FUNCTION 0x4F10 +#define VBE_DPMS_GET_SUPPORTED_STATES 0x00 +#define VBE_DPMS_GET_STATE 0x02 +#define VBE_DPMS_SET_STATE 0x01 +#define VBE_MAJORVERSION_MASK 0x0F +#define VBE_MINORVERSION_MASK 0xF0 +#endif + /* ACPI video extension driver. */ struct acpi_video_output { ACPI_HANDLE handle; @@ -64,6 +88,10 @@ ACPI_HANDLE handle; struct acpi_video_output_queue vid_outputs; eventhandler_tag vid_pwr_evh; +#ifdef USE_DPMS + int vid_dpms_supported_states; + int vid_dpms_initial_state; +#endif }; /* interfaces */ @@ -72,6 +100,8 @@ static int acpi_video_attach(device_t); static int acpi_video_detach(device_t); static int acpi_video_shutdown(device_t); +static int acpi_video_suspend(device_t); +static int acpi_video_resume(device_t); static void acpi_video_notify_handler(ACPI_HANDLE, UINT32, void *); static void acpi_video_power_profile(void *); static void acpi_video_bind_outputs(struct acpi_video_softc *); @@ -93,6 +123,11 @@ static UINT32 vo_get_device_status(ACPI_HANDLE); static UINT32 vo_get_graphics_state(ACPI_HANDLE); static void vo_set_device_state(ACPI_HANDLE, UINT32); +#ifdef USE_DPMS +static int dpms_get_supported_states(int *); +static int dpms_get_current_state(int *); +static int dpms_set_state(int); +#endif /* events */ #define VID_NOTIFY_SWITCHED 0x80 @@ -139,6 +174,8 @@ DEVMETHOD(device_attach, acpi_video_attach), DEVMETHOD(device_detach, acpi_video_detach), DEVMETHOD(device_shutdown, acpi_video_shutdown), + DEVMETHOD(device_resume, acpi_video_resume), + DEVMETHOD(device_suspend, acpi_video_suspend), { 0, 0 } }; @@ -245,6 +282,13 @@ acpi_video_power_profile(sc); +#ifdef USE_DPMS + if (dpms_get_supported_states(&sc->vid_dpms_supported_states) == 0) + dpms_get_current_state(&sc->vid_dpms_initial_state); + else + sc->vid_dpms_supported_states = -1; +#endif + return (0); } @@ -282,6 +326,32 @@ return (0); } +static int +acpi_video_suspend(device_t dev) +{ + struct acpi_video_softc *sc; + + sc = device_get_softc(dev); +#ifdef USE_DPMS + if (sc->vid_dpms_supported_states != -1) + dpms_set_state(DPMS_OFF); +#endif + return (0); +} + +static int +acpi_video_resume(device_t dev) +{ + struct acpi_video_softc *sc; + + sc = device_get_softc(dev); +#ifdef USE_DPMS + if (sc->vid_dpms_supported_states != -1) + dpms_set_state(sc->vid_dpms_initial_state); +#endif + return (0); +} + static void acpi_video_notify_handler(ACPI_HANDLE handle, UINT32 notify, void *context) { @@ -896,3 +966,49 @@ printf("can't evaluate %s._DSS - %s\n", acpi_name(handle), AcpiFormatException(status)); } + +#ifdef USE_DPMS +/* XXX: Requires VM86 support in the kernel. */ +static int +dpms_call_bios(int subfunction, int *bh) +{ + struct vm86frame vmf; + int error; + + bzero(&vmf, sizeof(vmf)); + vmf.vmf_ax = VBE_DPMS_FUNCTION; + vmf.vmf_bl = subfunction; + vmf.vmf_bh = *bh; + vmf.vmf_es = 0; + vmf.vmf_di = 0; + error = vm86_intcall(0x10, &vmf); + if (error == 0 && (vmf.vmf_eax & 0xffff) != 0x004f) + error = ENXIO; + if (error == 0) + *bh = vmf.vmf_bh; + return (error); +} + +static int +dpms_get_supported_states(int *states) +{ + + *states = 0; + return (dpms_call_bios(VBE_DPMS_GET_SUPPORTED_STATES, states)); +} + +static int +dpms_get_current_state(int *state) +{ + + *state = 0; + return (dpms_call_bios(VBE_DPMS_GET_STATE, state)); +} + +static int +dpms_set_state(int state) +{ + + return (dpms_call_bios(VBE_DPMS_SET_STATE, &state)); +} +#endif -- 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 Fri Dec 10 18:39:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BBE416A4CE; Fri, 10 Dec 2004 18:39:25 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D93C43D53; Fri, 10 Dec 2004 18:39:25 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBAIdNC4014010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2004 10:39:24 -0800 Message-ID: <41B9ED5A.80503@root.org> Date: Fri, 10 Dec 2004 10:39:22 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Karthauser References: <20041210133615.GA1482@genius.tao.org.uk> In-Reply-To: <20041210133615.GA1482@genius.tao.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@FreeBSD.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 18:39:25 -0000 Josef Karthauser wrote: > Grump. I leave my new Sony in S3 and come back to it in the morning to > find that it's run out of battery :/. I thought that S3 was a low > energy state. Anyone else got a similar machine? Is it a problem with > the machine or our ACPI? (I'm running RELENG_5 on it). Try a -current kernel. It has more code to power down devices while in suspend but this part is too experimental to MFC for a while. > ps. I remember some talk a while ago about a native S4 implementation - > FreeBSD suspend to disk. Has there been any progress in this direction? Not that I know. It's at the bottom of my "would be nice" list. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:43:29 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54DCF16A4DF for ; Fri, 10 Dec 2004 18:43:29 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D6A43D39 for ; Fri, 10 Dec 2004 18:43:28 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBAIhQC4014091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2004 10:43:27 -0800 Message-ID: <41B9EE4E.8030703@root.org> Date: Fri, 10 Dec 2004 10:43:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> <41B76AF2.3040204@root.org> <20041210180446.GA768@galgenberg.net> In-Reply-To: <20041210180446.GA768@galgenberg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 10 Dec 2004 18:43:29 -0000 Ulrich Spoerlein wrote: > On Wed, 08.12.2004 at 12:58:26 -0800, Nate Lawson wrote: > >>Add an infinite loop at various points in the suspend process until it >>hangs but doesn't reset. Start with the end of the first function below >>and work your way backwards. Once you identify the exact place the >>reset occurs, we can figure out why. Use boot -s to keep from having to >>fsck on each reset or hang. >> >>AcpiEnterSleepState():sys/contrib/dev/acpica/hwsleep.c > > > Line 444 is the culprit: > ACPI_FLUSH_CPU_CACHE (); > > Status = AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK, ACPI_REGISTER_PM1A_CONTROL, PM1AControl); > if (ACPI_FAILURE (Status)) > { > return_ACPI_STATUS (Status); > } > > Putting the loop before AcpiHwRegisterWrite will enter infinite loop, > putting it after it -> Reset Interesting. If you add a "DELAY(10000);" before the register write, does this help? A more likely issue is that we need to write pm1a/b at the same time. Let me think about this and get you more info later. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:43:53 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AA1116A4CE for ; Fri, 10 Dec 2004 18:43:53 +0000 (GMT) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F5843D66 for ; Fri, 10 Dec 2004 18:43:52 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mailhost.tao.org.uk (Postfix) with ESMTP id 6FE597513; Fri, 10 Dec 2004 18:43:51 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 100) id 67458408B; Fri, 10 Dec 2004 18:43:50 +0000 (GMT) Date: Fri, 10 Dec 2004 18:43:50 +0000 From: Josef Karthauser To: Nate Lawson Message-ID: <20041210184350.GJ1615@genius.tao.org.uk> References: <20041210133615.GA1482@genius.tao.org.uk> <41B9ED5A.80503@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="451BZW+OUuJBCAYj" Content-Disposition: inline In-Reply-To: <41B9ED5A.80503@root.org> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@FreeBSD.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 18:43:53 -0000 --451BZW+OUuJBCAYj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 10, 2004 at 10:39:22AM -0800, Nate Lawson wrote: > Josef Karthauser wrote: > >Grump. I leave my new Sony in S3 and come back to it in the morning to > >find that it's run out of battery :/. I thought that S3 was a low > >energy state. Anyone else got a similar machine? Is it a problem with > >the machine or our ACPI? (I'm running RELENG_5 on it). >=20 > Try a -current kernel. It has more code to power down devices while in= =20 > suspend but this part is too experimental to MFC for a while. >=20 Can I run a current kernel on a RELENG_5 userland? Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --451BZW+OUuJBCAYj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iEYEARECAAYFAkG57mUACgkQXVIcjOaxUBYgcACffmB65i44tJZr54qVVJsxS6H4 5/MAn1SUdQ1mFSwh0TfJS+C+ngWXPFla =aKRA -----END PGP SIGNATURE----- --451BZW+OUuJBCAYj-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 18:47:19 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBF3A16A4CE; Fri, 10 Dec 2004 18:47:18 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8479943D45; Fri, 10 Dec 2004 18:47:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBAIlGC4014232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2004 10:47:17 -0800 Message-ID: <41B9EF34.9020500@root.org> Date: Fri, 10 Dec 2004 10:47:16 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Karthauser References: <20041210133615.GA1482@genius.tao.org.uk> <41B9ED5A.80503@root.org> <20041210184350.GJ1615@genius.tao.org.uk> In-Reply-To: <20041210184350.GJ1615@genius.tao.org.uk> Content-Type: multipart/mixed; boundary="------------050102010902040504040104" cc: freebsd-acpi@FreeBSD.org Subject: Re: S3 on a Sony VGN-A290 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, 10 Dec 2004 18:47:19 -0000 This is a multi-part message in MIME format. --------------050102010902040504040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Josef Karthauser wrote: > On Fri, Dec 10, 2004 at 10:39:22AM -0800, Nate Lawson wrote: > >>Josef Karthauser wrote: >> >>>Grump. I leave my new Sony in S3 and come back to it in the morning to >>>find that it's run out of battery :/. I thought that S3 was a low >>>energy state. Anyone else got a similar machine? Is it a problem with >>>the machine or our ACPI? (I'm running RELENG_5 on it). >> >>Try a -current kernel. It has more code to power down devices while in >>suspend but this part is too experimental to MFC for a while. >> > > > Can I run a current kernel on a RELENG_5 userland? For testing, should work ok. The recent mount changes may have hosed that path though. Instead, just use the attached patch against 5.x -- Nate --------------050102010902040504040104 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); --------------050102010902040504040104-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 20:54:20 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B73B16A4CE for ; Fri, 10 Dec 2004 20:54:20 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE99C43D64 for ; Fri, 10 Dec 2004 20:54:19 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id F290DD45A4; Fri, 10 Dec 2004 21:54:18 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id D5AC1AB4A5; Fri, 10 Dec 2004 21:54:18 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id B55E7AB3D0; Fri, 10 Dec 2004 21:54:18 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 78857D45A4; Fri, 10 Dec 2004 21:54:18 +0100 (CET) Received: from igor.q.local (igor.q.local [192.168.0.147]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id iBAKsIBm015021; Fri, 10 Dec 2004 21:54:18 +0100 (CET) (envelope-from q@uni.de) Received: from igor.q.local (localhost.q.local [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id iBAKsHb7001826; Fri, 10 Dec 2004 21:54:18 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id iBAKsHKU001825; Fri, 10 Dec 2004 21:54:17 +0100 (CET) (envelope-from q@uni.de) Date: Fri, 10 Dec 2004 21:54:17 +0100 From: Ulrich Spoerlein To: Nate Lawson Message-ID: <20041210205417.GB768@galgenberg.net> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> <41B76AF2.3040204@root.org> <20041210180446.GA768@galgenberg.net> <41B9EE4E.8030703@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <41B9EE4E.8030703@root.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 10 Dec 2004 20:54:20 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10.12.2004 at 10:43:26 -0800, Nate Lawson wrote: > >Line 444 is the culprit: > > ACPI_FLUSH_CPU_CACHE (); > > > > Status =3D AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK,=20 > > ACPI_REGISTER_PM1A_CONTROL, PM1AControl); > > if (ACPI_FAILURE (Status)) > > { > > return_ACPI_STATUS (Status); > > } > > > >Putting the loop before AcpiHwRegisterWrite will enter infinite loop, > >putting it after it -> Reset >=20 > Interesting. If you add a "DELAY(10000);" before the register write,=20 > does this help? A more likely issue is that we need to write pm1a/b at= =20 > the same time. Let me think about this and get you more info later. It "looks" like the delay does nothing, however I noticed that all three LEDs (num/scroll/caps lock) were lighting up for 1-2s. I then swapped pm1a and pm1b, but nothing changed. Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBugz5mArGtfDbn0QRAnmkAKDYew56rRIvIl7znhTzzMfUYUdC3QCfWiw9 MJljYO8XlDAQ4U/R4ZNzf+Y= =+TSK -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 10 22:41:16 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67BBD16A4CE; Fri, 10 Dec 2004 22:41:16 +0000 (GMT) Received: from smtpq2.home.nl (smtpq2.home.nl [213.51.128.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id C981143D5A; Fri, 10 Dec 2004 22:41:15 +0000 (GMT) (envelope-from freebsd@mhueck.demon.nl) Received: from [213.51.128.133] (port=40461 helo=smtp2.home.nl) by smtpq2.home.nl with esmtp (Exim 4.30) id 1CctRq-0002oy-WC; Fri, 10 Dec 2004 23:41:14 +0100 Received: from cc731484-a.groni1.gr.home.nl ([217.120.199.34]:2330 helo=me) by smtp2.home.nl with esmtp (Exim 4.30) id 1CctRn-0000XO-Fh; Fri, 10 Dec 2004 23:41:11 +0100 From: "M. Hueck" To: Date: Fri, 10 Dec 2004 23:39:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20041210131223.2AEBC43D49@mx1.FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTem1ReocLk7rxrTzWZxOlWqLYvoQAHXyGgABP7PCA= X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean Message-Id: <20041210224115.C981143D5A@mx1.FreeBSD.org> cc: freebsd-acpi@freebsd.org Subject: RE: Dell Inspiron 8200 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, 10 Dec 2004 22:41:16 -0000 Forgot an important problem: With this in /boot/loader.conf, I can not start X. The only error I get in the logfile is failure to load nvidia driver just after a 'write combine range already clear' info message. After the nvidia failure X gives up. Do I have to reinstall the nvidia driver because I enabled acpi_video ? Thanks, M. Hueck > -----Original Message----- > From: owner-freebsd-mobile@freebsd.org [mailto:owner-freebsd- > mobile@freebsd.org] On Behalf Of M. Hueck > Sent: vrijdag 10 december 2004 14:10 > To: freebsd-mobile@freebsd.org > Cc: freebsd-acpi@freebsd.org > Subject: Dell Inspiron 8200 > > Hello, > > I have a Dell Inspiron 8200 laptop running FreeBSD 5.3 and I have one > thing > that I'd like to get working: Turning off the LCD including backlight. > > I noticed a post earlier today for a 8600 that had acpi_video_load="YES" > in > /boot/loader.conf. I added this and rebooted. Then when I type > > sysctl hw.acpi.video.lcd0.active=0 > > The LCD turns off for about a second, then comes back on. I'd like a small > script or something like that that turns off the lcd and leaves it off > until > I hit a (specific?) key. > > Thanks, > > M. Hueck > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 01:14:27 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16A1016A4CE for ; Sat, 11 Dec 2004 01:14:27 +0000 (GMT) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C688543D41 for ; Sat, 11 Dec 2004 01:14:24 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mailhost.tao.org.uk (Postfix) with ESMTP id 01ABD7523; Sat, 11 Dec 2004 01:14:24 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 100) id 0A3C2408B; Sat, 11 Dec 2004 01:14:23 +0000 (GMT) Date: Sat, 11 Dec 2004 01:14:23 +0000 From: Josef Karthauser To: Nate Lawson Message-ID: <20041211011423.GL1615@genius.tao.org.uk> References: <20041210133615.GA1482@genius.tao.org.uk> <41B9ED5A.80503@root.org> <20041210184350.GJ1615@genius.tao.org.uk> <41B9EF34.9020500@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="00hq2S6J2Jlg6EbK" Content-Disposition: inline In-Reply-To: <41B9EF34.9020500@root.org> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@FreeBSD.org Subject: Re: S3 on a Sony VGN-A290 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, 11 Dec 2004 01:14:27 -0000 --00hq2S6J2Jlg6EbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wicked, thanks :) J. On Fri, Dec 10, 2004 at 10:47:16AM -0800, Nate Lawson wrote: > Josef Karthauser wrote: > >On Fri, Dec 10, 2004 at 10:39:22AM -0800, Nate Lawson wrote: > > > >>Josef Karthauser wrote: > >> > >>>Grump. I leave my new Sony in S3 and come back to it in the morning to > >>>find that it's run out of battery :/. I thought that S3 was a low > >>>energy state. Anyone else got a similar machine? Is it a problem with > >>>the machine or our ACPI? (I'm running RELENG_5 on it). > >> > >>Try a -current kernel. It has more code to power down devices while in= =20 > >>suspend but this part is too experimental to MFC for a while. > >> > > > > > >Can I run a current kernel on a RELENG_5 userland? >=20 > For testing, should work ok. The recent mount changes may have hosed=20 > that path though. Instead, just use the attached patch against 5.x >=20 > --=20 > Nate > Index: sys/dev/acpica/acpi.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > =20 > +#include "pci_if.h" > +#include > +#include > + > MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); > =20 > /* 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), > =20 > /* 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), > =20 > + /* PCI emulation */ > + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), > + > /* ISA emulation */ > DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), > =20 > @@ -212,6 +229,12 @@ > static int acpi_serialize_methods; > TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); > =20 > +/* Power devices off and on in suspend and resume. XXX Remove once test= ed. */ > +static int acpi_do_powerstate =3D 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 @@ > } > =20 > 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 =3D bus_generic_suspend(dev); > + if (error) > + return (error); > + > + /* > + * Now, set them into the appropriate power state, usually D3. If t= he > + * device has an _SxD method for the next sleep state, use that power > + * state instead. > + */ > + sc =3D device_get_softc(dev); > + device_get_children(dev, &devlist, &numdevs); > + for (i =3D 0; i < numdevs; i++) { > + /* If the device is not attached, we've powered it down elsewhere. */ > + child =3D 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 =3D PCI_POWERSTATE_D3; > + error =3D acpi_device_pwr_for_sleep(device_get_parent(child), > + child, &pstate); > + if ((error =3D=3D 0 || error =3D=3D ESRCH) && acpi_do_powerstate) > + pci_set_powerstate(child, pstate); > + } > + free(devlist, M_TEMP); > + error =3D 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 =3D 0; i < numdevs; i++) { > + child =3D devlist[i]; > + handle =3D 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) > { > =20 > @@ -624,6 +713,45 @@ > return (retval); > } > =20 > +/* > + * 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 =3D 0; i < numdevs; i++) { > + child =3D devlist[i]; > + if (device_get_state(child) =3D=3D DS_NOTPRESENT) { > + /* pci_set_powerstate(child, PCI_POWERSTATE_D0); */ > + if (device_probe_and_attach(child) !=3D 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)); > } > =20 > +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 =3D device_get_softc(bus); > + handle =3D 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 =3D=3D 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 =3D acpi_GetInteger(handle, sxd, dstate); > + else > + status =3D AcpiEvaluateObject(handle, sxd, NULL, NULL); > + > + switch (status) { > + case AE_OK: > + error =3D 0; > + break; > + case AE_NOT_FOUND: > + error =3D ESRCH; > + break; > + default: > + error =3D 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)); > } > =20 > +/* > + * Even though ACPI devices are not PCI, we use the PCI approach for set= ting > + * 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 =3D 0; > + h =3D acpi_get_handle(child); > + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) > + return (EINVAL); > + if (h =3D=3D NULL) > + return (0); > + > + /* Ignore errors if the power methods aren't present. */ > + status =3D acpi_pwr_switch_consumer(h, state); > + if (ACPI_FAILURE(status) && status !=3D AE_NOT_FOUND > + && status !=3D 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 @@ > }; > =20 > # > +# 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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" > =20 > +#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 parameter= s"); > =20 > static int pci_enable_io_modes =3D 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 the= re\n\ > are some peripherals that this causes problems with."); > =20 > -static int pci_do_powerstate =3D 0; > -TUNABLE_INT("hw.pci.do_powerstate", (int *)&pci_do_powerstate); > +static int pci_do_powerstate =3D 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; > =20 > /* > - * 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 =3D NULL; > + if (pci_do_powerstate) > + acpi_dev =3D devclass_get_device(devclass_find("acpi"), 0); > device_get_children(dev, &devlist, &numdevs); > for (i =3D 0; i < numdevs; i++) { > child =3D devlist[i]; > dinfo =3D (struct pci_devinfo *) device_get_ivars(child); > pci_cfg_save(child, dinfo, 0); > } > + > + /* Suspend devices before potentially powering them down. */ > + error =3D 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 =3D 0; acpi_dev && i < numdevs; i++) { > + child =3D devlist[i]; > + dinfo =3D (struct pci_devinfo *) device_get_ivars(child); > + if (device_is_attached(child) && dinfo->cfg.hdrtype =3D=3D 0) { > + dstate =3D 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); > } > =20 > 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; > =20 > /* > - * Restore the pci configuration space for each child. > + * Set each child to D0 and restore its PCI configuration space. > */ > + acpi_dev =3D NULL; > + if (pci_do_powerstate) > + acpi_dev =3D devclass_get_device(devclass_find("acpi"), 0); > device_get_children(dev, &devlist, &numdevs); > for (i =3D 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 =3D devlist[i]; > dinfo =3D (struct pci_devinfo *) device_get_ivars(child); > + if (acpi_dev && device_is_attached(child) && > + dinfo->cfg.hdrtype =3D=3D 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); --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --00hq2S6J2Jlg6EbK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iEYEARECAAYFAkG6Se4ACgkQXVIcjOaxUBZ4jgCgvR9meiQwYBTBNPS9A5Z9jUo/ YO8AoJL+eVJ+l88wtAKmJEDdc/0uPF0A =Inly -----END PGP SIGNATURE----- --00hq2S6J2Jlg6EbK-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 01:49:56 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B041B16A4CE for ; Sat, 11 Dec 2004 01:49:56 +0000 (GMT) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6159D43D41 for ; Sat, 11 Dec 2004 01:49:56 +0000 (GMT) (envelope-from yb@sainte-barbe.org) Received: from taz.hsc.fr (taz.hsc.fr [192.70.106.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "taz.hsc.fr", Issuer "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id 299852119D for ; Sat, 11 Dec 2004 02:46:13 +0100 (CET) Received: by taz.hsc.fr (Postfix, from userid 1001) id 6F6474157; Sat, 11 Dec 2004 02:46:13 +0100 (CET) Date: Sat, 11 Dec 2004 02:46:13 +0100 From: Yann Berthier To: freebsd-acpi@FreeBSD.org Message-ID: <20041211014613.GK695@hsc.fr> Mail-Followup-To: freebsd-acpi@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Organization: Herve Schauer Consultants X-Web: http://www.hsc.fr/ X-Operating-System: FreeBSD 6.0-CURRENT User-Agent: Mutt/1.5.6i Subject: suspend status 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, 11 Dec 2004 01:49:56 -0000 Hi gang, My IBM T41 suspend / resume well (-CURRENT from the 12/3): screen goes black, every activity seems stopped, resume like a champ (i'm not sure that champs resume either) but battery goes down as if it where not suspended: Remaining battery life: 99% Remaining battery time: 3:18:00 [yb@taz 19:00]% sudo zzz After resuming: Remaining battery life: 80% Remaining battery time: 2:00:00 [yb@taz 20:29]% I know the remaining battery time is not an accurate measure, but all in one I stay suspended 1h30, and my battery 'lost' 1h20 of power - so it says That's been *months* i did not try to suspend, so i don't know if this is a regression du to recent commits or not I should let the AC unplugged to see if the displayed battery time has anything to do with reality i suppose Other strangeness: the keyboard is 'slowed down' after a resume. I now this is a very unscientific remark, but no doubt about that, this is especially irritating while scrolling through my mails. Any thoughts about that ? regards, - yann From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 02:56:10 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8E8316A4CE for ; Sat, 11 Dec 2004 02:56:10 +0000 (GMT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1516A43D55 for ; Sat, 11 Dec 2004 02:56:10 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id iBB2u6OJ089244; Fri, 10 Dec 2004 20:56:07 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <41BA61C6.9080903@centtech.com> Date: Fri, 10 Dec 2004 20:56:06 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yann Berthier References: <20041211014613.GK695@hsc.fr> In-Reply-To: <20041211014613.GK695@hsc.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: suspend status 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, 11 Dec 2004 02:56:11 -0000 Yann Berthier wrote: > Hi gang, > > My IBM T41 suspend / resume well (-CURRENT from the 12/3): screen > goes black, every activity seems stopped, resume like a champ (i'm > not sure that champs resume either) > > but battery goes down as if it where not suspended: > > Remaining battery life: 99% > Remaining battery time: 3:18:00 > [yb@taz 19:00]% sudo zzz > > After resuming: > > Remaining battery life: 80% > Remaining battery time: 2:00:00 > [yb@taz 20:29]% > > I know the remaining battery time is not an accurate measure, but all > in one I stay suspended 1h30, and my battery 'lost' 1h20 of power - > so it says > Refigure your math - if 100% cpu means 3hrs 18 minutes of runtime left, then that about 200 minutes of runtime. So 1% equals 2 minutes of runtime roughly. So, you suspend - and wait up 90 minutes later. If it would have been running like normal, it would eat up 1% per 2 minutes, so about 45% of your battery - but it didn't, it only ate up 20%. So ath that rate, it was using less than half the power as when in non-suspend mode. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology When in doubt, mumble; when in trouble, delegate; when in charge, ponder ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 05:29:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C634816A4CE for ; Sat, 11 Dec 2004 05:29:04 +0000 (GMT) Received: from muse.clarku.edu (calliope.clarku.edu [140.232.1.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55BEA43D2D for ; Sat, 11 Dec 2004 05:29:04 +0000 (GMT) (envelope-from ipartola@pisem.net) Received: from [140.232.148.83] (thalia.clarku.edu [140.232.1.65]) by muse.clarku.edu (Postfix) with ESMTP id A99761D56AC for ; Sat, 11 Dec 2004 00:29:03 -0500 (EST) Message-ID: <41BA85A0.3050206@pisem.net> Date: Sat, 11 Dec 2004 00:29:04 -0500 From: Igor Partola User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Dell Inspiron 8600 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, 11 Dec 2004 05:29:04 -0000 Ulrich Spoerlein wrote: > I also added this, which turns off the LCD when pressing suspend: > notify 10 { > match "system" "ACPI"; > match "subsystem" "Button"; > match "notify" "0x01"; > action "/sbin/sysctl hw.acpi.video.lcd0.active=0"; > }; > > Turning the LCD back on, when resuming, needs to be done manually. I > think /etc/rc.{suspend,resume} is a better place for this. > > This does indeed work (just like the lid switch thing), thank you. One problem though is that rc.resume is not read in all cases. While acpiconf honors it, just hitting the suspend button and resuming (hitting the power button) does not turn the lcd back on. Is there a way to fix this? I tried setting an event in devd.conf for the power button to turn the display back. It did not work and either way I would prefer to use rc.suspend and rc.resume for this kind of a thing since I'd like to ultimately have the power button suspend and resume the machine. I appreciate the help. Respect Igor From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 09:21:01 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5334816A4CE for ; Sat, 11 Dec 2004 09:21:01 +0000 (GMT) Received: from mailhub03.unibe.ch (mailhub03-eth0.unibe.ch [130.92.9.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58F7C43D48 for ; Sat, 11 Dec 2004 09:21:00 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from localhost (scanhub01.unibe.ch [130.92.254.65]) by mailhub03.unibe.ch (Postfix) with ESMTP id 13D1D12051; Sat, 11 Dec 2004 10:20:58 +0100 (CET) Received: from mailhub03.unibe.ch ([130.92.9.70]) by localhost (scanhub01 [130.92.254.65]) (amavisd-new, port 10024) with LMTP id 14980-06-21; Sat, 11 Dec 2004 10:20:57 +0100 (CET) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub03.unibe.ch (Postfix) with ESMTP id 0C31811FD7; Sat, 11 Dec 2004 10:20:57 +0100 (CET) Received: from droopy.unibe.ch (droopy [130.92.64.20]) by asterix.unibe.ch (8.11.7p1+Sun/8.11.7) with ESMTP id iBB9Ktq11162; Sat, 11 Dec 2004 10:20:55 +0100 (MET) Received: (from roth@localhost) by droopy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id iBB9KnDf015364; Sat, 11 Dec 2004 10:20:49 +0100 (MET) Date: Sat, 11 Dec 2004 10:20:48 +0100 From: Tobias Roth To: Eric Anderson Message-ID: <20041211092048.GA15338@droopy.unibe.ch> References: <20041211014613.GK695@hsc.fr> <41BA61C6.9080903@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BA61C6.9080903@centtech.com> User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne cc: freebsd-acpi@freebsd.org Subject: Re: suspend status 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, 11 Dec 2004 09:21:01 -0000 On Fri, Dec 10, 2004 at 08:56:06PM -0600, Eric Anderson wrote: > > Refigure your math - if 100% cpu means 3hrs 18 minutes of runtime left, > then that about 200 minutes of runtime. So 1% equals 2 minutes of > runtime roughly. So, you suspend - and wait up 90 minutes later. If it > would have been running like normal, it would eat up 1% per 2 minutes, > so about 45% of your battery - but it didn't, it only ate up 20%. So > ath that rate, it was using less than half the power as when in > non-suspend mode. how long would the same laptop/battery survive when suspended from windows? i always had in mind that a suspended laptop is supposed to live for more than a day, which clearly is not the case in your example. you often hear comparisons here about how much less battery windows uses when compared to FreeBSD (or rather, how much better windows battery saving techniques are). detailed comparisons of bsd <-> linux <-> windows with good guesses of why the discrepancies are there would help. i am just trying to say that battery saving in suspend probably IS bad in FreeBSD (as compared to the possible optimum, as windows shows it). it's not just bad math in the above example. cheers, t. From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 10:17:21 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D8116A4CE for ; Sat, 11 Dec 2004 10:17:21 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8973343D41 for ; Sat, 11 Dec 2004 10:17:20 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 5B6FAD45D7 for ; Sat, 11 Dec 2004 11:17:19 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 3C5CBA7E98 for ; Sat, 11 Dec 2004 11:17:19 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 1819B9EC83 for ; Sat, 11 Dec 2004 11:17:19 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id C33F9D45D7 for ; Sat, 11 Dec 2004 11:17:18 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id iBBAHIXo033099 for ; Sat, 11 Dec 2004 11:17:18 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id iBBAHIbx001292 for ; Sat, 11 Dec 2004 11:17:18 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id iBBAHIdx001291 for freebsd-acpi@freebsd.org; Sat, 11 Dec 2004 11:17:18 +0100 (CET) (envelope-from q@uni.de) Date: Sat, 11 Dec 2004 11:17:18 +0100 From: Ulrich Spoerlein To: freebsd-acpi@freebsd.org Message-ID: <20041211101718.GA1283@galgenberg.net> References: <41BA85A0.3050206@pisem.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <41BA85A0.3050206@pisem.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Subject: Re: Dell Inspiron 8600 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, 11 Dec 2004 10:17:21 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 11.12.2004 at 00:29:04 -0500, Igor Partola wrote: > This does indeed work (just like the lid switch thing), thank you. One > problem though is that rc.resume is not read in all cases. While > acpiconf honors it, just hitting the suspend button and resuming > (hitting the power button) does not turn the lcd back on. Is there a > way to fix this? Somehow devd/acpi/whatever doesn't "see" the resume of the laptop, I normally just push the "LCD Button" after resumeing. When releasing the LCD-Button the display will turn on again. A hack, but a working one :) > I tried setting an event in devd.conf for the power button to turn > the display back. It did not work and either way I would prefer to use > rc.suspend and rc.resume for this kind of a thing since I'd like to > ultimately have the power button suspend and resume the machine. Run with 'devd -Dd', closely observe which events are triggered when hitting suspend and when resumeing (as I said above, for me, devd doesn't "see" anything when resuming :( Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBuskumArGtfDbn0QRApD2AKDuhctCrslQGz1pIq6IHjo7HTXtzQCdGP2q jK8lG2ZcgXKd0kLAcERZVoA= =rUlG -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 12:24:33 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 248A816A4CE for ; Sat, 11 Dec 2004 12:24:33 +0000 (GMT) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FAEF43D55 for ; Sat, 11 Dec 2004 12:24:32 +0000 (GMT) (envelope-from yb@sainte-barbe.org) Received: from taz.hsc.fr (taz.hsc.fr [192.70.106.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "taz.hsc.fr", Issuer "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id 3E71A2159B for ; Sat, 11 Dec 2004 13:24:31 +0100 (CET) Received: by taz.hsc.fr (Postfix, from userid 1001) id 85A4B40CE; Sat, 11 Dec 2004 13:24:30 +0100 (CET) Date: Sat, 11 Dec 2004 13:24:30 +0100 From: Yann Berthier To: freebsd-acpi@freebsd.org Message-ID: <20041211122430.GB714@hsc.fr> Mail-Followup-To: freebsd-acpi@freebsd.org References: <20041211014613.GK695@hsc.fr> <41BA61C6.9080903@centtech.com> <20041211092048.GA15338@droopy.unibe.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041211092048.GA15338@droopy.unibe.ch> X-Organization: Herve Schauer Consultants X-Web: http://www.hsc.fr/ X-Operating-System: FreeBSD 6.0-CURRENT User-Agent: Mutt/1.5.6i Subject: Re: suspend status 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, 11 Dec 2004 12:24:33 -0000 On Sat, 11 Dec 2004, Tobias Roth wrote: > On Fri, Dec 10, 2004 at 08:56:06PM -0600, Eric Anderson wrote: > > > > Refigure your math - if 100% cpu means 3hrs 18 minutes of runtime left, > > then that about 200 minutes of runtime. So 1% equals 2 minutes of > > runtime roughly. So, you suspend - and wait up 90 minutes later. If it > > would have been running like normal, it would eat up 1% per 2 minutes, > > so about 45% of your battery - but it didn't, it only ate up 20%. So > > ath that rate, it was using less than half the power as when in > > non-suspend mode. > > how long would the same laptop/battery survive when suspended from > windows? i always had in mind that a suspended laptop is supposed to > live for more than a day, which clearly is not the case in your example. > > you often hear comparisons here about how much less battery windows uses > when compared to FreeBSD (or rather, how much better windows battery > saving techniques are). detailed comparisons of bsd <-> linux <-> windows > with good guesses of why the discrepancies are there would help. > > i am just trying to say that battery saving in suspend probably IS bad > in FreeBSD (as compared to the possible optimum, as windows shows it). > it's not just bad math in the above example. Thanks, that was my point, though not clearly exposed i'm afraid (the 2 AM post excuse ;) I can do whatever maths you want, it leads me to the following conclusion that my laptop can't stay unplugged more than a few hours even suspended. It used to be an order of magnitude better with FreeBSD and ACPI, so as a user i tend to consider this a regression, even if it was with another laptop (toshiba) - yann From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 15:56:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5FE916A4CE for ; Sat, 11 Dec 2004 15:56:25 +0000 (GMT) Received: from muse.clarku.edu (calliope.clarku.edu [140.232.1.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3422C43D5A for ; Sat, 11 Dec 2004 15:56:25 +0000 (GMT) (envelope-from ipartola@pisem.net) Received: from [140.232.148.83] (thalia.clarku.edu [140.232.1.65]) by muse.clarku.edu (Postfix) with ESMTP id 7B9581D6115; Sat, 11 Dec 2004 10:54:24 -0500 (EST) Message-ID: <41BB1831.8030100@pisem.net> Date: Sat, 11 Dec 2004 10:54:25 -0500 From: Igor Partola User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein , freebsd-acpi@freebsd.org References: <41BA85A0.3050206@pisem.net> <20041211101718.GA1283@galgenberg.net> In-Reply-To: <20041211101718.GA1283@galgenberg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Dell Inspiron 8600 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, 11 Dec 2004 15:56:25 -0000 Ulrich Spoerlein wrote: >Somehow devd/acpi/whatever doesn't "see" the resume of the laptop, I >normally just push the "LCD Button" after resumeing. When releasing the >LCD-Button the display will turn on again. A hack, but a working one :) > > > >>I tried setting an event in devd.conf for the power button to turn >>the display back. It did not work and either way I would prefer to use >>rc.suspend and rc.resume for this kind of a thing since I'd like to >>ultimately have the power button suspend and resume the machine. >> >> > >Run with 'devd -Dd', closely observe which events are triggered when >hitting suspend and when resumeing (as I said above, for me, devd >doesn't "see" anything when resuming :( > > Running devd -Dd does not show any events. However I believe I found a better hack for this situation. Here's a portion of my devd.conf: notify 10 { match "system" "ACPI"; match "subsystem" "Button"; match "notify" "0x01"; notify "/etc/rc.sus"; } I hope I got the syntax right since I'm typing from memory. rc.sus is my script that calls acpiconf which *does* honor rc.suspend and rc.resume. rc.sus for now contains #!/bin/sh acpiconf -s 1 But I will modify it, unless someone fixes the event situation. Respect Igor P.S.: Don't forget to set hw.acpi.sleep_button_state to NONE From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 19:40:25 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D83B16A4CE for ; Sat, 11 Dec 2004 19:40:25 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id D389443D64 for ; Sat, 11 Dec 2004 19:40:24 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123])iBBJeSsV012650; Sat, 11 Dec 2004 14:40:28 -0500 Message-ID: <41BB4D22.6080205@root.org> Date: Sat, 11 Dec 2004 11:40:18 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Roth References: <20041211014613.GK695@hsc.fr> <41BA61C6.9080903@centtech.com> <20041211092048.GA15338@droopy.unibe.ch> In-Reply-To: <20041211092048.GA15338@droopy.unibe.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: suspend status 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, 11 Dec 2004 19:40:25 -0000 Tobias Roth wrote: > On Fri, Dec 10, 2004 at 08:56:06PM -0600, Eric Anderson wrote: > >>Refigure your math - if 100% cpu means 3hrs 18 minutes of runtime left, >>then that about 200 minutes of runtime. So 1% equals 2 minutes of >>runtime roughly. So, you suspend - and wait up 90 minutes later. If it >>would have been running like normal, it would eat up 1% per 2 minutes, >>so about 45% of your battery - but it didn't, it only ate up 20%. So >>ath that rate, it was using less than half the power as when in >>non-suspend mode. > > how long would the same laptop/battery survive when suspended from > windows? i always had in mind that a suspended laptop is supposed to > live for more than a day, which clearly is not the case in your example. > > you often hear comparisons here about how much less battery windows uses > when compared to FreeBSD (or rather, how much better windows battery > saving techniques are). detailed comparisons of bsd <-> linux <-> windows > with good guesses of why the discrepancies are there would help. > > i am just trying to say that battery saving in suspend probably IS bad > in FreeBSD (as compared to the possible optimum, as windows shows it). > it's not just bad math in the above example. I'd like it if people took the time to compare various features on windows/linux/freebsd including average temp during your normal use, battery usage, etc. Both my ThinkPads last a very long time in S3 (weeks). However, I think BIOS code handles most of the system power issues which may hide things that the OS doesn't do as well. If a single device driver doesn't properly power down a device, it may be the culprit. Such problems are hard to find, obviously. I do know that some display adapters need more magic than X is currently using. Also, bms@ pointed out that we possibly need to hook X into suspend/resume more. I started some patches for that (on my web page) but didn't get very far since I don't know the X server code and it wasn't clear that the module in question (bsd_apm) is even compiled on FreeBSD. The other thing you can try is my suspend power patch (committed in -current, patch posted recently here for 5.x). It may help since it explicitly powers down/up acpi and pci devices in suspend. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 19:43:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E129E16A4CE for ; Sat, 11 Dec 2004 19:43:04 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9742743D5A for ; Sat, 11 Dec 2004 19:43:04 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123])iBBJh9sV014851; Sat, 11 Dec 2004 14:43:09 -0500 Message-ID: <41BB4DC4.6090901@root.org> Date: Sat, 11 Dec 2004 11:43:00 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Partola References: <41BA85A0.3050206@pisem.net> In-Reply-To: <41BA85A0.3050206@pisem.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Dell Inspiron 8600 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, 11 Dec 2004 19:43:05 -0000 Igor Partola wrote: > Ulrich Spoerlein wrote: > >> I also added this, which turns off the LCD when pressing suspend: >> notify 10 { >> match "system" "ACPI"; >> match "subsystem" "Button"; >> match "notify" "0x01"; >> action "/sbin/sysctl hw.acpi.video.lcd0.active=0"; >> }; >> >> Turning the LCD back on, when resuming, needs to be done manually. I >> think /etc/rc.{suspend,resume} is a better place for this. >> >> > This does indeed work (just like the lid switch thing), thank you. One > problem though is that > rc.resume is not read in all cases. While acpiconf honors it, just > hitting the suspend button and > resuming (hitting the power button) does not turn the lcd back on. Is > there a way to fix this? Yes, this is a deficiency in the current usermode interface. If you look at my web page, I have a description of how to fix this if someone wants to do it. It includes implementing the /dev/apm suspend/standby compatibility ioctls including a timeout interface. See the "Implement X suspend/resume notification" section below. http://www.root.org/~nate/freebsd/acpi-todo.html -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 19:58:03 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94C9C16A4CE for ; Sat, 11 Dec 2004 19:58:03 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30A0D43D2D for ; Sat, 11 Dec 2004 19:58:03 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123])iBBJvxo1014116; Sat, 11 Dec 2004 14:57:59 -0500 Message-ID: <41BB5146.1080102@root.org> Date: Sat, 11 Dec 2004 11:57:58 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> <41B76AF2.3040204@root.org> <20041210180446.GA768@galgenberg.net> <41B9EE4E.8030703@root.org> <20041210205417.GB768@galgenberg.net> In-Reply-To: <20041210205417.GB768@galgenberg.net> Content-Type: multipart/mixed; boundary="------------040503080904080909030402" cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 11 Dec 2004 19:58:03 -0000 This is a multi-part message in MIME format. --------------040503080904080909030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ulrich Spoerlein wrote: > On Fri, 10.12.2004 at 10:43:26 -0800, Nate Lawson wrote: > >>>Line 444 is the culprit: >>> ACPI_FLUSH_CPU_CACHE (); >>> >>> Status = AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK, >>> ACPI_REGISTER_PM1A_CONTROL, PM1AControl); >>> if (ACPI_FAILURE (Status)) >>> { >>> return_ACPI_STATUS (Status); >>> } >>> >>>Putting the loop before AcpiHwRegisterWrite will enter infinite loop, >>>putting it after it -> Reset >> >>Interesting. If you add a "DELAY(10000);" before the register write, >>does this help? A more likely issue is that we need to write pm1a/b at >>the same time. Let me think about this and get you more info later. > > > It "looks" like the delay does nothing, however I noticed that all three > LEDs (num/scroll/caps lock) were lighting up for 1-2s. > > I then swapped pm1a and pm1b, but nothing changed. That's not quite what I meant. The acpi-ca code splits the write of SLP_TYP and SLP_EN into two separate writes. I suspect some BIOSes don't like this. Try the attached patch that combines them. -- Nate --------------040503080904080909030402 Content-Type: text/plain; name="sleep_split.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sleep_split.diff" Index: sys/contrib/dev/acpica/hwsleep.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/dev/acpica/hwsleep.c,v retrieving revision 1.18 diff -u -r1.18 hwsleep.c --- sys/contrib/dev/acpica/hwsleep.c 1 Dec 2004 23:40:48 -0000 1.18 +++ sys/contrib/dev/acpica/hwsleep.c 11 Dec 2004 02:23:18 -0000 @@ -420,6 +420,7 @@ /* Write #1: fill in SLP_TYP data */ +#if 0 Status = AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK, ACPI_REGISTER_PM1A_CONTROL, PM1AControl); if (ACPI_FAILURE (Status)) { @@ -431,6 +432,7 @@ { return_ACPI_STATUS (Status); } +#endif /* Insert SLP_ENABLE bit */ --------------040503080904080909030402-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 22:08:06 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 613DB16A4CE for ; Sat, 11 Dec 2004 22:08:06 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB6D143D48 for ; Sat, 11 Dec 2004 22:08:05 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id 80EB1DD368; Sat, 11 Dec 2004 23:08:04 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 67E1988BE1; Sat, 11 Dec 2004 23:08:04 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 4C2CC7B810; Sat, 11 Dec 2004 23:08:04 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id BD9B3D452D; Sat, 11 Dec 2004 23:08:03 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id iBBM83tm045085; Sat, 11 Dec 2004 23:08:03 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id iBBM83gx000760; Sat, 11 Dec 2004 23:08:03 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id iBBM82XD000759; Sat, 11 Dec 2004 23:08:02 +0100 (CET) (envelope-from q@uni.de) Date: Sat, 11 Dec 2004 23:08:02 +0100 From: Ulrich Spoerlein To: Nate Lawson Message-ID: <20041211220802.GA748@galgenberg.net> References: <41B4E577.9060502@root.org> <41B50754.10604@centtech.com> <41B50C12.6070103@root.org> <20041208095845.GA896@galgenberg.net> <41B76AF2.3040204@root.org> <20041210180446.GA768@galgenberg.net> <41B9EE4E.8030703@root.org> <20041210205417.GB768@galgenberg.net> <41BB5146.1080102@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <41BB5146.1080102@root.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: acpi@FreeBSD.org Subject: Re: suspend/resume improved? 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, 11 Dec 2004 22:08:06 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 11.12.2004 at 11:57:58 -0800, Nate Lawson wrote: > That's not quite what I meant. The acpi-ca code splits the write of=20 > SLP_TYP and SLP_EN into two separate writes. I suspect some BIOSes=20 > don't like this. Try the attached patch that combines them. Sorry, no luck. Still resets after the pm1a write. Is there some quick way to emit beeps via the speaker in that codepath? Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBu2/CmArGtfDbn0QRAjXeAJsEt4zzetYyHXQkEmcL3gS0SNBEsACgxjnh +x9CcitdtG6HbYR/TEXhCGw= =vJBa -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 22:30:13 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37DFF16A4CE for ; Sat, 11 Dec 2004 22:30:13 +0000 (GMT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id AED1143D1D for ; Sat, 11 Dec 2004 22:30:12 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([141.150.86.23]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041211223011.UHVY4717.out011.verizon.net@RabbitsDen> for ; Sat, 11 Dec 2004 16:30:11 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=iso-8859-5 Date: Sat, 11 Dec 2004 17:29:10 -0500 Message-Id: <1102804150.2640.4.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [141.150.86.23] at Sat, 11 Dec 2004 16:30:11 -0600 Subject: Keeping PCMCIA card powered while in S3 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, 11 Dec 2004 22:30:13 -0000 Good people, is there any chance to keep PCMCIA firewire card powered when machine goes into S3 mode, or at least push poweroff as far as possible. The reason for the question is that I am trying to debug S3 mode and do not have any other usable means on this laptop. Any suggestions, especially RTFMs with FM pointers are welcome. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 11 23:34:20 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07EE516A4CE for ; Sat, 11 Dec 2004 23:34:20 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id B91AB43D2D for ; Sat, 11 Dec 2004 23:34:19 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123])iBBNYTY9021512; Sat, 11 Dec 2004 18:34:29 -0500 Message-ID: <41BB83F6.4010309@root.org> Date: Sat, 11 Dec 2004 15:34:14 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <1102804150.2640.4.camel@RabbitsDen> In-Reply-To: <1102804150.2640.4.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-5; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Keeping PCMCIA card powered while in S3 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, 11 Dec 2004 23:34:20 -0000 Alexandre "Sunny" Kovalenko wrote: > Good people, > > is there any chance to keep PCMCIA firewire card powered when machine > goes into S3 mode, or at least push poweroff as far as possible. The > reason for the question is that I am trying to debug S3 mode and do not > have any other usable means on this laptop. > > Any suggestions, especially RTFMs with FM pointers are welcome. > We currently don't power down cardbus (PCMCIA) busses but we do power down the card itself. Setting hw.pci.do_powerstate=0 before suspending (or in /boot/loader.conf) should stop all PCI power state setting (including cardbus which is just another pci-like bridge). -- Nate