Monitor CPU and GPU fan RPM on Clevo laptops

Martin said:
This needs to be checked, because it should work.
Please attach 2 debug files created when:
1. Start HWiNFO when dGPU is off, open sensors and launch an application which enables dGPU. Do you see dGPU information? Then please close HWiNFO and get the DBG file.
2. Start an application using the dGPU and make sure it's enabled. Launch HWiNFO and perform the same procedure as above.
Also, please attach a screenshot of the entire sensors screen (showing all values displayed) when the dGPU is active and you don't see its values in HWiNFO.

Sorry mate, I'm double busy working on other beta's for the SM range, I haven't had time to do this yet - sorry.
Martin said:
Do you know of other Clevo models where this fan speed reading can be applied too (P150EM, P151EM1, P180HM maybe) ?

Please try this build:
and let me know if it works...

Hi Martin,
here's Martin from Germany and I own a Clevo W370ET (Schenker mysn XMG A722), checked the EC register and the fan-speed seems to be at the same offset as in the initial post with the same calculation rule (32768 * 60) / N_ticks) for the rotation speed.

But there's one difference:
The Clevo W350ET (15") / W370ET (17") don't have a separate fan for cpu and gpu but 1 cooler with 1 fan and 2 cooling pads - 1 pad for gpu the other for the cpu.

I noticed the following values
Embedded Controller I/O space (EC_SC/EC_DATA=0066/0062) at following byte offsets: CPU/GPU Fan: D0 D1
00 00 ==> 0 RPM (fan off - idle)
06 09 ==> 1273 RPM (fan slow speed - less cooling)
02 E8 ==> 2643 RPM (fan mid speed - moderate cooling)
02 73 ==> 3135 RPM (fan higher speed - more cooling)

(fyi: the byte-offset D2 D3 is always 00 00)

As the above mentioned beta isn't available for download and testing any more, could you please add the Clevo W350ET/W370ET with the combined CPU/GPU fan, too?

HWInfo Short Report:
Computer: Clevo W35_37ET
CPU: Intel Core i7-3632QM (Ivy Bridge-MB SV, E1)
2200 MHz (22.00x100.0) @ 1197 MHz (12.00x99.8)
Motherboard: Clevo W35_37ET
Chipset: Intel HM77 (Panther Point)
Memory: 16384 MBytes @ 798 MHz, 10.0-10-10-27
- 8192 MB PC12800 DDR3 SDRAM - Corsair CMSX8GX3M1A1600C10
- 8192 MB PC12800 DDR3 SDRAM - Corsair CMSX8GX3M1A1600C10
Graphics: Intel Ivy Bridge-MB GT2 - Integrated Graphics Controller [E1/L1/N0/P0] [CLEVO/KAPOK COMPUTER]
Intel HD Graphics 4000, 2112 MB
Graphics: nVidia GeForce GTX 660M [Clevo]
nVIDIA GeForce GTX 660M, 2048 MB

If you need further information, please let me know.
I use to read the ec-information.

Hi Martin,
thanks for the information. So the method to read fan speed is still the same, I just need to add your model to the list. Please attach a full HWiNFO report file, so I can do that based on information from that report.
Martin said:
Please attach a full HWiNFO report file, so I can do that based on information from that report.

Oh, that was really fast response! :)

I've added a full report but excluded user- and computer-name ... ;)


  • Clevo W370ET.HTM
    154.6 KB · Views: 9
Thanks. The next HWiNFO build released should support monitoring of fan speed on W350/370 models.
Great! I'm looking forward to test the new release.

Do you already have a rough idea when you will release the next (beta) version with the fan support for the W370ET?
Yes - I REALLY need it!! :cool:
Actually I'm tuning my rainmeter skin and it would be great, if I could integrate this feature already.
Thank you very much - it works just fine!

As previously posted, the CPU-load rises a bit (around 5-10% in 1 of 8 possible cpu-threads) with the fan reading activated.
Do you see a chance to get this fan speed value on another, less cpu consuming way, too?
Where (and how) should I have a look at to figure this out?

And additional, please could you tell me, if the readout of the values through the rainmeter-plugin is independend:
1. for every value (on demand, it's possible to set up separate cycles for every value).
2. of the update cycle of the sensor-screen, which has to run in background.

The fan speed doesn't change very often. So could I set the reading of the fan speed to i.e. 10 seconds with the main cycle set to 2 seconds?
By now it seems to me, that the sensor settings in HWinfo define the cycle to read out the values and write the information in a shared memory buffer.
And the cycle-settings in rainmeter or gadget just define the read out from this memory buffer.

There is one updatecycle for the sensors in the hwinfo program, another for the HWinfo-gadget and another one, you could set up in rainmeter.
It's a bit confusing to me.
I could test it out, but it seems easier to me to ask the developer. :D

Many questions ... ;)
I like your program very much and the possibilities giving it to me to control my PC.
I can try one modification, that might reduce the load by 1/2, but not more. Unfortunately the protocol used to access EC is such badly designed.
The physical sensor scan interval doesn't depend on a plugin, but HWiNFO. So all sensors are scanned in intervals defined in HWiNFO/Sensors, though particular plugins might display values less-frequent, but not more than what's set in HWiNFO. And there's just one update cycle period defined in HWiNFO for all sensors.
Would be great to reduce the load. How would you realize this?
Really would like to test this ...

