Bug 11010 - ACPI does not report correct temperature, fan is always on
ACPI does not report correct temperature, fan is always on
Status: REJECTED INVALID
Product: ACPI
Classification: Unclassified
Component: Power-Thermal
All Linux
: P1 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-29 15:51 UTC by Adolf Winterer
Modified: 2008-07-14 00:52 UTC (History)
3 users (show)

See Also:
Kernel Version: Seen in 2.6.22, 2.6.24 and 2.6.25
Tree: Mainline
Regression: ---


Attachments
acpidump of DSDT from computer 1 (18 month old Shuttle) (16.63 KB, application/octet-stream)
2008-07-01 03:38 UTC, Adolf Winterer
Details
acpidump of DSDT from computer 2 (brand new Shuttle) (16.71 KB, application/octet-stream)
2008-07-01 03:39 UTC, Adolf Winterer
Details
Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 1 (80 bytes, application/octet-stream)
2008-07-03 03:18 UTC, Adolf Winterer
Details
Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 2 (80 bytes, application/octet-stream)
2008-07-03 03:19 UTC, Adolf Winterer
Details

Description Adolf Winterer 2008-06-29 15:51:44 UTC
Latest working kernel version: -
Earliest failing kernel version: 2.6.22
Distribution: Debian
Hardware Environment: Two different Shuttle Barebones, Intel Core 2 Duo
Software Environment: 64Bit
Problem Description: The temperature reported in /proc/acpi/thermal_zone/THRM/temperature is always a fixed value, never changes while the sensors tool reports correct and changing values. The fan is always on. /proc/acpi/thermal_zone/THRM/polling_frequency always reports <polling disabled>.

