This failure is against 2.6.10 - 2.6.11-rc3

Did it work properly before 2.6.10.
Does it work properly with newer kernels, such as 2.6.13?

This happens for me in 2.6.13 on an Asus A8N-SLI Deluxe with Athlon 64 3500+ on
x86_64.

ACPI: Fan [FAN] (on)
ACPI: CPU0 (power states: C1[C1])
ACPI: Thermal Zone [THRM] (40 C)

The CPU temperature is definitely not always 40C.. It's possible that ACPI/BIOS
is reporting a bogus/fake value for this number..

This is probably a BIOS issue. 
I saw a lot machines with: 
if (something_checked){ 
     return 40 degrees statically 
} 
code in the DSDT. 
Could you post acpidmp output please. 
I expect that on some machines temperature is read out another way than through 
ACPI. (It's even on my workstation, also a x86_64...). 
This probably can be closed as invalid/won't fix, after reviewing DSDT. 

Created attachment 6295 [details]
ACPI DSDT from Asus A8N-SLI Deluxe

Here is the DSDT from my Asus A8N-SLI Deluxe which always reports a temperature
of 40C in the thermal zone.

I'm not seeing any immediately obvious static return value in the decompiled
code, but I don't know AML very well :-)

Sorry, but it is quite obvious:

            Method (_TMP, 0, NotSerialized)
            {
                And (SENF, 0x01, Local6)
                If (LEqual (Local6, 0x01))
                {
                    Return (RTMP ())
                }
                Else
                {
                    Return (0x0B86)
                }
            }

Still it seems as if it does not go into the else path or temp should be 22 C?
0xB86 10/Kelvin = 2950 10/Kelvin = 295 Kelvin = 22 C
Have I calculated something wrong?

There is another possiblity:
The method RTMP does not return a temperature value at all in one case.
I have searched in kernel with which value temperature gets initialised, but it
seems to be in deeper stages than thermal.c?

So this is a wontfix/invalid.
However if you like we could remove two if clauses so that the code goes through
where the temperature is evaluated, ignoring some checks which I have no idea
what they are good for (on your own risk of course).

Yeah, it does not go into the else path in that method - it seems it must go
into RTMP and see this code:

        If (LEqual (SSHU, 0x01))
        {
            Return (0x0C3C)
        }
        Else
        {
            Return (Local0)
        }

The SSHU bit is a field in a system memory operation region, if it is 1 then the
value of 40.2 degrees is always returned. Therefore I assume this must be what
is happening.

Actually Thomas it seems you already figured this out on the exact same board, lol:

http://lists.suse.com/archive/suse-amd64/2005-Feb/0287.html

This is with BIOS 1013, I see that 1014 is out but it is supposed to only
"support new CPUs" so it likely would make no difference here..

Who knows if this is the same cause as the original reporter, however. That
machine seems to have a SiS760 chipset, so it won't be an NVIDIA-specific issue.
Maybe it is Award that is writing this stuff?

Actually, looking deeper it appears that Pavilion t730 has an K8S-LA board made
by Asus, so maybe it's just their fault :-)

I really like to know whether you get sane values if you tweak the code to go
into the else path...
If you use a SUSE system it's easy to modify and override the DSDT.
You find a description how to do that here:
http://powersave.sourceforge.net/powersave/DSDT.html#DSDT (15.2)
Not sure whether it was SUSE 9.2 or 9.3, the Goldmaster kernel had a bug in
overriding the DSDT. Just install the latest update kernel then (what you should
do anyways :) ).

Seems as if those DSDTs are skeletons for a lot of different mainboards/hardware
configurations. Seems as if they check for a specific hardware and if the bit is
set try to get the value from there..., but fixed values for temperature do
never make much sense and error or zero would be nicer...

Just an idea, but I could imagine this could be just fixed (unfortunately not in
kernel as the DSDT is broken) by throwing out the if statement and overriding
the DSDT through initrd.

It's possible that SSHU bit is set by BIOS - please check if your BIOS has any 
OS-related settings. 'Windows' could be safer.