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

[Chris Whitehouse]

Ian Smith wrote:
> On Sun, 29 Mar 2009, Chris Whitehouse wrote:
>  > Ian Smith wrote:
> [..]
>  > > Try adding it to loader.conf and rebooting.
>  > 
>  > Nope still unknown oid. But in view of other progress I don't think that
>  > matters, at least for me.
> 
> Good to see you got there with the patched ASL; should help others too.

You can get different values of tz0._CRT by choosing the two hex values:

0x00 0x00 45.0C
0x00 0x01 102.0C
0x00 0x02 95.0C
0x00 0x03 60.0C
0x01 0x00 55.0C
0x01 0x01 60.0C
0x01 0x02 105.0C
0x01 0x03 127.1C
0x02 0x00 70.0C
0x02 0x01 127.1C
0x02 0x02 127.1C
0x03 0x00 80.0C

All the others I tried gave -1

Actually I think the patch may be a bit of a bodge. I think the values I 
changed are pointers to hard coded values in the ASL. It would be much 
nicer to identify the actual values in the ASL and add a new one for 
tz0._CRT.

> 
>  > > 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).
>  > 
>  > For some of the time I was running one instance of burnK7, other times 2
>  > instances. I just tested and 2 instances does run on both cores.
> 
> Right.  I was well wrong about CPU1 being TZ2.  Perhaps its the GPU?  
> If still interested, something like glxgears would test the theory.  The 
> same _CRT and _TC1,TC2,TSP values did assist me into false assumption :)

See www.fishercroft.plus.com/messages3.gz. This was with 2 x glxgears 
and firefox streaming a flash video (yeay fbsd can do flash video :)). 
Looks like tz4 is gpu. The service manual which I just discovered 
mentions temperature limits for hard disk and battery, maybe those are 
zones as well but no time to test right now.

I just tested the url in firefox and it displays the text, ie it gunzips 
it!! Amazing!
> 
>  > >  > 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?
>  > 
>  > Do you mean TZ1 gets much hotter than TZ2? When I ran 2 instances of burnk7
>  > one ran on each cpu (viewed in top). When I ran a single instance the on-die
>  > temps in the first two columns still tracked each other. Also this machine is
>  > running KDE which is always doing something which blurs the figures a bit.
>  > 
>  > I put messages2 next the previous one, I think it shows that tz2 is not cpu1
>  > even if tz1 is measuring cpu temp somehow. dev.cpu.n.temperature columns are
>  > the on-die temps. Those oids are only visible when coretemp is loaded, I
>  > don't know if the ASL is using those temperature probes.
> 
> http://www.fishercroft.plus.com/messages2.gz indeed does show that.  
> 
> Making sense now; there's no reason two sensors on one die should vary 
> much, so there's no need for a separate TZ for the second core.
> 
> Sorry if my further education was at the expense of your problem ..

Education is good :)
> 
> cheers, Ian
>