Steps to reproduce: It does not matter if the system is freshly installed or not, it does not matter if the system had performed a cold or warm boot, it is always the same. Different kernel versions did not matter either (tested with 2.6.22, 2.6.24 and 2.6.25 from Debian (Lenny and Sid). Older versions do not work on the computer because of the SATA hardware.

For this problem there is a bug open in the Debian bug tracker: #487287.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487287
I was asked be Maximilian Attems to open a bug report here.

When I use iasl to disassemble the dsdt found in /proc/acpi/dsdt and recompile it I get one warning and two errors which look quite similar on both machines.

# iasl -sa dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20061109 [May 15 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl   378:     Method (\_WAK, 1, NotSerialized)
Warning  1079 -                 ^ Reserved method must return a value (_WAK)

dsdt.dsl   419:             Store (Local0, Local0)
Error    4049 -                         ^ Method local variable is not 
initialized (Local0)

dsdt.dsl   424:             Store (Local0, Local0)
Error    4049 -                         ^ Method local variable is not 
initialized (Local0)

ASL Input:  dsdt.dsl - 5129 lines, 163766 bytes, 1797 keywords
Compilation complete. 2 Errors, 1 Warnings, 0 Remarks, 571 Optimizations

I found a suggestion how to fix the warning on the net, but did not find anything for the errors. The code with the errors looks like that:

Scope (\_SI)
{
    Method (_MSG, 1, NotSerialized)
    {
        Store (Local0, Local0)
    }
     Method (_SST, 1, NotSerialized)
    {
        Store (Local0, Local0)
    }
}
Comment 1 ykzhao 2008-06-29 23:10:12 UTC
Will you please attach the output of acpidump?


Comment 2 Zhang Rui 2008-06-29 23:50:55 UTC
Please check if it's a duplicate of bug 9167?
Comment 3 Adolf Winterer 2008-07-01 03:38:02 UTC
Created attachment 16671 [details]
acpidump of DSDT from computer 1 (18 month old Shuttle)

This is the dump of the DSDT of my older Shuttle (about 18 months old), it reports a constant temperature of -73 C. The file has been created with the tool acpidump.
Comment 4 Adolf Winterer 2008-07-01 03:39:38 UTC
Created attachment 16672 [details]
acpidump of DSDT from computer 2 (brand new Shuttle)

This is the dump of my latest Shuttle barebone, it always reports a constant temperature of 40 C. The file has been created with the acpidump tool.
Comment 5 Adolf Winterer 2008-07-01 04:06:04 UTC
There is some similarity to bug 9167, but it is not quite the same. The common components are the DSDT compile errors and the fixed value in the temperature file.

One big difference is 32 vs 64 bit. I did boot my new system (attached DSDT file labelled "computer 2") with a Knoppix 5.3 DVD, which is 32 bits (only 3.25 GB of memory recognized then). But there is no difference in behaviour in comparison to the installed 64 bit version. The temperature is still reported to be 40 C and it doesn't change, polling_frequency also is disabled. In both (32 and 64 bit versions) I can echo "1" into polling_frequency, which will show "1 seconds" as content then, but it does have no effect at all.

In bug 9167 there was one trip_point only, I see three:
# cat /proc/acpi/thermal_zone/THRM/trip_points
critical (S5):           60 C
passive:                 50 C: tc1=4 tc2=3 tsp=60 devices=CPU0
active[0]:               50 C: devices= FAN

I had no overheating as the case fan is alwas on, the CPU fans seem to be working correctly.

On "computer 1" sensors is installed, it reports correct values:
# sensors
it8712-isa-0290
Adapter: ISA adapter
VCore 1:     +1.15 V  (min =  +0.00 V, max =  +4.08 V)
VCore 2:     +1.57 V  (min =  +0.00 V, max =  +4.08 V)
+3.3V:       +3.39 V  (min =  +0.00 V, max =  +4.08 V)
+5V:         +5.05 V  (min =  +0.00 V, max =  +6.85 V)
+12V:       +12.29 V  (min =  +0.00 V, max = +16.32 V)
-12V:       -20.61 V  (min = -27.36 V, max =  +3.93 V)
-5V:         -5.74 V  (min = -13.64 V, max =  +4.03 V)
Stdby:       +5.08 V  (min =  +0.00 V, max =  +6.80 V)
VBat:        +3.22 V
fan1:       1480 RPM  (min =    0 RPM, div = 8)
fan2:          0 RPM  (min =    0 RPM, div = 8)
fan3:       1074 RPM  (min =    0 RPM, div = 8)
M/B Temp:    -55.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = transistor
CPU Temp:    -55.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = transistor
Temp3:       +46.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = transistor
cpu0_vid:   +1.219 V

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +46.0°C  (crit = +85.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +48.0°C  (crit = +85.0°C)

Finally, I did not suffer any thermal shutdowns on any of the two computers.
Comment 6 ykzhao 2008-07-03 00:40:22 UTC
Hi, Adolf
    From the acpidump in comment #4 there doesn't exist the any object that can be used to turn on/off the FAN device. For example: _PS0/_PS3/_PR0
 >Device (FAN)
        {
            Name (_HID, EisaId ("PNP0C0B"))
            Method (_INI, 0, NotSerialized)
            {
                Store (TP1H, CTOS)
                Store (TP1L, CTHY)
 >           }

   According to the description it seems that the temperature always returns 40 in the new BIOS(comment #4). IMO this is also related with the bogus BIOS.
   The RTMP object will be called by _TMP object and the definition of RTMP is listed in the following:
    Method (RTMP, 0, NotSerialized)
    {.....
        If (LEqual (SSHU, 0x01))
        {
            Return (0x0C3C) // IF the SSHU is 1, the temperature will 40.
        }
        Else
        {
            Return (Local0)
        }
    }
   
    Anyway will you please attach the following output?
    acpidump --addr 0xff810 --length 0x50 -o TEMP

    The outputs on the two computers are both required.

   Thanks.

    

Comment 7 Adolf Winterer 2008-07-03 03:18:46 UTC
Created attachment 16709 [details]
Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 1
Comment 8 Adolf Winterer 2008-07-03 03:19:47 UTC
Created attachment 16710 [details]
Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 2
Comment 9 ykzhao 2008-07-03 20:09:58 UTC
Thanks for the info.
From the attached info the bug we can confirm that the issue is caused by the broken BIOS.
On the two computers as the SENF in BIOS is one, the RTMP object will be called in the _TMP object. 
For the bios of computer1: 
     As the SSHU is zero, the RTMP object will get the temperature by using the value returned by GBYT object, which is related with BIOS. As the value returned by GBYT object is totally controlled by BIOS, it can't be fixed in Linux kernel.
    >If (LEqual (SSHU, 0x01)){
            Return (0x0C3C)
        }Else  {
            Return (Local0) // the local0 is related with the GBYT object.
     >   }

For the bios of computer2:
    As the SSHU is zero, the RTMP object will always return 0xC3C, which means that it is 40 degree.
   
    So IMO this bug is caused by broken BIOS and had better be fixed by BIOS upgrading.
Comment 10 Zhang Rui 2008-07-06 22:39:03 UTC
Hi, Adolf,
please check if there are any BIOS options that related to thermal/fan cotnrol.
If yes, please set them to different values and see if it helps.
Comment 11 Adolf Winterer 2008-07-07 06:45:51 UTC
Today I did some tests with BIOS settings on "computer 1" which were quite interesting.

There are five modes that can be set under "Advanced CPU Fan Setting".
Smart Fan Mode
Ultra-Low Fan Speed
Low Fan Speed
Mid Fan Speed
Full Fan Speed
eXtreme PC Mode

Changing the mode changes the speed the CPU and case fans are running immediately, right away. CPU temperature and the temperature in the case change accordingly.

Smart Fan Mode is the system's default setup, I had been using it with all prior tests. Here is a list of readings I got when using a mode for about 15 minutes allowing the thermal situation to settle.

Smart Fan Mode
    CPU temperature   : 57° C
    System temperature: 44° C
    Fan 1 speed       : 1620 RPM
    Fan 3 speed       : 4195 RPM
Ultra-Low Fan Speed
    CPU temperature   : 58° C
    System temperature: 45° C
    Fan 1 speed       : 1620 RPM
    Fan 3 speed       : 4200 RPM
Low Fan Speed
    CPU temperature   : 54° C
    System temperature: 42° C
    Fan 1 speed       : 2000 RPM
    Fan 3 speed       : 4150 RPM
Mid Fan Speed
    CPU temperature   : 49° C
    System temperature: 38° C
    Fan 1 speed       : 3075 RPM
    Fan 3 speed       : 4100 RPM
Full Fan Speed
    CPU temperature   : 48° C
    System temperature: 36° C
    Fan 1 speed       : 3685 RPM
    Fan 3 speed       : 4060 RPM
eXtreme PC Mode
    CPU temperature   : 62° C
    System temperature: 48° C
    Fan 1 speed       : 1290 RPM
    Fan 3 speed       : 4225 RPM

Fan 1 is the case fan, fan 2 does not exist, fan 3 is the CPU fan.

Until I did these tests I had assumed that fan 3 is the case fan and fan 1 is the CPU fan. But the tests proved it is the other way around.

Booting into Linux with a setting other than the default "Smart Fan Mode" did not change anything in the values found in /proc/acpi. 

From what I see I conclude that the fans are purely under control of the BIOS and the operating system and its services have no say whatsoever. The different fan mode settings are different profiles specifying something like a desired fan speed and / or temperature.

"Computer 2" has even more settings for the fans, actually there are two lists of modes that can be combined! I will play around with these a bit more but up to now the findings from "computer 1" seem to apply to "computer 2" as well.

I found that there are BIOS files available for the two systems. I ordered a USB floppy so that I can do a test with a more recent BIOS version. But given the results of the latest tests I do not expect a change in the behaviour.

BIOS for "computer 1":
http://global.shuttle.com/download03.jsp?PI=247

BIOS for "computer 2":
http://global.shuttle.com/download03.jsp?PI=638
Comment 12 Zhang Rui 2008-07-07 19:54:56 UTC
Device (FAN)
        {
            Name (_HID, EisaId ("PNP0C0B"))
            Method (_INI, 0, NotSerialized)
            {
                Store (TP1H, CTOS)
                Store (TP1L, CTHY)
            }
        }
This is the AML code describing the ACPI fan device on your computer.
Yes, it's a ACPI fan device, but it doesn't export any methods to control the fan, which means ACPI knows the fan but can do nothing on it.
This is same for both computer1 and computer2.
Comment 13 Zhang Rui 2008-07-14 00:52:49 UTC
As the fans are under control of BIOS, close this bug and mark it as INVALID.

Please re-open it if you still have any questions. :)

Note You need to log in before you can comment on or make changes to this bug.