Bug 13747
Summary: | temperature always reported as 27°C on Acer Aspire One (D150-1577) | ||
---|---|---|---|
Product: | ACPI | Reporter: | Jonathan (dzhonw) |
Component: | BIOS | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED DOCUMENTED | ||
Severity: | normal | CC: | jdelvare, lenb, rui.zhang, vajorie |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.30.1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
acpidump
customized DSDT customized DSDT |
Description
Jonathan
2009-07-08 21:08:11 UTC
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. |