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