acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537)

Ian Smith smithi at nimnet.asn.au
Sun Mar 29 07:20:49 PDT 2009


On Fri, 27 Mar 2009, Chris Whitehouse wrote:
 > Alexandre "Sunny" Kovalenko wrote:
 > > On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote:
 > > > Chris Whitehouse wrote:
 > > > > Alexandre "Sunny" Kovalenko wrote:
 > > > > > To be fair, if all you want is to override _CRT, you should be able
 > > > > > to
 > > > > > put something to the tune of
 > > > > > 
 > > > > > hw.acpi.thermal.user_override=1
 > > > > > hw.acpi.thermal.tz0._CRT=90C
 > > > > > 
 > > > > > in your /etc/sysctl.conf and not deal with the ASL at all.
 > > > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until
 > > > > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change
 > > > > values at which point hw.acpi.thermal.tz0._CRT reverts to -1.
 > > > > 
 > > 
 > > Looking at ASL I can see five thermal zone objects defined and only one
 > > of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes
 > > to the trouble of making sane return value. Maybe Windows somehow knows
 > > which thermal zones to ignore? Given the snippet below this _was_ geared
 > > heavily towards Windows:

However looking at Chris' messages listing linked below, TZ4 is strange.  
It's the one that got hottest during the burnk7 run, 10C below _CRT, 
steps seem sometimes to be 15 or 20C, and occasionally it reports 0C. It 
controls nothing obvious, maybe it only exists to trigger on _CRT?

No, later looking at ThermalZone (TZ4) it seems to clip readings at 100C 
anyway and doesn't have a _CRT method .. but I'm an ASL neophyte ..

 > >                     If (\_OSI ("Windows 2001"))
 > >                     {
 > >                         Store (0x04, C014)
 > >                     }
 > > 
 > >                     If (\_OSI ("Windows 2001 SP1"))
 > >                     {
 > >                         Store (0x04, C014)
 > >                     }
 > > 
 > >                     If (\_OSI ("Windows 2001 SP2"))
 > >                     {
 > >                         Store (0x05, C014)
 > >                     }
 > > 
 > >                     If (\_OSI ("Windows 2006"))
 > >                     {
 > >                         Store (0x06, C014)
 > >                     }
 > > 
 > > Chris, you should be able to set hw.acpi.osname=<pick one from the
 > > above> in loader.conf and see if things improve somewhat. Note that
 > > "Windows 2001" and "Windows 2001 SP1" are identical.
 > 
 > sysctl says it is an unknown oid

Try adding it to loader.conf and rebooting.

 > > Could you also, please, post the full output of the sysctl
 > > hw.acpi.thermal
 > > 
 > hw.acpi.thermal.min_runtime: 0
 > hw.acpi.thermal.polling_rate: 10
 > hw.acpi.thermal.user_override: 1
 > hw.acpi.thermal.tz0.temperature: 45.0C
 > hw.acpi.thermal.tz0.active: -1
 > hw.acpi.thermal.tz0.passive_cooling: 0
 > hw.acpi.thermal.tz0.thermal_flags: 0
 > hw.acpi.thermal.tz0._PSV: -1
 > hw.acpi.thermal.tz0._HOT: -1
 > hw.acpi.thermal.tz0._CRT: -1
 > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz0._TC1: -1
 > hw.acpi.thermal.tz0._TC2: -1
 > hw.acpi.thermal.tz0._TSP: -1

>From your messages listing I guess this is the heatsink sensor, running 
the fan.  5C steps up to 60C then 10C steps above.  values returned are 
a little on the high side of either coretemp or tz[12].temperature.  No 
_CRT value (shown here) though the value returned by the _CRT method 
seems to be causing the problem?

>From what I can figure for TZ0:

            Method (_CRT, 0, Serialized)
            {
                Return (C316 (0x04, 0x00))
            }
where:
        Method (C316, 2, Serialized)
        {
            Store (0x01, Local0)
            Store (Arg0, Local1)
            Store (DerefOf (Index (C312, Arg1)), Local3)
            If (LEqual (Local3, 0xFFFFFFFD))
            {
                Store (0x00, Local3)
            }

            If (LLess (Arg0, Local3))
            {
                Store (0x00, Local0)
                Add (Arg0, 0x01, Local1)
            }

            Store (DerefOf (Index (DerefOf (Index (DerefOf (Index (C305, C317 (Arg1)
                )), Local0)), Local1)), Local2)
            Return (Local2)
        }

but I got lost amongst the DerefOf (Index ..) nesting, not quite like 
following source with helpfully symbolic names.  Good luck Alexandre!


 > hw.acpi.thermal.tz1.temperature: 43.0C
 > hw.acpi.thermal.tz1.active: -1
 > hw.acpi.thermal.tz1.passive_cooling: 1
 > hw.acpi.thermal.tz1.thermal_flags: 0
 > hw.acpi.thermal.tz1._PSV: 102.0C
 > hw.acpi.thermal.tz1._HOT: -1
 > hw.acpi.thermal.tz1._CRT: 105.0C
 > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz1._TC1: 1
 > hw.acpi.thermal.tz1._TC2: 2
 > hw.acpi.thermal.tz1._TSP: 300

