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

[Alexandre "Sunny" Kovalenko]

On Wed, 2009-03-25 at 09:06 -0700, Nate Lawson wrote:
> 
> Alexandre "Sunny" Kovalenko wrote:
> > On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote:
> >> [Please would you cc me in any reply as I'm not subscribed, thanks.]
> >>
> >> Ian Smith wrote:
> >>> On Tue, 24 Mar 2009, Pasi Parviainen wrote:
> >>>  > Chris Whitehouse wrote:
> >>>  > > Hi, I sent this a while ago but don't think there was a reply. I'm about to
> >>>  > > embark on a custom ASL to load in loader.conf as per
> >>>  > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just
> >>>  > > wondering if their might be a 'proper' fix on the way. I do have the latest
> >>>  > > bios installed.
> >>>  > 
> >>>  > Loading custom ASL with modified _CRT value for temperature zone in
> >>>  > question will solve the problem, see below for more information.
> >>>  > 
> >>>  > > Would it help if I installed 8-CURRENT?
> >>>  > 
> >>>  > Probably not, see below.
> >>>  > 
> >>>  > > -------- Original Message --------
> >>>  > > Subject: pr kern/105537
> >>>  > > Date: Mon, 12 Jan 2009 15:00:49 +0000
> >>>  > > From: Chris Whitehouse <cwhiteh at onetel.com>
> >>>  > > To: freebsd-acpi at FreeBSD.org
> >>>  > > 
> >>>  > > hi,
> >>>  > > 
> >>>  > > Please would you cc me in any reply as I'm not subscribed, thanks.
> >>>  > > 
> >>>  > > I have the same problem noted in
> >>>  > > 
> >>>  > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537
> >>>  > > 
> >>>  > > of frequent messages saying
> >>>  > > 
> >>>  > > acpi_tz0: _CRT value is absurd, ignored (256.0C)
> >>>  > > 
> >>>  > > on my HP nc6320 laptop, model RH383ET.
> >>>  > > 
> >>>  > 
> >>>  > I have HP 6510b and HP 2510p laptops and had same problem with those.
> >>>  > Actual problem is that the ACPI thermal code in kernel does sanity-check
> >>>  > for temperature values, and accepts only values between 0 - 200 Celsius.
> >>>  > To solve the problem you either create custom DSDT which returns 200.0C
> >>>  > value instead of 256.0C for thermal zone in question or increase the limit of
> >>>  > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c
> >>>  > function: acpi_tz_sanity).
> >>>  > 
> >>>  > Proper way to solve this in my opinion is to increase the range of
> >>>  > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at
> >>>  > least provide sysctl variable to disable thermal sanity-checks.
> >>>
> >>> Even 200C is absurd, really.  That's above the melting point of many 
> >>> types of solder (http://www.rfcafe.com/references/electrical/solder.htm) 
> >>> while 256C exceeds the melting point of _most_ types of solder.  I seem 
> >>> to recall that this limit used to be 150C, still hotter than anything 
> >>> you actually want to have anywhere on a computer board.
> >>>
> >>> No sense checking sanity to then accept insane values; fix the broken 
> >>> ASL.  256 sounds suspiciously like a byte-swapped value, perhaps?
> >>>
> >>> cheers, Ian
> >>>
> >> Getting the ASL in the actual BIOS firmware fixed would be great, but I 
> >> tried once to get Asus to correct a byte swapped value without success. 
> >> I don't suppose HP will be any more cooperative but I can try. I will 
> >> have a look at an acpidump tonight. A custom ASL would at least prove 
> >> what is wrong.
> >>
> >> Does anyone know what this value is supposed to be measuring?
> > _CRT method in ASL is supposed to return temperature (in the tenth of
> > Kelvin) at which you would like to have your computer shut down rather
> > rapidly. On my ThinkPad X60 it is 97C. 
> > 
> 
> > 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.
> 
> Yes, this is the best way instead of messing with ASL.
> 
While it is true that, unlike _PSV, _CRT should not be changed while OS
is running, it is not impossible to imagine that it could be calculated
at boot, taking into account point-in-time configuration of the hardware
(and causing EC timeout in process).

Hence, I would recommend looking into ASL anyway, at least so OP
understands what he is giving up by hardcoding the value. If I am not
mistaken, 256C should look like Return(0x14AD), which is somewhat odd a
number to say the least.

Besides, FreeBSD makes ASL overriding so easy ;)

-- 
Alexandre "Sunny" Kovalenko