I think, it also (even if you are able to reduce the load) would be a good feature enhancement, if you could add an optional and customizeable call-divisor for the cpu consuming EC-check (could be placed after the checkbox for "EC Support" in the options menu).
For example, if the Users sets a divisor "5" here, the ec-information is only updated every 5th main-update-cycle.

I found another issue for the clevo:
There might be a possible pch temp offset ~30°C(?). Directly after PC-start HWinfo shows PCH-Temp at ~58°C (cold boot after 30 seconds boot time) and in idle it goes slowly to ~82°C.
I will check this the next days with suspended to ram and cooled down PC.

And I haven't given up searching more sensor information - but it's hard work, because I've not found any documentation, yet.

But one after the other ... ;)


Just played Assassin's Creed III with the FAN readout through EC activated.
There's a lag (0.5 sec), every time the EC ist read out, what makes the game unplayable. Everything works fine, if you just deactivate EC readout.
In normal desktop work there's no adverse effect noticeable with EC.
But in gaming (and maybe other multithreaded tasks) the EC-readout is not acceptable ...
Seems to be better with this build. Could you tell me, what you have done or changed in this build?
I've made the gaming test again and the lagging is reduced but not gone.
I really don't understand why there's a lag. During gaming the cores are at max. 60-70% cpu load.
There have to be enough ressources left for the ec readout (5-10% in 1 core).

Would it be a possible solution to reduce the prozess priority from normal to low?

I've found a service manual for the board with schematic diagrams (to big to attach - 5.5MB).
Would it be helpfull for you to find another possible way to read out the fan-speed?
Or do you think, there's no other way than the EC?

I don't understand this in the schematics at all:
The CPU_FANSEN is connected with IT8518 (the EC) on ( PD )TACH0/GPD6 (48)
And on PantherPoint (U18F) there' a TACH0 / GPIO17 -> DGPU_PWROK (D40)

Is this the same as in the HWinfo-log:
- Cooling Device
- Type: Power Supply Fan
- Description: Cooling Dev 1
- Status: OK

Maybe I'm talking bullshit ... ;)

Btw. there doesn't seem to be an offset in PCH temp. It really seems to be as hot as shown in HWinfo (>80°C).
I have reduced the amount of communication with the EC in this case.
The problem is not that the method would cause high CPU load, but it requires to block the system for a short while, so that it avoids possible conflicts with other subsystems like ACPI.
I don't know of another way to communicate with the EC than the current one, though the IT8518 might offer an alternate backdoor method to do this. Will have to check the documents... Does the service manual describe commands used to communicate with the EC (Compal service manuals usually include this) ?
OK - I understand - I also found a thread in another forum, where you discussed this.

I attached the Schematic Diagrams, cutted off the manual.
Yellow marks on the things I found:
Fan: Pages 2, 31, 38
Tach0: Pages 27, 38
I hope it could give you a hint.

I searched the internet but mostly only found, that many people are looking for a way to access the EC or a way to access this information through ACPI.
No manuals or datasheets to find for this EC in the internet.
The EC is used in many newer Notebooks.
And the P-Series Clevo (and more?) seem to work nearly the same.

Could this thread give you an idea?

I really like to help as much as possible.


  • CLEVO W370ETService Manual - App B Schematics.pdf
    1.1 MB · Views: 5
Thanks for the information, I'll have a look at it.
Btw, do you have the "Evaluate ACPI Methods" option enabled ? A side-effect of this option is, that it should improve (reduce) the system blocking during EC access.

EDIT: It's true that ACPI accesses the EC when it's requested to. It uses the same method as HWiNFO does, however it's a closed subsystem. The BIOS defines methods using ACPI AML/ASL code which is then processed by the ACPI driver. So when the BIOS defines, that the system needs to access the EC when a certain event occurs, the ACPI driver performs this operation. The problem is that other applications have no access to the ACPI subsystem, so they can't utilize it to send commands to the EC.
The "Evaluate ACPI Methods" option is and was enabled.
And also: EC Support, SW SMI, Audio Codec Check

And there's no way to get information from the ACPI-driver? We don't want to set something, we just want to get an information. Is there no shared information buffer, register or something like that, where information can get from?
I understand ACPI only from user side. Sorry, if that is a dumb question.

Btw, am I right to have to disable CPU Clock Measurement "From Bus Clock" if I want to have a watchdog on Thermal Throtteling?
No, there's no way to interact with the ACPI driver in a custom way. It's a closed system. Even reading the fan speed from EC requires sending data to the EC to request the particular register content.

I strongly advise to enable the "From Bus Clock" option. Having this option disabled can cause similar periodic system lags as you experience because of EC communication. Maybe the lags occur because you have that option disabled and not because of EC ?