Automatic fan control is provided only WHILE using chrultrabook-tools_2.8.1_amd64.AppImage, running MrChromebox-2405.0 firmware on CachyOS. I can see the fan RPM change wrt CPU temp in realtime while using the app and running stress -c 8.
Automatic fan control is not working as expected when NOT using the app while stressing the system. The fan doesn’t change RPM as can be heard or felt physically (fan RPM monitoring is missing on Linux for this SuperIO, which sensors-detect as
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... Yes
Found unknown chip with ID 0x2011
Manual fan control works with ectool fanduty, but ectool autofancntrl does not work as expected.
I understand that as with most GUIs on Linux, they interface with the underlying command line utility, ectool in this case.
As this is my first ChromeOS turned Linux device, I’m still finding my way around. Without clear understanding on how exactly the GUI translates the controls into call to the ectool command line utility, this is how exactly automatic fan control behaves:
Start by stressing the system with stress -c 8.
10mins into the stress test, notice that the CPU temp fluctuates between a concerning 80 to 89 C, sometimes reaching as high as 90+
The fan at this point remains silent, and not ramping up to MAX RPM for the given CPU temperatures.
Invoking ectool autofanctrl as root DOES NOTHING to ram up the fan to MAX RPM, despite running the stress 10mins at this point. Only ectool fanduty 100 makes the fan work to MAX RPM.
Running ectool autofanctrl after manually setting fan duty to 100 makes the fan fallback to its RPM BEFORE fan duty was set, which is very silent for the running CPU temps.
At this point the app is NOT started yet. So we start the app. Et voila, now the fan ramps up to MAX RPM, then gradually falls back as soon as the stress command is terminated. It was only thru the app that I get to see current fan RPM values, which at the moment I haven’t found how to translate into the corresponding ectool command.
Please advise on how to further troubleshoot this issue, as running without the app makes the fan not spin up according to the increasing or decreasing CPU temps.
I wish to clarify that the issue here is not merely seeing the fan ramp to max RPM. The issue is that the fan does NOT change RPM even while the system is under heavy load. It should already be audible when the CPU temp is going up. The fan only stays silent without audible changes.
Only when the app is run does the fan truly functions automatically. Audible fan changes can be heard and RPM can be seen changing in the app when the system is stressed.
And when the app is terminated, the fan ceases to automatically spin up or down wrt to increasing or decreasing CPU temp.
I’ll have to try and reproduce this on WYVERN, but don’t believe I was able to last time I tried. I’m not sure what would be different on DUFFY, though it does look like the ECRW fw is older than the ECRO, so that may need an update
Thank you. I’m ready to provide debugging info as needed, and looking forward to having a working AFC without the intervention of another app/appimage, or if need be then create a service unit to provide the non-working function.
I’d like to add that ectool console shows a lot of Fan 0 stalled! output despite the CPU temps idling between 43 to 47 C. This is without the appimage running, and the system has just been booted and is left idling for some minutes.
Thank you for sharing your similar experience regarding the issue.
I have tried the commands, but they did not change what I was hoping to achieve – a sane automatic fan control that changes speed proportional to the change in CPU temperature. And I may have found some reasonable explanation to this behavior.
It seems that the fan RPM is based on the sensor reported by ectool temps 0. This sensor is in degrees Kelvin, however, it doesn’t show the same temps as that from the coretemp module. For example at peak temp of 327 K, which translates to 53.85 C, coretemp reading is at 73 C.
Moreover, the temp I got from ectool changes much slowly and in increments of 1 K, which means the fan also changes in small increments and never reaching RPMs in the 3000s or even 4000s, despite coretemp showing temperatures of 70+ C.
Also, when I try to query ectool thermalget:
sensor warn high halt fan_off fan_max name
0 0 341 351 314 345 Core
EC result 3 (INVALID_PARAM)
(all temps in degrees Kelvin)
I’m not sure if that INVALID_PARAM is indicative of some issue, but it returns only sensor.
So it isn’t that automatic fan control doesn’t work at all, it’s just that it works albeit in small increments for it to be noticeable and make a difference in keeping the CPU cool during heavy workloads. And this is due, it seems, to the sensor from the EC that is slow and gradual in temp changes, which the fan use as basis for determining its speed.
RW is v2.0.4736, RO is v2.0.4638. Maybe you meant RW (4736) is NEWER than RO (4638)? How do we update ECRO? Does it need to match ECRW version?
Yes it looks like the app is setting fan speed manually, even though it has an AUTO / OFF / MAX settings, and a curve where you can manually set speed based on temp.
I made the comment on the slow sensor because this is what I observed when I made a script that gets ectool temps 0 and ectool pwmgetfanrpm for every second while stressing the system. Fan RPM changed gradually as soon as the EC temp sensor was incremented by 1 K.
That’s exactly what you want if you always set the fan speed point blank based off of the temp (specifically the cpu temp), that speed is going to be constantly jumping around, as temperature is very dependent on what load it’s running.
Hehe, well I wouldn’t want that as well – fan that is jumping around as soon as the CPU temp rise or fall. The point of the observation was to highlight that because the EC temp sensor is somehow indicating temps that are much lower than the coretemp kernel module, the fan speed is thus not performing as to cooling down the CPU when under load.
To put this into perspective, I also own a Lenovo ThinkCentre M920q Tiny. In its BIOS is an Intelligent Cooling Engine (ICE), which is just a fancy term for setting fan speed performance into better acoustics or better thermal. I set it for the latter. When I stress test that system, the fan kicks into high gear in a couple of seconds and you can hear the sound coming from that tiny CPU like that of a jet engine. It’s that loud. And as soon as I end the test, the fan gradually comes back down. This change isn’t instantaneous, no fan jumping arouond, and best of all BIOS controls fan performance according to what one desires, better acoustic or better thermals.
Yep, sounds like your device takes into account cpu percentage when setting fan speeds. It knows that high cpu usage = more heat, so they take that into account. I don’t believe Chromebooks with full rom do this
has nothing to do with Full ROM or not, different devices use different inputs/methods for thermal management.
no, I misread and was only looking at the last 2 digits. ECRW is supposed to be equal to or newer than ECRO. I can try updating the ECRW regardless of it already being newer than ECRO.
I’ll be glad to try whatever you could come up with, just to have the fan work like how it is with other systems implementing AFC in their BIOS implementation.
Just an added point of data. Running Windows on Duffy / Asus Chromebox 4, was getting throttled to 0.4Ghz before I found AsusFanControl to override the BIOS fan control. Willing to help/test any potential fixes. Thanks!
I don’t even know how that Asus fan control app would work, it’s almost certainly not made for ChromeOS devices and the fan interface is completely different than your typical UEFI PC.
if you always set the fan speed point blank based off of the temp (specifically the cpu temp), that speed is going to be constantly jumping around, as temperature is very dependent on what load it’s running.