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) } }
Will you please attach the output of acpidump?
Please check if it's a duplicate of bug 9167?
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.
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.
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.
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.
Created attachment 16709 [details] Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 1
Created attachment 16710 [details] Output of "acpidump --addr 0xff810 --length 0x50 -o TEMP" from computer 2
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.
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.
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
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.
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. :)