Monitor CPU and GPU fan RPM on Clevo laptops

[Martin]

Thanks, I think I'm starting to understand what happens there
"GPU VID" is always the iGPU value. There are 2 problems however:
1. There seems to be a problem with reading of GPU VID straight from the CPU - sometimes it returns 0 V.
2. The position of this value is sometimes wrong because of other sensors appearing/disappearing.

The fact that with disabled nVidia GPU during HWiNFO start the GPU VID appears after some time (and as the last entry in the sensors list) is related to the 1st problem. But I might have a workaround for this (even though the hardware seems to return 0V sometimes).

When you see the "GPU VID" entry, do you see it fluctuating between 0 V and the correct value ?

 

[Martin]

Please try this build: www.hwinfo.com/beta/hw64_423_1988.zip
and let me know if you see a difference in the GPU VID behavior. Before using this build, make sure to Restore Original Order.

 

[demattin]

When you see the "GPU VID" entry, do you see it fluctuating between 0 V and the correct value ?

No. The value is always "0" during runtime. It never changes to another value over hours.
But the very first value sometimes is different (0.9V or 0.4V).
As I remember, this (correct) value is only displayed, when I start HWinfo the first time after reboot or have a longer pause between stop and start again of HWinfo.
This has to be the reason why there is mostly a max Value 0,9V in the sensors screen.

And the GPU VID mostly needs some cycles to come up after starting HWinfo.
Sometimes, when I stop HWinfo and start it some seconds later again, it appears instantly. Btw this is the same with the Clevo-Fan-sensor.

I'm at work now and will test the new beta this afternoon.
Thanks!

 

[Martin]

Any results using the new build? I might need a new Debug File created using that build.

 

[demattin]

Tested the new Beta and try to describe as much as possible:

Fresh start of the cold Notebook.
HWinfo not in Autostart.
updated hwinfo64.exe and .ini to default beta version
started hwinfo gadget
start of hwinfo 64.exe
configured debug-log
started sensors
closed hwinfo overview

GPU VID came up with 2nd update cycle in the CPU section - before that, there was a blank line at the position where it then came up.
Now the VID value sometimes shows another value but mostly is "0".
Curious: the "minimum value" in the sensor list isn't 0 but a bigger value (now at 0.450V).
NV Sensors only section header is shown

Clevo CPU Temp came up instantly, Fanspeed needed many cycles but then came up at the previously left free line in the clevo EC section.

Then activated the NV GPU.
NV Sensors were shown at the bottom of the sensor list.
Restored original order
Everything fine, but CPU VID Line gone! (hmm, I missed to have a look at the bottom of the list)
Deactivated NV GPU
GPU VID came up again at the bottom of the sensor list (behaves as before - mostly 0 but sometimes a 0,xxx value)
NV GPU sensors are all at 0
restored original order
NV GPU sensors gone away (but section header remains)
GPU VID at the correct place.

closed HWino
wrote this down ...
restarted HWinfo - click "run" (damn, wanted something others ...)
stoped hwinfo
restarted HWinfo - "activated sensors only" - clicked "run"
let PC run a while (GPU VID sometimes other than 0)
activated NV GPU.
GPU VID is further been shown in gadget and sensors list and changes value between 0 an 0.9!
in sensors this GPU vid is at correct position!
NV Values are shown (in sensors list at bottom under battery state)
deactivated NV GPU
NV GPU values got to 0 and are further shown in sensors and gadget.
reordered sensors to default.
NV sensors gone

reactivated NV GPU
reordered sensors to default
now EVERYTHINK is fine and at right place.

stop and end of logfile ...

puhhh ...
I think now at this state everythink is ok.
in first start of NV it is possible, that NV GPU has been shown at the bottom of the sensors list, may be, I didn't have a look at a bottom of the list ...

I wrote a debugging file with the above described scenario.

Hope this could help you to find the problem.

Edit: Now I restarted HWinfo to use it normally (only sensors) and I waited a long time. GPU VID wasn't shown.
Made a reorder and some cycles later GPU VID appears (maybe by chance?!) at the bottom of the sensors list.

 

[Martin]

Thanks for your detailed report, it helps me to understand what's going on there and I can analyze the DBG file produced.

