Bug 13747 - temperature always reported as 27°C on Acer Aspire One (D150-1577)
Summary: temperature always reported as 27°C on Acer Aspire One (D150-1577)
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-08 21:08 UTC by Jonathan
Modified: 2010-01-05 05:36 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.30.1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump (138.45 KB, text/plain)
2009-07-09 07:57 UTC, Jonathan
Details
customized DSDT (256.25 KB, application/octet-stream)
2009-07-09 08:24 UTC, Zhang Rui
Details
customized DSDT (256.26 KB, application/octet-stream)
2009-07-22 05:50 UTC, Zhang Rui
Details

Description Jonathan 2009-07-08 21:08:11 UTC
In all 2.6.29 and 2.6.30 kernels that I've tried on this machine, /proc/acpi/thermal_zone/THRM/temperature always reads 27°C.  The fan always reports "on".

The acerhdf driver does not cover this model of Aspire One, and the module's maintainer informed me that this model should have standard acpi fan and temperature support.  The acer-wmi module also doesn't recognise my hardware.

I will be happy to provide any further information, install patches, etc.
Comment 1 Jonathan 2009-07-08 21:43:53 UTC
Appears to be a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=11563 , except for the fan issue?
Comment 2 Zhang Rui 2009-07-09 01:32:09 UTC
please attach your acpidump output
Comment 3 Jonathan 2009-07-09 07:57:43 UTC
Created attachment 22286 [details]
acpidump
Comment 4 Zhang Rui 2009-07-09 08:22:04 UTC
            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.
Comment 5 Zhang Rui 2009-07-09 08:24:30 UTC
Created attachment 22287 [details]
customized DSDT

if none of them helps, please try this customized DSDT.
Comment 6 Jean Delvare 2009-07-09 08:37:07 UTC
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.
Comment 7 Jonathan 2009-07-09 08:41:58 UTC
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?
Comment 8 Jonathan 2009-07-09 08:57:29 UTC
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?
Comment 9 Zhang Rui 2009-07-10 01:08:17 UTC
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.
Comment 10 Zhang Rui 2009-07-10 01:09:46 UTC
(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?
Comment 11 Len Brown 2009-07-20 15:36:19 UTC
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.
Comment 12 Jonathan 2009-07-22 05:13:19 UTC
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.
Comment 13 Zhang Rui 2009-07-22 05:50:03 UTC
Created attachment 22436 [details]
customized DSDT

done. please give it a try
Comment 14 Jonathan 2009-07-22 15:30:55 UTC
That apparently makes the sensor read 0°C.
Comment 15 Zhang Rui 2009-12-09 07:44:58 UTC
it seems that both DTSE/DTS1/DTS2 is zero after system boot.
can you please check if there is any BIOS update available?
Comment 16 Len Brown 2009-12-15 03:03:52 UTC
I don't see a Linux bug here, closing as Documented.

Please re-open if I missed something.

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