acpi method access (thermal zone _TMP)


Nice product I am looking for an accurate/reliable/logging tool to replace
(speedfan, nhc, HWmonitor...) a couple of questions

1. acpi method evaluation and logging
Specifically following _TMP method accessible in other products

rationale is that I want to modify acpi for better fan control so first want to
be able to monitor; this is for a sony vaio laptop which I believe has embedded
control so easier to access acpi for temp data
2 timestamp of sensor data
report file does not seem to timestamp the data (I infer from other posts
that fixed poll is 1s) this would be useful for excel analysis

Regards, Paul

ps. not yet sure if hwinfo is responsible but since I have been trying hwinfo have
seen BSOD's when I put laptop to sleep
IMAGE_NAME: acpi.sys
A driver is causing an inconsistent power state.
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 85768b70, Physical Device Object of the stack
Arg3: 85767318, Functional Device Object of the stack
Arg4: 859f07f8, The blocked IRP
not sure if hwinfo ACPI aml enumeration could be responsible


  • tz.jpg
    15.2 KB · Views: 1,157

HWiNFO32 currently doesn't support reading of ACPI _TMP method.
I can add timestamps to logfile for sensor data.
Hard to say if HWiNFO32 is causing the BSOD, but I don't think the AML enum might cause this. You can try to disable this option in HWiNFO32 and then check if the problem persists. Also please send me a Report + Debug file, so I can check better the system configuration.

Thanks for the quick reply
I have uploaded dbg & report files to
<!-- m --><a class="postlink" href=""></a><!-- m -->
<!-- m --><a class="postlink" href=""></a><!-- m -->
I do not know if these reveal other sensors from which I might obtain same data as acpi _TMP ?
[I was also running other monitoring product so I am not sure HWinfo is responsible for bsod]

Cheers, Paul
Thanks for the data. Currently HWiNFO32 can display CPU temperature only on this machine, but there might be a way how to read sensor data from EC, however it would require you to supply additional data which I would need to analyse:
- Download and run the RW-Everything tool: <!-- m --><a class="postlink" href=""></a><!-- m -->
- Press the EC (Embedded Controller) button to dump data
- Send me the dump
then I can check if it's possible to use a direct EC-read method..
the ascii ec file is at

<!-- m --><a class="postlink" href=""></a><!-- m -->

[The disassembled method for
Method (_TMP, 0, Serialized)

Store (\_SB.PCI0.LPCB.EC.TS1R, Local0)
If (And (Local0, 0x80))
Subtract (Local0, 0x0100, Local0)

shows use of TS1R
which is at an offset oX40 in
OperationRegion (ECF2, EmbeddedControl, 0x00, 0xFF)
Field (ECF2, ByteAcc, Lock, Preserve)
Offset (0x40),
TS1R, 8,

and embedded controller data as visualized in rw utility shows continuous update
of value at 0x40 in the range x34-x36 which seems it might be the temp I want ? ]

Thanks, Paul
Hi Paul,

thanks for the data! Yes, that's exactly what I'm looking for.
Unfortunately after analysing other VAIO dumps, it seems that different models have these data at different EC offsets (I was hoping VAIO series to be compatible), so I'll need to add support per each model.
Could you please attach the complete DSDT decoded dump, so I can verify other values too?

Thanks very much seems to work fine, new sony vaoi ec section reports cpu
temp which is same as _TMP method

1. ec Mainboard reading seems unchanging what does it correspond to
2. ec Temp3 sensor value was not in initial graphic but was added dynamically by HWinfo

I guess it is monitoring a range of ec addresses for changes ? ; maybe interesting to see offset address being monitored

Also since _TMP method had some 'IF' clauses eg
Method (_TMP, 0, Serialized)
Store (\_SB.PCI0.LPCB.EC.TS1R, Local0)
If (And (Local0, 0x80))

I did check out with RW tool memory dump that DTSE is 0 and ECON 1 so the value used is from TS1R .. but maybe you coded complete algorithm ?

log file now also has timestamp - thanks again and is reporting the new cpu temp
Sensors @ 19.07.2010 09:04:45

"CPU#0 Core0","47.0 °C"
"CPU#0 Core1","45.0 °C"
"CPU","54.0 °C"
"Mainboard","51.0 °C"

I'll continue to test

Thanks, Paul


  • tz1.jpg
    33.4 KB · Views: 1,140
The "Mainboard" reading is just my guess, it's the value of TS2R (0x42), the 3rd Temperature is TS3R (0x44). I don't know the real meaning of these values and I have no idea how to determine this.
I suppose ECON determines if the EC is running/enabled and DTSE if CPU DTS (Digital Thermal Sensor) is available.
According to the screenshot you attached there seems to be an issue with the reading of values - sometimes it returns invalid data (2 - 240 C, you can notice this by the Min/Max values). I don't know yet why this happens :( Maybe it should be watched via the RW tool if the data are sometimes erratic, or it's an issue in my EC code. It might also happen in case there are more applications running concurently that access the EC.