From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 26 12:18:06 2006 Return-Path: X-Original-To: acpi@freebsd.org 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 544F116A415 for ; Tue, 26 Sep 2006 12:18:06 +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 35C3443D6E for ; Tue, 26 Sep 2006 12:18:02 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id WAA14996; Tue, 26 Sep 2006 22:17:43 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 26 Sep 2006 22:17:42 +1000 (EST) From: Ian Smith To: Nate Lawson In-Reply-To: <451815FC.1050103@root.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, David Wolfskill Subject: Re: Avoiding "WARNING: system temperature too high, shutting down soon!"? 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, 26 Sep 2006 12:18:06 -0000 Hi Nate and crew, I'm an ACPI newbie, though I've been keeping an eye on it these 4 years while using a Compaq Armada 1500c that does APM very well, and have just installed 6.1-R on a Thinkpad T23 in good condition, a model chosen in the end due to your message on FLCL saying suspend/resume worked w/ACPI. So from a low base I've been climbing the curve on possibilities with - and trying to understand interactions between - powerd, power_profile, acpi_ibm, acpi_thermal etc, looking towards minimum power consumption with responsiveness on demand, both on battery in the field and on 'AC' which is here supplied by battery from solar-only power anyway, with a computing budget not exceeding 60 Ah/day on average, and that with the old 1500c running 24/7 headless as a server at approx 24 Ah/day. On Mon, 25 Sep 2006, Nate Lawson wrote: > Eric Anderson wrote: > > On 09/22/06 09:08, David Wolfskill wrote: > >> On Sat, Sep 16, 2006 at 04:46:42PM -0700, David Wolfskill wrote: > >>> I could use some help: I seem to overheat my laptop; I'd like to get > >>> some idea of how to avoid the overheating, preferably while still > >>> getting the work done. > >>> ... > >> > >> I received several useful suggestions, and I have the problem mitigated > >> while I await word from places that advertise that they will do laptop > >> repairs. > > > > [..snip..] > > > >> Alexandre "Sunny" Kovalenko discussed the issues at some length, and > >> provided a patch to powerd(8) to cap the CPU frequency at or above a > >> certain temperature. As with the "passive cooling," I have not yet > >> needed that, so I haven't tested it. > >> > >> If there's interest in the patch to powerd(8), I could test it & submit > >> a PR -- but I'd rather not if there's not much interest. One more hand up for interest, David, for even a pointer to the patch. > > I think is interesting - it would be nice to have something like that, > > at least as an option to powerd. I think linux does something like this. What I've noticed so far is that powerd works great here with default values for adaptive speed shifting, but doesn't do anything with CX states like power_profile, which in turn seems to require settings of "NONE" for {performance,economy}_cpu_freq to not mess with powerd. I've yet to explore acpi_thermal settings beyond watching with sysctl, but powerd being able to respond to _PSV, _HOT and _CRT notifications sounds like a really good integrated idea. [As an aside, on machines with no working S4, it'd be 'cool' if "hw.acpi.thermal.tz%d._HOT Temperature to start critical suspend to disk (S4)." could use S3 instead, before a big S5 lose-all-your-work _CRT shutdown?] > > Another thing I just thought of, was to have two debug.cpufreq.lowest > > settings, like debug.cpufreq.lowest.battery and debug.cpufreq.lowest.ac > > so that one could have a cooler quieter system while plugged in, but > > still get fast enough performance, yet have a lower speed setting for > > battery usage. > > > > If that sounds useful to others, maybe I'll write a patch. > > Sure, if you mean implementing general profiles in powerd. You can get > AC line events from devd (/var/run/devd.pipe) and then just allow a user Do you mean instead of polling ACPI or APM states as in powerd.c now? I see advantages with maintaining ability to work with APM, or will acpi now simulate APM notifications such as line state and battery events? > to specify a profile associated with each setting. This could have a > CPU freqs usable section, ataidle parameters, etc. CX states too, maybe? I expect to be playing with ataidle soon, and hope to get blanking to switch LCD off (good power savings) as it does on the 1500c with apm_saver (which won't run under acpi). My T23 has ancient BIOS + EC and I've neither a USB floppy nor windows installed, so I have to figure out how to upgrade those before really seeing what this beastie can do; currently getting a bunch of ACPI-0356 and -1304 errors/warnings in dmesg, though most things seem to work fine anyway. Anyway hello, I'll likely bothering you guys a bit for a while .. Cheers, Ian > If you mean implementing more profiles in the kernel, I don't think the > kernel should be managing policy. It's up to userland to specify policy > and the kernel to do its best to meet it (only when speed/reliability > matters to the task of following the policy). > > -- > Nate