Appears to be a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=11563 , except for the fan issue?

please attach your acpidump output

Created attachment 22286 [details]
acpidump

            Method (_TMP, 0, Serialized)
            {
                If (DTSE)
                {
                    If (LGreaterEqual (DTS1, DTS2))
                    {
                        Return (Add (0x0AAC, Multiply (DTS1, 0x0A)))
                    }

                    Return (Add (0x0AAC, Multiply (DTS2, 0x0A)))
                }

                Return (0x0BB8)
            }

it seems that DTSE is not set by the BIOS.

Jonathan,
could you please check your BIOS options and see if there is anything related with thermal management.
you can also try to blacklist the hwmon driver and see if it helps.

Created attachment 22287 [details]
customized DSDT

if none of them helps, please try this customized DSDT.

Blacklisting the "hwmon" driver is never going to have any effect, as this driver is loaded as a dependency and not by modalias.

Also note that Jonathan did not mention any hwmon-class driver being used on his system to start with. This could be verified easily with the output of "lsmod" or the listing of /sys/class/hwmon. But at this point it seems to be a pure ACPI issue.

I'm pretty sure my BIOS options have nothing related to thermal management (the first thing I did when I noticed the problem was to check that).

The hwmon code is compiled into my kernel.  I'll set it up as a module and see what happens without it.

What's the customised DSDT do?

I just double-checked the BIOS: nothing at all thermal-related.

A lot of stuff seems to depend on hwmon.  What would removing/blacklisting it accomplish?

the customized DSDT just changes the _TMP method to:
            Method (_TMP, 0, Serialized)
            {
                    If (LGreaterEqual (DTS1, DTS2))
                    {
                        Return (Add (0x0AAC, Multiply (DTS1, 0x0A)))
                    }

                    Return (Add (0x0AAC, Multiply (DTS2, 0x0A)))
            }
Now _TMP will return a temperature represent by DTS1 and DTS2 rather than a constant, even if DTSE is not set by BIOS.

(In reply to comment #8)
> A lot of stuff seems to depend on hwmon.  What would removing/blacklisting it
> accomplish?

add one item in /etc/modprobe.d/blacklist and reboot?

My guess is that DTSE is a flag to be set by a platform specific driver
to enable the Digital Thermal Sensors, since it is in a physical
memory region called "MBOX" with a bunch of other flags...

    OperationRegion (MBOX, SystemMemory, 0x7F6BEE10, 0x00000112)
    Field (MBOX, AnyAcc, NoLock, Preserve)
    {
        PCI1,   8,
        PCI2,   8,
        PCI3,   8,
        PCI4,   8,
        PCI5,   8,
        PCI6,   8,
        PCI7,   8,
        PCI8,   8,
        NLCK,   8,
        ZIPE,   8,
        COMA,   8,
        CAIO,   8,
        CAIP,   8,
 ...

        DTSE,   8,

I would think that if this were enbaled by BIOS SETUP,
that the flags would exist as a bit in CMOS, but it is
always possible that CMOS bits are expanded into this
memory at startup...

Of course this also means as a workaround,
that you could write a small driver
to set DTSE, or scribble on physical memory, to set this flag
to enable access to the thermal sensors...

I would also check that you're running the latest BIOS --
it is possible that this is simply an incomplete feature.

Rui, could you add this DSDT hack to the customised DSDT you posted at http://bugzilla.kernel.org/show_bug.cgi?id=13802 ?  I'd like to try both hacks together.

Created attachment 22436 [details]
customized DSDT

done. please give it a try

That apparently makes the sensor read 0°C.

it seems that both DTSE/DTS1/DTS2 is zero after system boot.
can you please check if there is any BIOS update available?

I don't see a Linux bug here, closing as Documented.

Please re-open if I missed something.