I have a Broadwell Xeon machine that I have been running Fedora on for many years. I upgraded to Fedora 41 recently and that went fine. Last night I updated to the latest kernel, 6.12.13-200.fc41.x86_64, and now the fans run continuously. Previously they did not even come on when I had 21 threads running folding and now they are on even when that isn’t running. top shows nothing running. The system is headless and has no GPU. Any idea what might have changed in this latest kernel? The temp is reported as 22000 at idle whereas it would be something like 42000 when running 21 threads of protein folding.
Check powertop Powertop - ArchWiki
It has a tab that shows what states your CPU(s) are in. On idle load, they should drop down to the deep (C6-7) idle states.
As for ‘what changed’, check what else was updated, e.g. updated microcode/firmware can also be an issue, e.g. eliminate if it’s only the updated kernel.
Check if your cpu governor hasn’t changed, that too can be an issue.
For the kernel version you list, you can see what commits are included here
https://fr2.rpmfind.net/linux/RPM/fedora/updates/testing/41/x86_64/Packages/k/kernel-doc-6.12.13-200.fc41.noarch.html
If you grep Intel, there’s several matches that can be a further lead.
Thanks. Looking at powertop I see the cpus all at 1.2GHz (minimum for the CPU) and 99% in C6. Idle as anything. The last dnf update I did only had 2 or 3 packages including the kernel because I had done an update a few days before that updated a bunch of stuff (but not the kernel at that time). I would not expect a microcode update for this old cpu at this point and I haven’t changed any platform firmware in years. I confirmed that the governor is still set to powersave on all the cores. One of the commits I noticed mentioned the PCH. That has the highest temp in the system being at 41 c, which is fine. All this is convincing me more and more that something that went into this most recent kernel update has either broken something, or is over-reacting to the PCH temperature. Up to this point I had been assuming that the UEFI was controlling the fans, am I mistaken? Has the kernel taken it over?
Hmm. I rebooted into the previous kernel, which was 6.12.11-200.fc41.x86_64 and that is still showing the problem. I even went back to 6.12.10-200.fc41.x86_64 and the fan is still pegged there, too. So now I’m kind of stumped. At least I can rule out the kernel. Thanks for your help. I’ve got a puzzle to solve.
Final update: booting back to the 6.12.13-200.fc41.x86_64 kernel and the problem is no longer seen! Further evidence of it not being related to the kernel.
Perhaps the update caused temperature readings or the decision heuristics to trigger fans to get corrupted/misread?
If it reappears, you can override it Fan speed control - ArchWiki , though ideally eliminating the cause would be preferable.
It appears that it was a coincidence that a fan began failing that perhaps went over the edge as a consequence of the reboot performed during the update. The sdr report from ipmitool made that more apparent. I am completely convinced that there never was a kernel problem. I was just misled by the coincidental failure.
1 Like