3 ms·

> It seems inherently dangerous to me In the old days, it kinda was - at least to your hardware. Then people realized that blowing up components because a fan

> It seems inherently dangerous to me In the old days, it kinda was - at least to your hardware. Then people realized that blowing up components because a fan failed, or became unplugged, or a filter clogged with dust, maybe wasn't a great user experience and/or caused more in-warranty returns that required replacing hardware ($$expensive$$!), and implemented thermal throttling and thermal cutoffs. Nearly two decades ago at this point, I helped a friend diagnose his computer randomly turning off. It turned out to be a CPU fan unplugged itself, causing overheating to trigger a thermal cutoff. No other apparent harm done. Fans aren't the only means of limiting heat: slowing stuff down and turning stuff off also works. And it turns out users sometimes would rather stuff run slow than run loud, and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail - for whatever network-connected bloatware syncs your RGB lighting and fan settings to the cloud. And they will do exactly that, if that's what's required to give their customers what they want. Just exposing fan RPMs to userspace might be far less dangerous.

deathanatos 4y ago
> and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail This wasn't the suggestion I was making. I was suggesting that the motherboard, itself, should be controlling the fan RPMs (or should at least provide such a mode). I don't feel like taking a temperature input, and mapping that to an RPM output should take much circuitry at all, but it that (somehow) required a full-blown CPU, I was thinking a (very small) auxiliary chip, dedicated to the task. But yes, if you're going to do it on the main CPU, then in userspace. But now you incur all the problems I mentioned in the original comment, some of which can exhibit death spirals: CPU has to throttle due to heat, meaning less CPU time, meaning it will take longer to get to the code responsible for alleviating the problem of heat by notching the RPM up! In the worse case, you hit the CPU's critical trip point before the problem can be brought under control.
- wtallis 4y ago
  On typical desktop motherboards, the Super IO chip handles all the temperature monitoring and fan control. Those chips usually have a few modes to configure some very simple control system for mapping temperature inputs to fan speed outputs (never anything as advanced as a PID controller). The main problem is that the Super IO only has access to the temperature sensors on the motherboard itself, and on the CPU (these days, through PECI). There's no standard way for the Super IO to do out of band monitoring of temperatures on your GPU or storage drives, so if you want those to affect fan speeds you need to implement it in software. Servers typically have BMCs controlling fans, and even Apple's x86 machines have their SMC; in both cases you typically see a more thorough monitoring of component temperatures, configured out of the box with a proper awareness of which fans are blowing across which components. But that stuff doesn't trickle down to the build your own desktop market.
  - deathanatos 4y ago
    Hmm. I guess I have no idea how this chip interfaces with the kernel then? The only knobs that seem to be documented to exist ever are direct RPM controls for manual control. I know it's possible (despite the insistence to the contrary on the other thread), as basically every laptop does it. Only do desktops seem to struggle with this concept.
    - wtallis 4y ago
      How fan control is configured depends on the SuperIO chip, so it's different for eg. Fintek SuperIOs than for Winbond/Nuvoton SuperIOs. On Linux, a supported SuperIO will be exposed as a directory under /sys/class/hwmon. On one of my systems, the SuperIO is a Nuvoton NCT6791, so the relevant driver documentation is https://www.kernel.org/doc/Documentation/hwmon/nct6775 https://www.kernel.org/doc/Documentation/hwmon/nct6775 Relevant sysfs files to note are pwm[1-7]_mode to toggle between DC voltage and PWM control, and pwm[1-7]_enable to switch between full speed, pure software speed control, and several Nuvoton-specific automatic speed control modes.
- MaulingMonkey 4y ago
LorenPechtel 4y ago
Yup, I got random thermal shutoffs. The pump in the water cooling loop had failed.

deathanatos 4y ago

> and maybe your crappy motherboard vendor shouldn't be writing a ton of code running in kernel space - with all the potential stability and security issues that might entail This wasn't the suggestion I was making. I was suggesting that the motherboard, itself, should be controlling the fan RPMs (or should at least provide such a mode). I don't feel like taking a temperature input, and mapping that to an RPM output should take much circuitry at all, but it that (somehow) required a full-blown CPU, I was thinking a (very small) auxiliary chip, dedicated to the task. But yes, if you're going to do it on the main CPU, then in userspace. But now you incur all the problems I mentioned in the original comment, some of which can exhibit death spirals: CPU has to throttle due to heat, meaning less CPU time, meaning it will take longer to get to the code responsible for alleviating the problem of heat by notching the RPM up! In the worse case, you hit the CPU's critical trip point before the problem can be brought under control.

wtallis 4y ago
On typical desktop motherboards, the Super IO chip handles all the temperature monitoring and fan control. Those chips usually have a few modes to configure some very simple control system for mapping temperature inputs to fan speed outputs (never anything as advanced as a PID controller). The main problem is that the Super IO only has access to the temperature sensors on the motherboard itself, and on the CPU (these days, through PECI). There's no standard way for the Super IO to do out of band monitoring of temperatures on your GPU or storage drives, so if you want those to affect fan speeds you need to implement it in software. Servers typically have BMCs controlling fans, and even Apple's x86 machines have their SMC; in both cases you typically see a more thorough monitoring of component temperatures, configured out of the box with a proper awareness of which fans are blowing across which components. But that stuff doesn't trickle down to the build your own desktop market.
- deathanatos 4y ago
  Hmm. I guess I have no idea how this chip interfaces with the kernel then? The only knobs that seem to be documented to exist ever are direct RPM controls for manual control. I know it's possible (despite the insistence to the contrary on the other thread), as basically every laptop does it. Only do desktops seem to struggle with this concept.
  - wtallis 4y ago
    How fan control is configured depends on the SuperIO chip, so it's different for eg. Fintek SuperIOs than for Winbond/Nuvoton SuperIOs. On Linux, a supported SuperIO will be exposed as a directory under /sys/class/hwmon. On one of my systems, the SuperIO is a Nuvoton NCT6791, so the relevant driver documentation is https://www.kernel.org/doc/Documentation/hwmon/nct6775 https://www.kernel.org/doc/Documentation/hwmon/nct6775 Relevant sysfs files to note are pwm[1-7]_mode to toggle between DC voltage and PWM control, and pwm[1-7]_enable to switch between full speed, pure software speed control, and several Nuvoton-specific automatic speed control modes.
MaulingMonkey 4y ago

LorenPechtel 4y ago

Yup, I got random thermal shutoffs. The pump in the water cooling loop had failed.