From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 1 11:49:14 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3C5816A418; Tue, 1 Jan 2008 11:49:13 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CC5C613C43E; Tue, 1 Jan 2008 11:49:13 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m01BnDuH042938; Tue, 1 Jan 2008 11:49:13 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m01BnDcW042934; Tue, 1 Jan 2008 11:49:13 GMT (envelope-from remko) Date: Tue, 1 Jan 2008 11:49:13 GMT Message-Id: <200801011149.m01BnDcW042934@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/119200: [acpi] Lid close switch suspends CPU for 1 second on HP nx6125 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 11:49:14 -0000 Synopsis: [acpi] Lid close switch suspends CPU for 1 second on HP nx6125 Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Tue Jan 1 11:49:06 UTC 2008 Responsible-Changed-Why: reassign to acpi team http://www.freebsd.org/cgi/query-pr.cgi?pr=119200 From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 01:16:29 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40CA616A41A for ; Fri, 4 Jan 2008 01:16:29 +0000 (UTC) (envelope-from beto@octantis.com.au) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id D8FBF13C442 for ; Fri, 4 Jan 2008 01:16:28 +0000 (UTC) (envelope-from beto@octantis.com.au) Received: (qmail 9823 invoked from network); 3 Jan 2008 19:09:48 -0600 Received: from 124-170-189-12.dyn.iinet.net.au (HELO localhost) (124.170.189.12) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jan 2008 19:09:47 -0600 Date: Fri, 4 Jan 2008 12:09:07 +1100 From: Norberto Meijome Message-ID: <20080104120907.35fbb91e@octantis.com.au> In-Reply-To: References: <200712271449.58285.jhb@freebsd.org> Organization: Octantis Pty Ltd X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, njl@freebsd.org Subject: Re: An issue with powerd.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:16:29 -0000 On Fri, 28 Dec 2007 13:38:13 +1100 (EST) Ian Smith wrote: > On Thu, 27 Dec 2007, John Baldwin wrote: [...] Hi there :) > > It was also far worse in console mode than in X. In console mode I found that > > sometimes the system would never "come back". > > Presumably X itself keeps it busy enough to keep cpu freq 'reasonable'? > I use gkrellm to keep an eye on cpu freq, temp, load avg .. but my T23 > is only a two-speed, min 733MHZ, so I can't see what you're seeing (and > that's my faster laptop :) hmm not necessarily - all my problems I had with temperature going up and powerd slowing down the CPU to 100 Mhz were under X. again, the heat issue may had overriden the 'need for speed'.... > > > So I was running in console mode recently with my timing patches and noticed > > that when it hung it started warning about GPE events taking several > > _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ seconds. > > So, my theory is that powerd has lowered my CPU all the way down to 100mhz > > (easy to reproduce in non-X, just let the box sit with no apps running) and > > that for some reason the machine ends up in a "GPE storm" where it is > > spending all its time handling GPE's and never has any CPU left for userland > > apps (due to being at 100mhz). The problem then is that powerd never runs to > > bump my CPU up to some reasonable speed. > > One workaround some have noted using is to set debug.cpufreq.lowest to > some value considerably higher than 100MHz, say >500MHz to maintain > reasonable responsiveness, at a cost of higher power use when idle. yes - the only way I could get my machine to work OKish is to set cpufreq.lowest to 932 Mhz. > > > In fact, anytime a completely idle box suddently gets a lot of kernel work > > (e.g. a sudden flow of packets) it could in theory end up trying to handle > > all this work at the reduced speed since the work has a higher priority than > > the powerd process. To that end, I think that at least part of powerd needs > > to be in the kernel, or at least that the kernel should be more proactive > > about bumping the speed up when it resumes from Cx due to an interrupt. A > > simple policy would be to bump up to full speed for any non-clock interrupt > > (possibly bumping up for a clock interrupt if we wake up softclock as well). > > > > Thoughts? > > Just humble grasshopper droppings, master .. but the default powerd > polling interval is 500ms, which is a really long time on a fast box, so > -p 100 or even less might make a considerable difference? giving -p 100 a try now. > > Can't comment on any in-kernel component, but responding per any sort of > single interrupt/s sounds way too triggerhappy compared to monitoring > load, assuming that such as vm.loadavg and kern.cp_time are themselves > updated promptly in high-stress times? > > AU$0.02, which rounds down to 0 since we abandoned coins less than 5c .. LOL - good point! cheers, B _________________________ Norberto Meijome Octantis Pty Ltd Exhilaration is that feeling you get just after a great idea hits you, and just before you realize what is wrong with it. NOTICE: The contents of this email and its attachments are confidential and intended only for the individuals or entities named above. If you have received this message in error, please advise the sender by reply email and immediately delete the message and any attachments without using, copying or disclosing the contents. Thank you. From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 01:29:31 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512C116A41A for ; Fri, 4 Jan 2008 01:29:31 +0000 (UTC) (envelope-from beto@octantis.com.au) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id ECCE613C4D1 for ; Fri, 4 Jan 2008 01:29:30 +0000 (UTC) (envelope-from beto@octantis.com.au) Received: (qmail 9224 invoked from network); 3 Jan 2008 19:02:49 -0600 Received: from 124-170-189-12.dyn.iinet.net.au (HELO localhost) (124.170.189.12) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jan 2008 19:02:49 -0600 Date: Fri, 4 Jan 2008 12:02:08 +1100 From: Norberto Meijome Message-ID: <20080104120208.40c4fbfe@octantis.com.au> In-Reply-To: <20071230105141.GA5825@tirith.brixandersen.dk> References: <200712291624.lBTGOiI1002329@aldan.algebra.com> <20071230105141.GA5825@tirith.brixandersen.dk> Organization: Octantis Pty Ltd X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: acpi@FreeBSD.org, questions@FreeBSD.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:29:31 -0000 On Sun, 30 Dec 2007 11:51:41 +0100 Henrik Brix Andersen wrote: > That depends largely on the hardware - on e.g. ThinkPads you need to > press the 'Fn' button to wake up the laptop after sleep. hmm i think it's not so much the Fn key, u need to do anything that triggers an ACPI event in the BIOS - like opening the lid , or pressing Fn. I *think* 'thinkVantage' blue btn should work too. _________________________ Norberto Meijome Octantis Pty Ltd "I'm not afraid of dying, I just don't want to be there when it happens." Woody Allen NOTICE: The contents of this email and its attachments are confidential and intended only for the individuals or entities named above. If you have received this message in error, please advise the sender by reply email and immediately delete the message and any attachments without using, copying or disclosing the contents. Thank you. From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 02:01:51 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4461816A417 for ; Fri, 4 Jan 2008 02:01:51 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id EB5FB13C45D for ; Fri, 4 Jan 2008 02:01:50 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 12375 invoked from network); 3 Jan 2008 19:35:09 -0600 Received: from 124-170-189-12.dyn.iinet.net.au (HELO localhost) (124.170.189.12) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jan 2008 19:35:08 -0600 Date: Fri, 4 Jan 2008 12:34:28 +1100 From: Norberto Meijome Message-ID: <20080104123428.3292da81@meijome.net> In-Reply-To: <20071230105141.GA5825@tirith.brixandersen.dk> References: <200712291624.lBTGOiI1002329@aldan.algebra.com> <20071230105141.GA5825@tirith.brixandersen.dk> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: acpi@FreeBSD.org, questions@FreeBSD.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:01:51 -0000 On Sun, 30 Dec 2007 11:51:41 +0100 Henrik Brix Andersen wrote: > That depends largely on the hardware - on e.g. ThinkPads you need to > press the 'Fn' button to wake up the laptop after sleep. hmm i think it's not so much the Fn key, u need to do anything that triggers an ACPI event in the BIOS - like opening the lid , or pressing Fn. I *think* 'thinkVantage' blue btn should work too. _________________________ {Beto|Norberto|Numard} Meijome "Discovery consists of looking at the same thing as everyone else does and thinking something different." Albert Szent-Gyorgyi, 1937 Nobel Prize in Physiology and Medicine I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 08:13:31 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51C416A41B for ; Fri, 4 Jan 2008 08:13:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 87EAE13C448 for ; Fri, 4 Jan 2008 08:13:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id TAA27593; Fri, 4 Jan 2008 19:13:21 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 4 Jan 2008 19:13:20 +1100 (EST) From: Ian Smith To: Norberto Meijome In-Reply-To: <20080104123428.3292da81@meijome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, questions@freebsd.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 08:13:31 -0000 On Fri, 4 Jan 2008, Norberto Meijome wrote: > On Sun, 30 Dec 2007 11:51:41 +0100 > Henrik Brix Andersen wrote: > > > That depends largely on the hardware - on e.g. ThinkPads you need to > > press the 'Fn' button to wake up the laptop after sleep. > > hmm i think it's not so much the Fn key, u need to do anything that > triggers an ACPI event in the BIOS - like opening the lid , or > pressing Fn. I *think* 'thinkVantage' blue btn should work too. On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to have to use the Fn key to wake. No other keys do that on mine including the ThinkPad key, so then called. While consulting 'sysctl hw.acpi' about that I see: hw.acpi.lid_switch_state: NONE which I assume reflects my don't-do-that BIOS setting. And confirming: # sysctl hw.acpi.lid_switch_state=1 # (or =0) hw.acpi.lid_switch_state: NONE sysctl: hw.acpi.lid_switch_state: Invalid argument which makes sense and was expected .. except that since doing that, closing the lid while awake still just blanks screen, but opening lid now wakes the laptop from sleep! No big deal, just slightly odd .. Cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 09:12:25 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F9EA16A41B for ; Fri, 4 Jan 2008 09:12:25 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 29B8913C469 for ; Fri, 4 Jan 2008 09:12:25 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 18404 invoked from network); 4 Jan 2008 03:12:24 -0600 Received: from 124-170-189-12.dyn.iinet.net.au (HELO localhost) (124.170.189.12) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2008 03:12:24 -0600 Date: Fri, 4 Jan 2008 20:11:42 +1100 From: Norberto Meijome To: Ian Smith Message-ID: <20080104201142.7bc73059@meijome.net> In-Reply-To: References: <20080104123428.3292da81@meijome.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, questions@freebsd.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 09:12:25 -0000 On Fri, 4 Jan 2008 19:13:20 +1100 (EST) Ian Smith wrote: > On Fri, 4 Jan 2008, Norberto Meijome wrote: > > On Sun, 30 Dec 2007 11:51:41 +0100 > > Henrik Brix Andersen wrote: > > > > > That depends largely on the hardware - on e.g. ThinkPads you need to > > > press the 'Fn' button to wake up the laptop after sleep. > > > > hmm i think it's not so much the Fn key, u need to do anything that > > triggers an ACPI event in the BIOS - like opening the lid , or > > pressing Fn. I *think* 'thinkVantage' blue btn should work too. > > On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to > have to use the Fn key to wake. No other keys do that on mine including > the ThinkPad key, so then called. ah yes :) > > While consulting 'sysctl hw.acpi' about that I see: > hw.acpi.lid_switch_state: NONE > which I assume reflects my don't-do-that BIOS setting. > > And confirming: > # sysctl hw.acpi.lid_switch_state=1 # (or =0) > hw.acpi.lid_switch_state: NONE > sysctl: hw.acpi.lid_switch_state: Invalid argument > > which makes sense and was expected .. except that since doing that, > closing the lid while awake still just blanks screen, but opening lid > now wakes the laptop from sleep! No big deal, just slightly odd .. hmm mine reads : hw.acpi.lid_switch_state: NONE dev.acpi_lid.0.wake: 1 FreeBSD ayiin.octantis.com.au 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Fri Jan 4 09:44:17 EST 2008 root@ayiin.octantis.com.au:/usr/obj/usr/src/sys/GENERIC i386 _________________________ {Beto|Norberto|Numard} Meijome "Great spirits have often encountered violent opposition from mediocre minds." Albert Einstein I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 13:22:15 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD71E16A46E; Fri, 4 Jan 2008 13:22:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED4913C461; Fri, 4 Jan 2008 13:22:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id AAA06024; Sat, 5 Jan 2008 00:22:06 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 5 Jan 2008 00:22:05 +1100 (EST) From: Ian Smith To: Norberto Meijome In-Reply-To: <20080104201142.7bc73059@meijome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, questions@freebsd.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:22:16 -0000 On Fri, 4 Jan 2008, Norberto Meijome wrote: > On Fri, 4 Jan 2008 19:13:20 +1100 (EST) > Ian Smith wrote: [..] > > On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to > > have to use the Fn key to wake. No other keys do that on mine including > > the ThinkPad key, so then called. > > ah yes :) > > > > > While consulting 'sysctl hw.acpi' about that I see: > > hw.acpi.lid_switch_state: NONE > > which I assume reflects my don't-do-that BIOS setting. > > > > And confirming: > > # sysctl hw.acpi.lid_switch_state=1 # (or =0) > > hw.acpi.lid_switch_state: NONE > > sysctl: hw.acpi.lid_switch_state: Invalid argument > > > > which makes sense and was expected .. except that since doing that, > > closing the lid while awake still just blanks screen, but opening lid > > now wakes the laptop from sleep! No big deal, just slightly odd .. > > hmm mine reads : > > hw.acpi.lid_switch_state: NONE > > dev.acpi_lid.0.wake: 1 Sorry Beto, I must have been dreaming :) I have that too, but did try 'sysctl dev.acpi_lid.0.wake=0'. With that, no keys at all but only pressing the power button (not for too long!) will wake it up (phew). Anyway, after a reboot - having noticed that since my verbose boot the other day, each ACPI suspend/resume is VERY chatty in messages - it's still working the same. So eat this message .. > FreeBSD ayiin.octantis.com.au 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE > #1: Fri Jan 4 09:44:17 EST 2008 > root@ayiin.octantis.com.au:/usr/obj/usr/src/sys/GENERIC i386 Happy new job .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 14:55:51 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1D616A41B for ; Fri, 4 Jan 2008 14:55:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8005413C45A for ; Fri, 4 Jan 2008 14:55:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id BAA08964; Sat, 5 Jan 2008 01:55:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 5 Jan 2008 01:55:26 +1100 (EST) From: Ian Smith To: Rui Paulo In-Reply-To: <86ejdaepm9.wl%rpaulo@fnop.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:55:51 -0000 On Tue, 25 Dec 2007, Rui Paulo wrote: > At Tue, 25 Dec 2007 17:16:58 +1100 (EST), > Ian Smith wrote: > > > > On Mon, 24 Dec 2007, Rui Paulo wrote: > > > At Mon, 24 Dec 2007 23:16:54 +0200, > > > Aragon Gouveia wrote: > > > > > > > > Hi, > > > > > > > > | By Rui Paulo > > > > | [ 2007-12-24 14:43 +0200 ] > > > > > Isn't it better to teach est(4) to ignore values that differ in, say, > > > > > +/- 5Mhz ? > > > > > > > > I agree my patch isn't ideal. I was thinking about it today and it might > > > > be useful to implement something that ignores frequencies whose power > > > > ratings don't differ by more than X mW. In my case, both 2201 and 2200 are > > > > rated to draw 35000 mW. The question is, in these cases which one of the > > > > two should be ignored? Can't ignore both... > > > > > > I think you can ignore one of them, which one doesn't really matter > > > because the power levels are the same. I suspect that, in these cases, > > > the 2001 comes after 2000 in the EST table, so if we ignore a value > > > already present, 2000 will remain and 2001 will be ignored. > > > > I'm starting to wonder if this 2000/2001 thing isn't some sort of signal > > to a Certain OS to do Something Proprietary. As it makes no engineering > > sense, best we can do for powerd without Inside Knowledge is what both > > these patches offer, eliminating/ignoring frequencies that won't set. > > > > It seems it does matter which is chosen; Andrey demonstrated in his case > > that setting 2000 gave 2001 anyway, so the one that reads back wrong > > when set is the one to ignore. It'd be better to know _why_, > > though. > > Well, the fact that "setting 2000 gave 2001 anyway" is most likely > regarding to how est is programmed, I think. Are we certain yet that this (apparently recent) 2001|2000 or 2201|2200 freq phenomenon only appears on hardware that uses est specifically? Trying to marginally reduce my ignorance I've done a bit of digging, not necessarily in this order .. % find /sys/ -name "*.[ch]" -exec egrep -Hi 'CPUFREQ_[GS]ET' {} \; /sys/kern/kern_cpu.c:static int cpufreq_settings_sysctl(SYSCTL_HANDLER_ARGS); /sys/kern/kern_cpu.c: DEVMETHOD(cpufreq_set, cf_set_method), /sys/kern/kern_cpu.c: DEVMETHOD(cpufreq_get, cf_get_method), /sys/kern/kern_cpu.c: error = CPUFREQ_GET(sc->dev, &levels[0]); /sys/kern/kern_cpu.c: * While we only call cpufreq_get() on one device (assuming all /sys/kern/kern_cpu.c: * CPUs have equal levels), we call cpufreq_set() on all CPUs. /sys/kern/kern_cpu.c: error = CPUFREQ_SET(devs[n], &levels[i], /sys/kern/kern_cpu.c:cpufreq_settings_sysctl(SYSCTL_HANDLER_ARGS) /sys/kern/kern_cpu.c: cpufreq_settings_sysctl, "A", "CPU frequency driver settings"); /sys/sys/cpu.h: * is registered, it must support calls to its CPUFREQ_GET, CPUFREQ_GET_LEVEL, /sys/sys/cpu.h: * and CPUFREQ_SET methods. It must also unregister before returning from So this seems where the main business is done. Up till then I'd been hunting through just /sys/dev/acpica/* and /sys/i386/cpufreq/* so this alone was a useful revelation. From that hunt derives this fat list: % find /sys/ -name "*.[ch]" -exec grep -Hi CPUFREQ_ {} \; and from there, it seems that only est.c does not use CPUFREQ_CMP(): % find /sys/ -name "*.[ch]" -exec grep -H CPUFREQ_CMP {} \; /sys/dev/acpica/acpi_perf.c: if (CPUFREQ_CMP(set->freq, sc->px_states[i].core_freq)) /sys/dev/acpica/acpi_perf.c: if (CPUFREQ_CMP(sc->px_states[i].core_freq, rate)) { /sys/dev/cpufreq/ichss.c: if (CPUFREQ_CMP(set->freq, sc->sets[0].freq)) /sys/dev/cpufreq/ichss.c: else if (CPUFREQ_CMP(set->freq, sc->sets[1].freq)) /sys/i386/cpufreq/powernow.c: if (CPUFREQ_CMP(sc->powernow_states[i].freq / 1000, cf->freq)) /sys/i386/cpufreq/smist.c: if (CPUFREQ_CMP(set->freq, sc->sets[0].freq)) /sys/i386/cpufreq/smist.c: else if (CPUFREQ_CMP(set->freq, sc->sets[1].freq)) /sys/kern/kern_cpu.c: if (CPUFREQ_CMP(sc->curr_level.total_set.freq, level->total_set.freq)) { /sys/kern/kern_cpu.c: if (CPUFREQ_CMP(set.freq, levels[i].total_set.freq)) { /sys/kern/kern_cpu.c: if (CPUFREQ_CMP(rate, levels[i].total_set.freq)) { /sys/kern/kern_cpu.c: if (CPUFREQ_CMP(fill_set->freq, itr_set->freq)) { /sys/kern/kern_cpu.c: if (CPUFREQ_CMP(levels[i].total_set.freq, freq)) { /sys/sys/cpu.h:#define CPUFREQ_CMP(x, y) (abs((x) - (y)) < 25) So the finest granularity in differing freqs is 25. (caveat: 5.5-STABLE sources from months ago, but I did check cpu.h on HEAD still has that) It's not yet clear to me, due to my generally meagre knowledge of C in general and method passing, softc, callbacks and such in particular, whether est's get/set calls override or assist what kern_cpu.c is up to? Cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 15:43:25 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6719316A469; Fri, 4 Jan 2008 15:43:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id D932013C447; Fri, 4 Jan 2008 15:43:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227269487-1834499 for multiple; Fri, 04 Jan 2008 10:41:32 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m04FhLSj039965; Fri, 4 Jan 2008 10:43:21 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 4 Jan 2008 10:12:24 -0500 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041012.25643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Jan 2008 10:43:21 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 08:37:27 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: acpi@freebsd.org, questions@freebsd.org, Ian Smith Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 15:43:25 -0000 On Friday 04 January 2008 03:13:20 am Ian Smith wrote: > On Fri, 4 Jan 2008, Norberto Meijome wrote: > > On Sun, 30 Dec 2007 11:51:41 +0100 > > Henrik Brix Andersen wrote: > > > > > That depends largely on the hardware - on e.g. ThinkPads you need to > > > press the 'Fn' button to wake up the laptop after sleep. > > > > hmm i think it's not so much the Fn key, u need to do anything that > > triggers an ACPI event in the BIOS - like opening the lid , or > > pressing Fn. I *think* 'thinkVantage' blue btn should work too. > > On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to > have to use the Fn key to wake. No other keys do that on mine including > the ThinkPad key, so then called. > > While consulting 'sysctl hw.acpi' about that I see: > hw.acpi.lid_switch_state: NONE > which I assume reflects my don't-do-that BIOS setting. No, that's the FreeBSD default. > And confirming: > # sysctl hw.acpi.lid_switch_state=1 # (or =0) > hw.acpi.lid_switch_state: NONE > sysctl: hw.acpi.lid_switch_state: Invalid argument This is because this sysctl is not an on/off, but it takes an Sx state to suspend to when you close the lid. So if you set this to S1 it will try to enter S1 when you close the lid, etc. For example: sysctl hw.acpi.lid_switch_state=S3 Would make it enter S3 when you closed the lid. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 4 15:43:25 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6719316A469; Fri, 4 Jan 2008 15:43:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id D932013C447; Fri, 4 Jan 2008 15:43:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227269487-1834499 for multiple; Fri, 04 Jan 2008 10:41:32 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m04FhLSj039965; Fri, 4 Jan 2008 10:43:21 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 4 Jan 2008 10:12:24 -0500 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041012.25643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Jan 2008 10:43:21 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 08:37:27 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: acpi@freebsd.org, questions@freebsd.org, Ian Smith Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 15:43:25 -0000 On Friday 04 January 2008 03:13:20 am Ian Smith wrote: > On Fri, 4 Jan 2008, Norberto Meijome wrote: > > On Sun, 30 Dec 2007 11:51:41 +0100 > > Henrik Brix Andersen wrote: > > > > > That depends largely on the hardware - on e.g. ThinkPads you need to > > > press the 'Fn' button to wake up the laptop after sleep. > > > > hmm i think it's not so much the Fn key, u need to do anything that > > triggers an ACPI event in the BIOS - like opening the lid , or > > pressing Fn. I *think* 'thinkVantage' blue btn should work too. > > On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to > have to use the Fn key to wake. No other keys do that on mine including > the ThinkPad key, so then called. > > While consulting 'sysctl hw.acpi' about that I see: > hw.acpi.lid_switch_state: NONE > which I assume reflects my don't-do-that BIOS setting. No, that's the FreeBSD default. > And confirming: > # sysctl hw.acpi.lid_switch_state=1 # (or =0) > hw.acpi.lid_switch_state: NONE > sysctl: hw.acpi.lid_switch_state: Invalid argument This is because this sysctl is not an on/off, but it takes an Sx state to suspend to when you close the lid. So if you set this to S1 it will try to enter S1 when you close the lid, etc. For example: sysctl hw.acpi.lid_switch_state=S3 Would make it enter S3 when you closed the lid. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 5 03:18:24 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16C7116A46D for ; Sat, 5 Jan 2008 03:18:24 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp11.mail.ogk.yahoo.co.jp (ybbsmtp11.mail.ogk.yahoo.co.jp [124.83.153.131]) by mx1.freebsd.org (Postfix) with SMTP id 927E113C458 for ; Sat, 5 Jan 2008 03:18:23 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 62903 invoked by alias); 5 Jan 2008 02:51:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; h=Received:X-Apparently-From:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=X7NlRkiW0kAYrfCF7Zoiity7YfQC+dy2pjJBGImPWWeHkUsmYCeKQLr4DIooz0tkF1He2BlbD4Vw/fc6U7jEi9i/XKykoWPyyGAzK4JFYunLBY/Fn43QKKHGPdf2m60Q ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp11.mail.ogk.yahoo.co.jp with SMTP; 5 Jan 2008 02:51:41 -0000 X-Apparently-From: Message-ID: <477EF09E.60606@ybb.ne.jp> Date: Sat, 05 Jan 2008 11:51:10 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Andrey References: <476E8674.5000303@gmail.com> In-Reply-To: <476E8674.5000303@gmail.com> Content-Type: multipart/mixed; boundary="------------030908000301020908020206" Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 03:18:24 -0000 This is a multi-part message in MIME format. --------------030908000301020908020206 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hi, I met same problem on my Panasonic CF-R7 note book PC. As far as I investigate, cpufreq(est driver) does not check setting values for PERFCTL register which are reported from acpi_perf driver. According to comments in sys/i386/cpufreq/est.c, the auther of the driver regards this as TODO thing (see following lines.). -- sys/i386/cpufreq/est.c for (i = 0; i < count; i++) { /* * TODO: Figure out validity checks for id16. Linux checks * that the control and status values match. */ -- I wrote the patch to check id16 values as comments says. As far as I test the patch, the patch fixes the problem. Would you try this patch? P.S. I've send-pr this problem with this patch in this morning(kern/119350). Andrey wrote: > Good time of the day. > > I've noticed that powerd isn't able to decrease CPU frequency on my > laptop (HP Compaq 6710b) as soon as frequency gets highest level. > > I've pottered a bit in the sources and it seems found the root of the > issue. > So those who are interested in the subject let consider it. > > For instance my system reports the following frequency levels: > > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2001/35000 2000/35000 1750/30625 1600/25000 > 1400/21875 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 > 500/8750 400/7000 300/5250 > > If I try to adjust current frequency to 2000 MHz then I'll get: > [silent@beastie][/home/silent]sudo sysctl dev.cpu.0.freq=2000 > dev.cpu.0.freq: 300 -> 2001 > Let check: > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2001 > > Thus, as you can see, I have level "2000" which system reports me but > actually I can't to adjust those one exactly because it silently becomes > "2001" > > Well... If I'm not mistaken powerd calculates the current "CPU idle > mark" and if it is more then adopted value (by default 90%) then it > shifts CPU frequency value 1 step down. In my case powerd sticks at > "2001". It is obvious because when powerd decreases CPU frequency from > the highest frequency level we'll get the following scenario: > > +-----------------------+ > | dev.cpu.0.freq=2001 +--<-+ > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | "CPU idle" > 90% | | > +-----------+-----------+ | > | | > Y ^ > +-----------+-----------+ ^ > | powerd shifts freq. | ^ > | 1 step down: | | > | "2001" -> "2000" | | > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | actually we have here | | > | dev.cpu.0.freq == 2001+-->-+ > +-----------------------+ > > > According to the things mentioned above I've came to conclusion that in > my case it is not a good idea to rely on frequency levels reported by > the system. (Also I saw many sysctl mibs (dev.cpu.0.freq) of many other > people. And there were "strange" frequency levels like "2000" and > "2001". Of course I can't state that their systems' behaviors fit my > case. But still...) > > So the simple way out I see is to teach powerd recognize "fake" > frequency levels. Here I suggest a very simple workaround (and may be > quite ugly... sorry I'm not sure if it is my cup of tee) which allows me > to overcome the issue. And I hope it can be useful for smb. else. > > Also I'd like to hear opinions of others. May be there exists another > and simpler way to overcome an issue or even I've missed something or > not aware of something. > > > Thank you. > > > -- > Sincerely, > Andrey Kosachenko > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------030908000301020908020206 Content-Type: text/plain; name="est-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="est-fix.patch" --- sys.orig/i386/cpufreq/est.c 2006-05-11 17:35:44.000000000 +0000 +++ sys/i386/cpufreq/est.c 2008-01-05 10:56:14.435882213 +0000 @@ -902,6 +902,8 @@ static int est_set(device_t dev, const struct cf_setting *set); static int est_get(device_t dev, struct cf_setting *set); static int est_type(device_t dev, int *type); +static int est_set_id16(uint16_t id16, int need_check); +static void est_get_id16(uint16_t *id16_p); static device_method_t est_methods[] = { /* Device interface */ @@ -1068,7 +1070,6 @@ return (0); } - static int est_acpi_info(device_t dev, freq_info **freqs) { @@ -1076,7 +1077,8 @@ struct cf_setting *sets; freq_info *table; device_t perf_dev; - int count, error, i; + int count, error, i, idx; + uint16_t saved_id16; perf_dev = device_find_child(device_get_parent(dev), "acpi_perf", -1); if (perf_dev == NULL || !device_is_attached(perf_dev)) @@ -1098,19 +1100,38 @@ error = ENOMEM; goto out; } - for (i = 0; i < count; i++) { + for (i = 0, idx = 0; i < count; i++) { /* - * TODO: Figure out validity checks for id16. Linux checks - * that the control and status values match. + * Confirm id16 value is correct. */ - table[i].freq = sets[i].freq; - table[i].volts = sets[i].volts; - table[i].id16 = sets[i].spec[0]; - table[i].power = sets[i].power; + if (sets[i].freq > 0) { + + /* save current value */ + est_get_id16(&saved_id16); + + /* + * Try to set specified value + */ + error = est_set_id16(sets[i].spec[0], 1); + if (error == 0) { + if (bootverbose) + printf("Invalid freq %u, ignored.\n", + sets[i].spec[0]); + } else { + table[idx].freq = sets[i].freq; + table[idx].volts = sets[i].volts; + table[idx].id16 = sets[i].spec[0]; + table[idx].power = sets[i].power; + ++idx; + } + + /* restore saved setting */ + est_set_id16(sets[i].spec[0], 0); + } } /* Mark end of table with a terminator. */ - bzero(&table[i], sizeof(freq_info)); + bzero(&table[idx], sizeof(freq_info)); sc->acpi_settings = TRUE; *freqs = table; @@ -1148,6 +1169,41 @@ *freqs = p->freqtab; return (0); } +static void +est_get_id16(uint16_t *id16_p) { + *id16_p = rdmsr(MSR_PERF_STATUS) & 0xffff; +} + +static int +est_set_id16(uint16_t id16, int need_check) { + uint64_t msr; + uint16_t new_id16; + int rc = 0; + + /* + * Try to set freq. + */ + + /* Read the current register, mask out the old, set the new id. */ + msr = rdmsr(MSR_PERF_CTL); + msr = (msr & ~0xffff) | id16; + wrmsr(MSR_PERF_CTL, msr); + + /* Wait a short while for the new setting. XXX Is this necessary? */ + DELAY(EST_TRANS_LAT); + + if (need_check) { + est_get_id16(&new_id16); + if (new_id16 != id16) { + if (bootverbose) + printf("Invalid id16 (set, cur) = (%u, %u)\n", + id16, new_id16); + rc = ENXIO; /* Can not set this value */ + } + } + + return (rc); +} static freq_info * est_get_current(freq_info *freq_list) @@ -1162,7 +1218,7 @@ * we get a temporary invalid result. */ for (i = 0; i < 5; i++) { - id16 = rdmsr(MSR_PERF_STATUS) & 0xffff; + est_get_id16(&id16); for (f = freq_list; f->id16 != 0; f++) { if (f->id16 == id16) return (f); @@ -1201,7 +1257,6 @@ { struct est_softc *sc; freq_info *f; - uint64_t msr; /* Find the setting matching the requested one. */ sc = device_get_softc(dev); @@ -1213,9 +1268,7 @@ return (EINVAL); /* Read the current register, mask out the old, set the new id. */ - msr = rdmsr(MSR_PERF_CTL); - msr = (msr & ~0xffff) | f->id16; - wrmsr(MSR_PERF_CTL, msr); + est_set_id16(f->id16, 0); /* Wait a short while for the new setting. XXX Is this necessary? */ DELAY(EST_TRANS_LAT); --------------030908000301020908020206-- From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 5 03:22:06 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB15416A46D for ; Sat, 5 Jan 2008 03:22:06 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp08.mail.ogk.yahoo.co.jp (ybbsmtp08.mail.ogk.yahoo.co.jp [124.83.153.128]) by mx1.freebsd.org (Postfix) with SMTP id 8C1F913C44B for ; Sat, 5 Jan 2008 03:22:06 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 25198 invoked by alias); 5 Jan 2008 03:22:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; h=Received:X-Apparently-From:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=QIgzbM9fN+7BRGnCXqnqc+XEk/GbMVq7MCHUFRE1AugQGgwsWQgdIagN8uRV1KOaQKFslCoMLnuzWnRm52OE/4BgyMGFkqapQJsLORCNavwe5OkjFNazjGuZ85cl9vtA ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp08.mail.ogk.yahoo.co.jp with SMTP; 5 Jan 2008 03:22:05 -0000 X-Apparently-From: Message-ID: <477EF7BD.8040800@ybb.ne.jp> Date: Sat, 05 Jan 2008 12:21:33 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Takeharu KATO References: <476E8674.5000303@gmail.com> <477EF09E.60606@ybb.ne.jp> In-Reply-To: <477EF09E.60606@ybb.ne.jp> Content-Type: multipart/mixed; boundary="------------050906000808070009080005" Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 03:22:07 -0000 This is a multi-part message in MIME format. --------------050906000808070009080005 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hi, Sorry, I sent wrong patch, please apply this instead. Takeharu KATO wrote: > Hi, > > I met same problem on my Panasonic CF-R7 note book PC. > As far as I investigate, cpufreq(est driver) does not check setting > values for PERFCTL register which are reported from acpi_perf driver. > > According to comments in sys/i386/cpufreq/est.c, > the auther of the driver regards this as TODO thing > (see following lines.). > > -- sys/i386/cpufreq/est.c > for (i = 0; i < count; i++) { > /* > * TODO: Figure out validity checks for id16. Linux checks > * that the control and status values match. > */ > -- > > I wrote the patch to check id16 values as comments says. > As far as I test the patch, the patch fixes the problem. > > Would you try this patch? > > P.S. I've send-pr this problem with this patch in this > morning(kern/119350). > > Andrey wrote: >> Good time of the day. >> >> I've noticed that powerd isn't able to decrease CPU frequency on my >> laptop (HP Compaq 6710b) as soon as frequency gets highest level. >> >> I've pottered a bit in the sources and it seems found the root of the >> issue. >> So those who are interested in the subject let consider it. >> >> For instance my system reports the following frequency levels: >> >> [silent@beastie][/home/silent]sysctl dev.cpu.0.freq_levels >> dev.cpu.0.freq_levels: 2001/35000 2000/35000 1750/30625 1600/25000 >> 1400/21875 1200/16000 1050/14000 900/12000 800/14000 700/12250 >> 600/10500 500/8750 400/7000 300/5250 >> >> If I try to adjust current frequency to 2000 MHz then I'll get: >> [silent@beastie][/home/silent]sudo sysctl dev.cpu.0.freq=2000 >> dev.cpu.0.freq: 300 -> 2001 >> Let check: >> [silent@beastie][/home/silent]sysctl dev.cpu.0.freq >> dev.cpu.0.freq: 2001 >> >> Thus, as you can see, I have level "2000" which system reports me but >> actually I can't to adjust those one exactly because it silently >> becomes "2001" >> >> Well... If I'm not mistaken powerd calculates the current "CPU idle >> mark" and if it is more then adopted value (by default 90%) then it >> shifts CPU frequency value 1 step down. In my case powerd sticks at >> "2001". It is obvious because when powerd decreases CPU frequency from >> the highest frequency level we'll get the following scenario: >> >> +-----------------------+ >> | dev.cpu.0.freq=2001 +--<-+ >> +-----------+-----------+ | >> | | >> Y | >> +-----------+-----------+ | >> | "CPU idle" > 90% | | >> +-----------+-----------+ | >> | | >> Y ^ >> +-----------+-----------+ ^ >> | powerd shifts freq. | ^ >> | 1 step down: | | >> | "2001" -> "2000" | | >> +-----------+-----------+ | >> | | >> Y | >> +-----------+-----------+ | >> | actually we have here | | >> | dev.cpu.0.freq == 2001+-->-+ >> +-----------------------+ >> >> >> According to the things mentioned above I've came to conclusion that >> in my case it is not a good idea to rely on frequency levels reported >> by the system. (Also I saw many sysctl mibs (dev.cpu.0.freq) of many >> other people. And there were "strange" frequency levels like "2000" >> and "2001". Of course I can't state that their systems' behaviors fit >> my case. But still...) >> >> So the simple way out I see is to teach powerd recognize "fake" >> frequency levels. Here I suggest a very simple workaround (and may be >> quite ugly... sorry I'm not sure if it is my cup of tee) which allows >> me to overcome the issue. And I hope it can be useful for smb. else. >> >> Also I'd like to hear opinions of others. May be there exists another >> and simpler way to overcome an issue or even I've missed something or >> not aware of something. >> >> >> Thank you. >> >> >> -- >> Sincerely, >> Andrey Kosachenko >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------050906000808070009080005 Content-Type: text/plain; name="est-fix-v2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="est-fix-v2.patch" --- sys.orig/i386/cpufreq/est.c 2006-05-11 17:35:44.000000000 +0000 +++ sys/i386/cpufreq/est.c 2008-01-05 12:08:41.359933175 +0000 @@ -902,6 +902,8 @@ static int est_set(device_t dev, const struct cf_setting *set); static int est_get(device_t dev, struct cf_setting *set); static int est_type(device_t dev, int *type); +static int est_set_id16(uint16_t id16, int need_check); +static void est_get_id16(uint16_t *id16_p); static device_method_t est_methods[] = { /* Device interface */ @@ -1068,7 +1070,6 @@ return (0); } - static int est_acpi_info(device_t dev, freq_info **freqs) { @@ -1076,7 +1077,8 @@ struct cf_setting *sets; freq_info *table; device_t perf_dev; - int count, error, i; + int count, error, i, idx; + uint16_t saved_id16; perf_dev = device_find_child(device_get_parent(dev), "acpi_perf", -1); if (perf_dev == NULL || !device_is_attached(perf_dev)) @@ -1098,19 +1100,38 @@ error = ENOMEM; goto out; } - for (i = 0; i < count; i++) { + for (i = 0, idx = 0; i < count; i++) { /* - * TODO: Figure out validity checks for id16. Linux checks - * that the control and status values match. + * Confirm id16 value is correct. */ - table[i].freq = sets[i].freq; - table[i].volts = sets[i].volts; - table[i].id16 = sets[i].spec[0]; - table[i].power = sets[i].power; + if (sets[i].freq > 0) { + + /* save current value */ + est_get_id16(&saved_id16); + + /* + * Try to set specified value + */ + error = est_set_id16(sets[i].spec[0], 1); + if (error != 0) { + if (bootverbose) + printf("Invalid freq %u, ignored.\n", + sets[i].freq); + } else { + table[idx].freq = sets[i].freq; + table[idx].volts = sets[i].volts; + table[idx].id16 = sets[i].spec[0]; + table[idx].power = sets[i].power; + ++idx; + } + + /* restore saved setting */ + est_set_id16(sets[i].spec[0], 0); + } } /* Mark end of table with a terminator. */ - bzero(&table[i], sizeof(freq_info)); + bzero(&table[idx], sizeof(freq_info)); sc->acpi_settings = TRUE; *freqs = table; @@ -1148,6 +1169,41 @@ *freqs = p->freqtab; return (0); } +static void +est_get_id16(uint16_t *id16_p) { + *id16_p = rdmsr(MSR_PERF_STATUS) & 0xffff; +} + +static int +est_set_id16(uint16_t id16, int need_check) { + uint64_t msr; + uint16_t new_id16; + int rc = 0; + + /* + * Try to set freq. + */ + + /* Read the current register, mask out the old, set the new id. */ + msr = rdmsr(MSR_PERF_CTL); + msr = (msr & ~0xffff) | id16; + wrmsr(MSR_PERF_CTL, msr); + + /* Wait a short while for the new setting. XXX Is this necessary? */ + DELAY(EST_TRANS_LAT); + + if (need_check) { + est_get_id16(&new_id16); + if (new_id16 != id16) { + if (bootverbose) + printf("Invalid id16 (set, cur) = (%u, %u)\n", + id16, new_id16); + rc = ENXIO; /* Can not set this value */ + } + } + + return (rc); +} static freq_info * est_get_current(freq_info *freq_list) @@ -1162,7 +1218,7 @@ * we get a temporary invalid result. */ for (i = 0; i < 5; i++) { - id16 = rdmsr(MSR_PERF_STATUS) & 0xffff; + est_get_id16(&id16); for (f = freq_list; f->id16 != 0; f++) { if (f->id16 == id16) return (f); @@ -1201,7 +1257,6 @@ { struct est_softc *sc; freq_info *f; - uint64_t msr; /* Find the setting matching the requested one. */ sc = device_get_softc(dev); @@ -1213,9 +1268,7 @@ return (EINVAL); /* Read the current register, mask out the old, set the new id. */ - msr = rdmsr(MSR_PERF_CTL); - msr = (msr & ~0xffff) | f->id16; - wrmsr(MSR_PERF_CTL, msr); + est_set_id16(f->id16, 0); /* Wait a short while for the new setting. XXX Is this necessary? */ DELAY(EST_TRANS_LAT); --------------050906000808070009080005-- From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 5 07:44:33 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E1C216A481; Sat, 5 Jan 2008 07:44:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id D67F513C44B; Sat, 5 Jan 2008 07:44:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id SAA08100; Sat, 5 Jan 2008 18:44:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 5 Jan 2008 18:44:26 +1100 (EST) From: Ian Smith To: John Baldwin In-Reply-To: <200801041012.25643.jhb@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, questions@freebsd.org Subject: Re: how to suspend/wake-up a FreeBSD machine? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 07:44:33 -0000 On Fri, 4 Jan 2008, John Baldwin wrote: > On Friday 04 January 2008 03:13:20 am Ian Smith wrote: > > On Fri, 4 Jan 2008, Norberto Meijome wrote: > > > On Sun, 30 Dec 2007 11:51:41 +0100 > > > Henrik Brix Andersen wrote: > > > > > > > That depends largely on the hardware - on e.g. ThinkPads you need to > > > > press the 'Fn' button to wake up the laptop after sleep. > > > > > > hmm i think it's not so much the Fn key, u need to do anything that > > > triggers an ACPI event in the BIOS - like opening the lid , or > > > pressing Fn. I *think* 'thinkVantage' blue btn should work too. > > > > On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to > > have to use the Fn key to wake. No other keys do that on mine including > > the ThinkPad key, so then called. > > > > While consulting 'sysctl hw.acpi' about that I see: > > hw.acpi.lid_switch_state: NONE > > which I assume reflects my don't-do-that BIOS setting. > > No, that's the FreeBSD default. Um, der .. I see that and other sysctls are in acpi(4) now, but weren't in my (oldish) 5.5-STABLE nor 6.1-RELEASE. Time for upgrades for sure! > > And confirming: > > # sysctl hw.acpi.lid_switch_state=1 # (or =0) > > hw.acpi.lid_switch_state: NONE > > sysctl: hw.acpi.lid_switch_state: Invalid argument > > This is because this sysctl is not an on/off, but it takes an Sx state to > suspend to when you close the lid. So if you set this to S1 it will try to > enter S1 when you close the lid, etc. For example: > > sysctl hw.acpi.lid_switch_state=S3 > > Would make it enter S3 when you closed the lid. Thanks John. S3 works on mine, but S1 doesn't. Didn't try S5 :) but NONE is really what I want there anyway. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 5 18:50:02 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE81D16A418 for ; Sat, 5 Jan 2008 18:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A1A9C13C468 for ; Sat, 5 Jan 2008 18:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m05Io2JJ048063 for ; Sat, 5 Jan 2008 18:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m05Io2du048062; Sat, 5 Jan 2008 18:50:02 GMT (envelope-from gnats) Date: Sat, 5 Jan 2008 18:50:02 GMT Message-Id: <200801051850.m05Io2du048062@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: "Yousif Hassan" Cc: Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousif Hassan List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 18:50:02 -0000 The following reply was made to PR i386/79080; it has been noted by GNATS. From: "Yousif Hassan" To: , , Cc: Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110 Date: Sat, 5 Jan 2008 13:19:08 -0500 The problem is still found in the most recent 7.0 RC code as well. Has something to do with a Mutex lock/unlock problem when the thermal zone change occurs - it doesn't appear to be an interrupt storm any longer. It is assuredly ACPI-related, because disabling ACPI makes the freezes go away. However, this laptop does not function well without ACPI so it's not a good workaround. USB devices do not work w/o ACPI, as well as other hardware. There are several suggested workarounds I tried, none of which resoloved the issue. These included building the kernel with apic, disabling apic, manually changing the hw.acpi.thermal.tz0.active number (my nx6110 seems to want to keep it at 1 no matter what), and using the ULE scheduler rather than the 4BSD. Again, none of the above workarounds, in any combination, solved the issue. INFORMATION ----------- Turning on debugging, the following appears right before the lock, as soon as temperature rises enough to trigger a change in the zone: acpi_tz0: _AC3: temperature 68.0 >= setpoint 45.0 acpi_tz0: _AC2: temperature 68.0 >= setpoint 55.0 acpi_tz0: _AC3: temperature 67.0 >= setpoint 45.0 acpi_tz0: _AC2: temperature 67.0 >= setpoint 55.0 ...etc... and then: ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 0xc321c220), AE_TIME ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ1_._TMP] (Node 0xc321b9c0), AE_TIME ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 0xc321c220), AE_TIME ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ2_._TMP] (Node 0xc321b8c0), AE_TIME ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] (the errors continue to repeat ad infinitum, and each TZ reports problems) As a result, you will eventually see: acpi_tz0: error fetching current temperature -- AE_TIME acpi_tz1: error fetching current temperature -- AE_TIME (..etc...) The interesting thing is that THIS PROBLEM DOES NOT APPEAR in FreeBSD 6.2-RELEASE nor in any of the 6.3-RC variants. It's unique to FreeBSD 7, and it involves some of the new ACPI mutex code. This is definitely a regression for this particular laptop since it worked well in 6.x - so as such, maybe it would be worthwhile to investigate this bug. It seems general enough that it could affect other laptop ASLs as well. The ASL dump AND a sysctl dump can be found: http://www.far-far-away.com/~yousif/freebsd/ Please let me know if more information is needed. --Yousif From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 5 19:07:33 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC05C16A418 for ; Sat, 5 Jan 2008 19:07:32 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 78A5813C468 for ; Sat, 5 Jan 2008 19:07:32 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 12093 invoked from network); 5 Jan 2008 13:34:48 -0500 Received: from kamino.far-far-away.us (HELO kamino) (192.168.0.9) by coruscant.far-far-away.us with SMTP; 5 Jan 2008 13:34:48 -0500 Message-ID: <09EE88FF8B644C90AAE0158ACB4AB595@kamino> From: "Yousif Hassan" To: "\"Frederic Chardon\"" , Date: Sat, 5 Jan 2008 13:41:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: Subject: Re: solved ?] i386/79080: acpi thermal changes freezes HP nx6110 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousif Hassan List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 19:07:33 -0000 Hi Frederic, Nate, list members: I recently tried 7.0-RC1 on an nx6110. The thermal freeze problems are definitely still there, and appear worse. I tried all of the workarounds below and nothing helped - I suspect this issue is not interrupt storm related any more, but rather, a mutex race condition of some sort... please see below... > Hello, > I found a workaround to avoid freeze while change _ACx state on > nx6110. In kernel, use > options SCHED_ULE > device apic > options AUTO_EOI_1 > options AUTO_EOI_2 I tried this. With the exact above options, by root boot device became unfindable, and no amount of tweaking at the loader prompt would get it to boot. When I removed AUTO_EOI_2 and tried again, the root filesystem booted but the freeze problems remained. I also tried the out-of-the-box GENERIC kernel, of course; freeze problems occur. > ULE and apic allow the freeze to last only a few second (without it, > I never waited more than 10 minutes but I supposed it can be long...). > AUTO_EOI_1 and AUTO_EOI_2 have no impact without ULE and apic. > Separately they don't have noticeable effect. In my case, the mutex problem causes the freeze to last forever, regardless of the scheduler used. (From a previous email by Frederic): > Pavel Rydvan stated in the pr that if the temperature doesn't change > there is no problem. In fact, it is not completely true: problem > arises when ACx _increase_. When it decreases if there is a freeze it > is unnoticable. I agree with this observation. I only get the freezes if the temperature INCREASES. > If I manually set hw.acpi.thermal.tz0.active then there is no more > problem (apart from the thermal function of ACPI becomes useless). This I tried and it didn't work for me. The "active" number remained at 1 regardless of the arguments I passed it - I tried -1, 0, 1, 2, 3, 4, 5, and 6. I don't know how you get this number to change but sysctl kept it at 1. (ex: #root# sysctl hw.acpi.thermal.tz0.active=-1 hw.acpi.thermal.tz0.active: 1 -> 1 ) > Pavel Rydvan said that it is due to IRQ storm, I can't dig deeper this > because I don't know how to do. It seems mutex-related to me. I placed as much of the debug info as I could into the PR. I'll also include it below. Thanks to anyone for reading this. --BEGIN PR 79080 INFO-- The problem is still found in the most recent 7.0 RC code as well. Has something to do with a Mutex lock/unlock problem when the thermal zone change occurs - it doesn't appear to be an interrupt storm any longer. It is assuredly ACPI-related, because disabling ACPI makes the freezes go away. However, this laptop does not function well without ACPI so it's not a good workaround. USB devices do not work w/o ACPI, as well as other hardware. There are several suggested workarounds I tried, none of which resoloved the issue. These included building the kernel with apic, disabling apic, manually changing the hw.acpi.thermal.tz0.active number (my nx6110 seems to want to keep it at 1 no matter what), and using the ULE scheduler rather than the 4BSD. Again, none of the above workarounds, in any combination, solved the issue. INFORMATION ----------- Turning on debugging, the following appears right before the lock, as soon as temperature rises enough to trigger a change in the zone: acpi_tz0: _AC3: temperature 68.0 >= setpoint 45.0 acpi_tz0: _AC2: temperature 68.0 >= setpoint 55.0 acpi_tz0: _AC3: temperature 67.0 >= setpoint 45.0 acpi_tz0: _AC2: temperature 67.0 >= setpoint 55.0 ...etc... and then: ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 0xc321c220), AE_TIME ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ1_._TMP] (Node 0xc321b9c0), AE_TIME ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 0xc321c220), AE_TIME ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ2_._TMP] (Node 0xc321b8c0), AE_TIME ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] (the errors continue to repeat ad infinitum, and each TZ reports problems) As a result, you will eventually see: acpi_tz0: error fetching current temperature -- AE_TIME acpi_tz1: error fetching current temperature -- AE_TIME (..etc...) The interesting thing is that THIS PROBLEM DOES NOT APPEAR in FreeBSD 6.2-RELEASE nor in any of the 6.3-RC variants. It's unique to FreeBSD 7, and it involves some of the new ACPI mutex code. This is definitely a regression for this particular laptop since it worked well in 6.x - so as such, maybe it would be worthwhile to investigate this bug. It seems general enough that it could affect other laptop ASLs as well. The ASL dump AND a sysctl dump can be found: http://www.far-far-away.com/~yousif/freebsd/ Please let me know if more information is needed. --Yousif