Fancontrol
Matt Dreher
I've been running through the fan control guide in the wiki, and reading most every post here on fan control without finding any solutions to this problem... Here are my notes on my setup from pwmconfig and sensors output:
So lm-sensors seems to work, and pwmconfig seems to spin down the right fans. Now, after pwmconfig has run through the tests, I say that pwm1 should be controlled by temp1, while pwm2 should be controlled by temp2, set interval, save and quit. Then I try starting fancontrol, it reads everything up until FCTEMPS, where I get an error. The FCTEMPS line has a + between the two fans controlled by pwm2, could this be the problem? Does anyone have a similar setup (two fans controlled by one pwm2 and one temp2, and a third fan controlled by pwm1 and temp1) and an /etc/fancontrol which displays this setup? Basically it seems to me pwmconfig is not writing the right /etc/fancontrol syntax for two fans on one pwm.
It is usually better to copy the changed service file to /etc/systemd/system . Because service files in that folder get priority over other service files with the same name. The service files in /usr/lib/systemd/system/ usually get overridden with updates without any notice.
All systemd services that are enabled are started simultaneously. But a service can have dependencies, that forces a service to wait for a different service to be started. There are different types of options that can be used to create a dependencies and a fixed start order.
For example Requires=, Wants= or Before=, After=
Just one note to your step 1. It is usually better to copy the changed service file to /etc/systemd/system . Because service files in that folder get priority over other service files with the same name. The service files in /usr/lib/systemd/system/ usually get overridden with updates without any notice.
@xabbu
Thanks for the suggestions and improvements. I will update the solution to reflect this. Also: I had set the Requires and After, but it seemed to ignore it. It still ran fancontrol.service before lm_sensors.service even though I put Requires=lm_sensors.service and After=lm_sensors.service. IDK what was up with that, but for now my system is doing what I want it to do (which is why I moved to Linux in the first place, I decide what I want). If I have to re-do the service after updates then I can live with that. Thanks for the comment!
After building myself a shiny new machine, I wondered if there was any way to fiddle with the fan settings from a GUI. I came across lots that pointed to pwmconfig, lm-sensors, fancontrol, etc and some that pointed to fancontrol-gui which sits on...
I have a Raspberry Pi 4 with Adafruit's Official Case fan, and am running Ubuntu 20.10. I have installed the pi-fancontrol snap, but I can't get it configured using the instructions at -fancontrol/ubuntu.
Once the sensors are properly configured, use pwmconfig(8) to test and configure fan speed control. Following the guide should create /etc/fancontrol, a customized configuration file. In the guide, the default answers are in parenthesis if you press enter without typing anything. Enter y for yes, n for no.
Some users may want to manually tweak the configuration file after running pwmconfig with root privileges, usually to fix something. For manually tweaking the /etc/fancontrol configuration file, see fancontrol(8) for the variable definitions.
A properly configured setup will not output errors and will take control of the system fans. Users should hear system fans starting shortly after executing this command. fancontrol can also be run by starting/enabling fancontrol.service.
Unfortunately, fancontrol does not work after suspending. As per the filed bug, you will have to restart fancontrol after suspending. This can be achieved automatically by a systemd hook.
NBFC is a cross-platform fan control solution for notebooks. It comes with a powerful configuration system, which allows to adjust it to many different notebook models, including some of the latest ones.
NBFC comes with pre-made profiles. You can find them in /opt/nbfc/Configs/ directory. When applying them, use the exact profile name without a file extension (e.g. some profile.xml becomes "some profile").
i8kutils is a daemon to configure fan speed according to CPU temperatures on some Dell Inspiron and Latitude laptops. It uses the /proc/i8k interface provided by the i8k driver (an alias for dell_smm_hwmon). Results will vary depending on the exact model of laptop.
The temperature points at which the fan changes speed can be adjusted in the configuration file /etc/i8kutils/i8kmon.conf. Only three fans speeds are supported (high, low, and off). Look for a section similar to the following:
This example starts the fan at low speed when the CPU temperature reaches 55 C, switching to high speed at 75 C. The fan will switch back to low speed once the temperature drops to 65 C, and turns off completely at 45 C.
Some newer laptops have BIOS fan control in place which will override the OS level fan control. To test if this the case, run i8kmon with verbose mode in a command line, make sure the CPU is idle, then see if the fan is turned off or turned down accordingly.
To configure the temperature thresholds, you will need to copy the example configuration file (/usr/share/doc/thinkfan/examples/thinkfan.yaml) to /etc/thinkfan.conf, and modify to taste. This file specifies which sensors to read, and which interface to use to control the fan. Some systems have /proc/acpi/ibm/fan and /proc/acpi/ibm/thermal available; on others, you will need to specify something like:
The tool Lenovo Legion Linux allows to change the fan curves that are stored in the embedded controller. It consists of a kernel module that must be compiled and loaded. Currently, there is no package, but it must be compiled and installed from source.
In configuration files, we are going to use full paths to sysfs files (e.g. /sys/devices/platform/asus-nb-wmi/hwmon/hwmon[[:print:]]*/pwm1). This is because hwmon1 might change to any other number after reboot. Fancontrol (lm-sensors) is written in Bash, so using these paths in configuration file is completely acceptable. You can find complete /etc/fancontrol configuration file examples at ASUS N550JV#Fan control.
asus-nb-wmi is a kernel module, which is included in the Linux kernel and is loaded automatically on ASUS laptops. It will only allow to control a single fan and if there is a second fan you will not have any controls over it. Note that blacklisting this module will prevent keyboard backlight to work.
Once you are done and the configuration file is generated, you should stop the first and second consoles. Continue with #Fancontrol (lm-sensors). After the configuration file is generated, you might need to manually replace PWM values with full sysfs paths as they are used in these steps, because hwmon number values might change after reboot.
If the above methods do not work for you, an alternative method is to directly write to certain registers in the embedded controller (EC). Using the EC-Probe tool, you can set the fan mode to one of the three fan speed modes, provided your model offers such feature in Windows.
Instead of manually controlling fan speed using asus-nb-wmi, it is also possible to set the thermal throttling policy to have a more or less aggressive fan control policy. Possible values are 0 (default), 1 (overboost), and 2 (silent).
You can view the value changing as you use press Fn+F5. 0 is "Normal Mode", 1 is "Performance Mode", 2 is most likely "Silent Mode".[2] It is also possible to write these values into the fan_boost_mode file as root and have the desired effect.
The amdgpu-fanAUR package is an automated fan controller for AMDGPU-enabled video cards written in Python. It uses a "speed-matrix" to match the frequency of the fans with the temperature of the GPU, for example:
The bash script amdgpu-fancontrol by grmat offers a fully automatic fan control by using the described sysfs hwmon functionality. It also allows to comfortably adjust the fancurve's temperature/PWM cycles assignments and a hysteresis by offering abstracted configuration fields at the top of the script.
For safety reasons, the script sets fan control again to auto when shutting down. This may cause spinning up of fans, which can be worked around at cost of security by setting set_fanmode 1 in the section function reset_on_fail.
To start the script, it is recommend to do so via systemd init system. This way the script's verbose output can be read via journalctl/systemctl status. For this purpose, a .service unit file is already included in the GitHub repository.
The enumerated hwmon symlinks located in /sys/class/hwmon/ might vary in order because the kernel modules do not load in a consistent order per boot. Because of this, it may cause fancontrol to not function correctly. The error is "Configuration appears to be outdated, please run pwmconfig again". Upstream bug.
In /etc/conf.d/lm_sensors, there are 2 arrays that list all of the modules detected when you execute sensors-detect. These get loaded in by fancontrol. If the file does not exist, run sensors-detect as root, accepting the defaults. Open (or create) /etc/modules-load.d/modules.conf. Get all of the modules listed from the 2 variables in /etc/conf.d/lm_sensors/ and place them into the /etc/modules-load.d/modules.conf file, one module per line. Specifying them like this should make a defined order for the modules to load in, which should make the hwmon paths stay where they are and not change orders for every boot. If this does not work, I highly recommend finding another program to control your fans. If you cannot find any, then you could try using the alternative solution below.
Using absolute file paths in fancontrol does not work by default, as its helper script pwmconfig is programmed to only use the hwmon paths to get the files. The way it does this is that it detects whether the hwmon path that is provided in its configuration file /etc/fancontrol did not change, and uses the variables DEVNAME and DEVPATH to determine such change. If your hwmon paths keep changing, this will prevent fancontrol from running no matter what you do. However, one can circumvent this problem. Open /usr/bin/fancontrol, and comment out this part of the script:
d3342ee215