[patch] enhance powerd(8) to handle max temperature

Alexandre "Sunny" Kovalenko alex.kovalenko at verizon.net
Fri Aug 3 00:36:16 UTC 2007


On Thu, 2007-08-02 at 10:08 -0700, Nate Lawson wrote:
> M. Warner Losh wrote:
> > In message: <46AE8F78.1060203 at root.org>
> >             Nate Lawson <nate at root.org> writes:
> > : Hajimu UMEMOTO wrote:
> > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200
> > : >>>>>> Pietro Cerutti <gahr at gahr.ch> said:
> > : > gahr> My patch is really just a first draft that I wrote in order to have
> > : > gahr> feedbacks on the general idea to implement a temperature controlling
> > : > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and
> > : > gahr> your feedback is that it's not a good idea, which I respect.
> > : > 
> > : > It is rather backward, IMHO.  I did implement a passive cooling
> > : > feature as an enhancement of powerd(8) like you did, during initial
> > : > phases.  Then, I implemented it in our kernel as a result.
> > : 
> > : I'll take a look at your patch.  Umemoto-san is right in that you really
> > : want the kernel to control cooling.  What happens if powerd dies/hangs
> > : and your system burns up?  Passive cooling is often a last resort to
> > : keep the system from overheating.
> > 
> > I keep getting the system shutting down on my HP by FreeBSD because
> > the temperature exceeds the _CRT value.  Maybe there's something wrong
> > with my values, since it happens a lot:
> > 
> > hw.acpi.thermal.min_runtime: 0
> > hw.acpi.thermal.polling_rate: 10
> > hw.acpi.thermal.user_override: 0
> > hw.acpi.thermal.tz0.temperature: 0.0C
> > hw.acpi.thermal.tz0.active: -1
> > hw.acpi.thermal.tz0.passive_cooling: 1
> > hw.acpi.thermal.tz0.thermal_flags: 0
> > hw.acpi.thermal.tz0._PSV: 90.0C
> > hw.acpi.thermal.tz0._HOT: -1
> > hw.acpi.thermal.tz0._CRT: 94.0C
> > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1
> > 
> > Note: temperature is always 0.0C.
> > 
> > What can I do to help my situation, if I really want the kernel doing
> > the cooling?
> 
> Your embedded controller is timing out.  Thus you're getting a bogus
> value for _TMP.
I have sort of picked up this thread in the middle... was it determined
that EC is timing out? The reason for asking is -- I used to have a
laptop where _TMP would just read value from the memory location, which
was never populated anywhere else in ASL. Call to _PSV method would go
figure current temperature and start fan, if necessary. Ugly...

Dumping ASL (using instructions from handbook) and looking for something
like

Method (_TMP, 0, NotSerialized)

might be a real eye opener.

If you would like me to take a look at your ASL, send it to me privately
-- I've only done it for one laptop, so no claims of the great skill
there, but maybe it is as simple as the other one ;)

-- 
Alexandre "Sunny" Kovalenko



More information about the freebsd-acpi mailing list