Quacks like a CPU0.  This one triggers passive cooling.  Its temperature 
values are generally 2-3C lower than the (eyeball) average of coretemp 
values, except when heating up fast, when it lags the latter by 5-6C.

I don't know where these various sensors live.  Board?  Package?  Die?

 > hw.acpi.thermal.tz2.temperature: 43.0C
 > hw.acpi.thermal.tz2.active: -1
 > hw.acpi.thermal.tz2.passive_cooling: 0
 > hw.acpi.thermal.tz2.thermal_flags: 0
 > hw.acpi.thermal.tz2._PSV: -1
 > hw.acpi.thermal.tz2._HOT: -1
 > hw.acpi.thermal.tz2._CRT: 105.0C
 > hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz2._TC1: 1
 > hw.acpi.thermal.tz2._TC2: 2
 > hw.acpi.thermal.tz2._TSP: 300

CPU1.  From the messages it appears that burnk7 ran on just CPU0 (tz1).

Snippets like this seem to confirm the cpu to tz allocation:
                            Notify (\_PR.CPU0, 0x80)
                            Notify (\_PR.CPU1, 0x80)
                            Notify (\_TZ.TZ1, 0x81)
                            Notify (\_TZ.TZ2, 0x81)

 > hw.acpi.thermal.tz3.temperature: 28.9C
 > hw.acpi.thermal.tz3.active: -1
 > hw.acpi.thermal.tz3.passive_cooling: 0
 > hw.acpi.thermal.tz3.thermal_flags: 0
 > hw.acpi.thermal.tz3._PSV: 60.0C
 > hw.acpi.thermal.tz3._HOT: -1
 > hw.acpi.thermal.tz3._CRT: 105.0C
 > hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz3._TC1: 1
 > hw.acpi.thermal.tz3._TC2: 2
 > hw.acpi.thermal.tz3._TSP: 300

This returned 28.[89]C throughout, too consistently to be anything real, 
except perhaps ambient external temperature?  Even then it's too steady.

 > hw.acpi.thermal.tz4.temperature: 0.0C
 > hw.acpi.thermal.tz4.active: -1
 > hw.acpi.thermal.tz4.passive_cooling: 0
 > hw.acpi.thermal.tz4.thermal_flags: 0
 > hw.acpi.thermal.tz4._PSV: -1
 > hw.acpi.thermal.tz4._HOT: -1
 > hw.acpi.thermal.tz4._CRT: 110.0C
 > hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz4._TC1: -1
 > hw.acpi.thermal.tz4._TC2: -1
 > hw.acpi.thermal.tz4._TSP: -1

As above, a mystery.

 > Also
 > fetch www.fishercroft.plus.com/messages.gz
 > 
 > will get bits of /var/log/messages with the normal startup messages and the
 > output of
 > 
 > #!/bin/sh
 > while [ TRUE ]; do
 > logger \
 > ` sysctl -n dev.cpu.0.temperature ; sysctl -n dev.cpu.1.temperature ; \
 > sysctl -n hw.acpi.thermal.tz0.temperature ; sysctl -n
 > hw.acpi.thermal.tz0.active ; sysctl -n  hw.acpi.thermal.tz0._CRT ; \
 > sysctl -n hw.acpi.thermal.tz1.temperature ; sysctl -n
 > hw.acpi.thermal.tz1.active ; sysctl -n  hw.acpi.thermal.tz1._CRT ; \
 > sysctl -n hw.acpi.thermal.tz2.temperature ; sysctl -n
 > hw.acpi.thermal.tz2.active ; sysctl -n  hw.acpi.thermal.tz2._CRT ; \
 > sysctl -n hw.acpi.thermal.tz3.temperature ; sysctl -n
 > hw.acpi.thermal.tz3.active ; sysctl -n  hw.acpi.thermal.tz3._CRT ; \
 > sysctl -n hw.acpi.thermal.tz4.temperature ; sysctl -n
 > hw.acpi.thermal.tz4.active ; sysctl -n  hw.acpi.thermal.tz4._CRT `
 > sleep 5
 > done
 > 
 > (sorry bad wrapping)

Good data.  I don't know if it helps track the ASL re $subject though.

 > The two cpu temps come from coretemp.ko module.

These I don't get.  They always track a few degrees above tz1 value, but 
rarely differ by more than 2C, while your burnk7 run showed CPU0 getting 
much hotter than CPU1, which only slowly rose during the run, indicating 
sympathetic package warming with an essentially idle CPU1, perhaps?

 > While this was running I changed the temp with burnK7 and an icepack :). It's
 > clear that the messages do correspond to changes of state but there are
 > further triggers that I am not watching.

Sure, but educational.  I won't ask where you applied the icepack :)

cheers, Ian


More information about the freebsd-acpi mailing list