Avoiding "WARNING: system temperature too high, shutting down soon!"?

Nate Lawson nate at root.org
Mon Sep 25 10:47:31 PDT 2006


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.
> 
> 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.
> 
> 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 
to specify a profile associated with each setting.  This could have a 
CPU freqs usable section, ataidle parameters, etc.

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


More information about the freebsd-acpi mailing list