My concern was the fluctuation of GPU VID, so I added retries in that build - HWiNFO attempts to retry reading the GPU VID value when it gets 0 back. This is done 20 times max per each cycle, if the value is still 0, then it gives up for that cycle. So this seems to helped a bit, since at least sometimes you get a non-zero value. I'm not sure what more I could do about this, since it seems to be a problem of the iGPU. Raising the number of retries might on the other hand cause a higher system load...

As for the sensor item order, once HWiNFO sees all values, it remembers their positions (when you close the window using the "Save & Close" button), so after the values should no longer change their positions.

BTW, I have also checked readout of the EC values for fan speed. HWiNFO doesn't get any errors back when reading this. Only at the end of the dump I see it reads 0 from the EC. I'm not sure why this happens, but I doubt there's anything I can do about this.

 

[demattin]

I don't think, it's a good idea to leave the 20 times rereads in the release version of HWinfo.
Now, in actual session, the value of GPU VID stucks for a long time on 0.
1 or 2 times in release version are ok and for testing the 20 retries were ok to see, if it helps.
If my or the board is the problem and some values are not reliable, it's better to ignore this problem (and perhaps deactivate the sensor by user), I think.
HWinfo is a tool for the background execution and high system load (without reliable values) isn't a good idea for a release version.

The problem, that the Fan sensor comes up very late, is acceptable but I think about it, to deactivate this clevo sensors in normal use because of the system lags.

So if you have no further idea, I am at the point to give it up ...

 

[Martin]

So regarding the appearance of GPU VID values, do you actually see reporting valid (non-zero) values more frequently with the latest build, or you don't see any significant difference ?
I believe those 20 retries should have no significant impact on system load, maybe even 100 might still be OK. You should be able to measure this anyway.

 

[demattin]

At first start (with the debug logs), the value was approx. 4/5 the cycle on 0 and 1/5 on the correct value.
Some times 7 cycles on 0 and sometimes only 1.

But after that, I started with "sensors only" for normal use and I never saw a value different from 0 for 2 hours until shut down of PC.

If it doesn't influence load, may have a try with 100 retries?
Or a version, where I can set it on my own and try the best value?

Thanks!

 

[Martin]

OK, here's a build with 100 retries: www.hwinfo.com/beta/hw64_423_1991.zip
Please let me know how it behaves, but I personally don't like the idea of so many retries and would keep it only in case of a significant success ratio.

 

[demattin]

Tested the 423_1990 at first with cold boot.
The Clevo Sensors came up instantly.
VID behaves as usual.
Checked with update interval of 200ms -> no change.
Sometimes there is another value seen, but mostly it's 0.

Then the 423_1991 beta:
GPU VID at first isn't seen but there was a blank line at the place, where it should be.
After some cycles it came up with "0".
Sometimes another value. But not more often than before.

So no remarkable improvement with this higher retry rate and this doesn't solve the problem.

The mystic is, that the min value of GPU VID is different from 0 with any build.
Do you ignore 0 here or where does this come from?

 

[Martin]

So it seems the retries have no remarkable impact, I'll remove them. It's the true value that the iGPU reports, so I can't do much about that...
Yes, the value of 0 is ignored, because it's considered as invalid.

 

[demattin]

I have to say thanks to all the work you had with this problem!
It is a great thing, that the Fan sensor now works and I can log this on demand.
You do a great job here.
Thank you!

 

[Martin]

You're welcome.

 

[demattin]

Hello Martin,
I made a firmware update to the modded Prema-FW and the Clevo-sensor hasn't been shown any more due to the changed board identification.
In this FW the identifier of the clevo has changed to "Clevo W370ET".
Could you please add this board /identifier as well?

And the identical 15" Board is named "Clevo W350ET". You may add this too, because it works the same.

I added a full report for reference.

Thanks,
Martin

 

[Martin]

OK, I'll add those.

 

[lfodor]

Hey Martin,


Thanks for a really great piece of software. I recently bought a new laptop based on Clevo W370ST and the fan support is gone. Is it possible to add this to the list of supported laptops? I have added a report, if it helps.

 

[Martin]

I can only try to add fan speed monitoring for this model, but no fan control.

 

[lfodor]

I can only try to add fan speed monitoring for this model, but no fan control.

Thanks, being able to log and monitor the fan speeds may help me understand why in some situations the fans just go ahead and spin out like crazy even though i barely use any resources.

As a side note, how come no tool is able to control the fans on Clevo laptops?

 

[Martin]

Please try the new Beta released (build 2017).

It's because no one knows how to control those fans - the method is Clevo-proprietary and not disclosed.