How to disable acpi thermal?

[Daniel Eischen]

On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote:

>
> On Wed, 2008-02-20 at 17:15 -0500, Daniel Eischen wrote:
>> On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote:
>>
>>>
>>> On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote:
>>>> [ Redirected from -current ]
>>>>
>>>> I posted the acpidump here:
>>>>
>>>>    http://people.freebsd.org/~deischen/stl2.iasl
>>>>
>>>> The problem is that acpi_thermal keeps shutting down the system
>>>> after 2 minutes into a buildkernel.  The system has no load other
>>>> than the buildkernel at the time it shuts down.
>>>>
>>>> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the
>>>> other CPU socket being occupied by a CPU terminator thingy.
>>>> I uncovered the rackmount system and watched it while building
>>>> a kernel.  With the cover off the acpi monitored temperature
>>>> went to 107C and stayed there.  It only took a minute or two
>>>> to get there.  I felt around inside the chassis and nothing
>>>> was even near being to warm or hot.  With the cover on, the
>>>> temperature goes to 111/112C before being shutdown by acpi_thermal
>>>> (the limit being 110C).  There is no way anything in that
>>>> chassis is anywhere near 100C.  I've disabled acpi_thermal
>>>> for now, but it'd be nice to get a better fix.
>>>>
>>>> Any ideas?
>>>>
>>> You can try this patch on your ASL, which might just cause passive
>>> cooling to kick in. If you decide to try a patch, I would like to see
>>> the output of
>>
>> I guess I'm confused - how can passive cooling "kick in".  Isn't
>> passive cooling always on if you are using a heatsink?
> In the ACPI context (and please, bear with me -- I am no expert -- I
> just read respective pieces of the spec and experimented with few
> specimens of my own hardware) "passive" cooling is lowering of the CPU
> frequency when temperature reaches given point, as denoted by
> hw.acpi.thermal.tzN._PSV value. This will happen (I have tried ;)
> regardless of the efforts of powerd to raise the frequency due to the
> load history. This helps in the situations when CPU could not run at
> maximum load for protracted periods of time.

Ok, now this makes sense.

> I assume (possibly incorrectly) that 1) your CPU is capable of the
> frequency throttling and 2) you are using frequency governor of some
> sort (see cpufreq(4) for detail). If this is not the case, the change
> will not help.

I don't know about 1):

   CPU: Intel Pentium III (933.08-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
   Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>

and 2), no, I'm not using a frequency governor from what I can
tell.

   $ sysctl -a | grep dev.cpu
   dev.cpu.0.%desc: ACPI CPU
   dev.cpu.0.%driver: cpu
   dev.cpu.0.%location: handle=\_PR_.CPU0
   dev.cpu.0.%pnpinfo: _HID=none _UID=0
   dev.cpu.0.%parent: acpi0
   dev.cpu.0.cx_supported: C1/0
   dev.cpu.0.cx_lowest: C1
   dev.cpu.0.cx_usage: 100.00%

   $ sudo kldload /boot/kernel/cpufreq.ko

   $ sysctl -a | grep dev.cpu
   dev.cpu.0.%desc: ACPI CPU
   dev.cpu.0.%driver: cpu
   dev.cpu.0.%location: handle=\_PR_.CPU0
   dev.cpu.0.%pnpinfo: _HID=none _UID=0
   dev.cpu.0.%parent: acpi0
   dev.cpu.0.cx_supported: C1/0
   dev.cpu.0.cx_lowest: C1
   dev.cpu.0.cx_usage: 100.00%


> Also, since I have sent you that change, I have learned that setting
> hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might
> accomplish the same thing as the ASL change. I saw it working for the
> thermal zone which already had sensible _PSV, but I have no hardware to
> try this approach when _PSV is not present in the ASL.

Well, this is a server board, not a laptop, so I'm not sure
it even has CPU throttling.

-- 
DE