I've installed Linux Kernel v.4.13.3 on my desktop running Linux Mint 18.2 Xfce (64 bit) and noticed that the CPU frequency gets stuck in the maximum position.
The processor on this computer is an Intel Pentium G4560 (Kaby Lake).
The motherboard is ASROCK B250M-HDV with BIOS updated to AMI L2.21 dated 6/27/2017, which addresses the hyper-threading issue on Kaby Lake processors.
I got 4.13.3 precompiled from:
If I run Linux Mint's stock 4.11.0-14 or 4.12.14-041214-generic from the ubuntu kernel repository above, the CPU frequency behaves normally and varies between 800MHz and 3.5GHz according to the load level.
With 4.13.3 it is always stuck at 3.5GHz
This is different from bug 121051 (Offline CPU's stick at maximum clock frequency after resume from suspend) as it happens on a fresh boot as well as resume from suspend or hibernate. The other kernels mentioned above all work well with CPU throttling, ACPI reboot, sleep/suspend mode and hibernate.
I also tried 4.13, 4.13.1 and 4.13.2; they all show the 4.13.3 symptoms.
could you please upload:
1. dmesg after boot up
2. grep . /sys/devices/system/cpu/cpu*/cpufreq/*
3. grep . /sys/devices/system/cpu/intel_pstate/* (if there is any)
4. turbostat -i 10
It looks like a regression, is it possible to do a bisect between 4.12 and 4.13?
I would need to reinstall 4.13.3 as I moved to 4.11.0-14 after the cpu frequency issue showed up. I'll get you the result of 1 through 4 later today.
I do not know how to do a bisect. I'll be happy to give a try if there is a recipe to follow. Where can I get some guidance?
Created attachment 258761 [details]
4.13.5 installation process output
Created attachment 258763 [details]
4.13.5 dmesg output
Created attachment 258765 [details]
4.13.5 grep 1 command output
Created attachment 258767 [details]
4.13.5 grep 2 output
Created attachment 258769 [details]
4.13.5 turbostat output
Created attachment 258771 [details]
cpu frequency readout
Created attachment 258773 [details]
xfce cpu frequency plugin about info
Sorry for the multi-post sequence above.
I installed 4.13.5 as it was the latest available in the 4.13 series.
The problem persists with this version too. I uploaded the visual from the CPU frequency plugin of Xfce which shows 3.50 GHz in Current Average mode. The readout never changes bit the plugin is live and not crashed as I can change its settings etc.
I wasn't able to install turbostat as you see in the output. Not sure where to find the required files for 4.13.5. It is attempting to install 4.9 material and then complains that 4.13.5 support files are missing.
Created attachment 258777 [details]
4.13.5 dmesg output
Created attachment 258779 [details]
4.13.5 dmesg output
(In reply to Hal from comment #5)
> Created attachment 258765 [details]
> 4.13.5 grep 1 command output
~ $ grep . /sys/devices/system/cpu/cpu*/cpufreq/*
it seems that the cpufreq is not stuck at 3.5G.
(In reply to Hal from comment #10)
> Sorry for the multi-post sequence above.
> I installed 4.13.5 as it was the latest available in the 4.13 series.
> The problem persists with this version too. I uploaded the visual from the
> CPU frequency plugin of Xfce which shows 3.50 GHz in Current Average mode.
> The readout never changes bit the plugin is live and not crashed as I can
> change its settings etc.
> I wasn't able to install turbostat as you see in the output. Not sure where
> to find the required files for 4.13.5. It is attempting to install 4.9
> material and then complains that 4.13.5 support files are missing.
you can build the turbostat tool from the kernel source
say you've checked out 4.13 kernel source, just
1. cd kernel_src/tools/power/x86/turbostat
3. ./turbostat -i 10
(In reply to Hal from comment #9)
> Created attachment 258773 [details]
> xfce cpu frequency plugin about info
so it is this plugin that reports the cpufrequency stuck?
is it the same plugin that reports the dynamic cpufreq which varies between 800MHz and 3.5GHz according to the load level?
I didn't look at the source code of xfce cpu frequency plugin.
But this seems to be a duplicate of bug #197153. Because the xfce cpu frequency plugin may reply on /proc/cpuinfo to report current frequency, which becomes static now.
*** This bug has been marked as a duplicate of bug 197153 ***
Or I should say this is a duplicate of bug #197009
*** This bug has been marked as a duplicate of bug 197009 ***
The xfce plug-in needs to be fixed to use
instead of the "cpu Mhz" field inside /proc/cpuinfo.
Note that was true even before Linux 4.13, as there
were already kernels and configurations where /proc/cpuinfo
would return a constant value, yet cpufreq sysfs
at least always has tried to show a current value.
Note also, that we have improved the accuracy of
cpufreq sysfs starting in Linux-4.13, so that its
value should be both meaningful and consistent.
I mentioned this on #197009 - but, to quote Linus from a couple of weeks ago:
> As far as the kernel is concerned, a regressions is THE KERNEL NOT GIVING THE
> SAME END RESULT WITH THE SAME USER SPACE.
This change certainly DOES change the end result, so (to me) it is a regression.
Sorry I was away for a while and I didn't pursue on this issue. I noted that the case is closed as duplicate but that is no help in my case.
Today I installed Kernel version 4.13.0-16 from Linux Mint's own repo with high hopes that this issue was fixed.
Alas! Same problem.
The frequency monitor in xfce is still stuck on 3.50GHz but I doubt that this is because the xfce plugin is reading the wrong value.
Simply because the CPU fan pattern is changing too as if the CPU is indeed running at 3.5GHz and causing more heat.
I went back and forth between 4.11.0-14 and 4.13.0-16 and with 4.13 the fan runs much louder. Otherwise I agree that according to /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq the frequency is changing between 800MHz and 3500MHz.
What a mess!
I'll turn to the Xfce team and see if they can be of help, but once again this is not some cosmetic issue with a GUI plugin showing the wrong data. I bet I'll see a higher power consumption if I connect my watt-meter to the AC line.
Thanks for your help though.
I found a way to mitigate the problem:
If I boot up kernel 4.13.0-16 with intel_pstate=disable I get my machine to use acpi_cpufreq which alleviates the problem. The CPU frequency monitor in Xfce shows different frequencies depending upon the load level and one can correlate the fan activity of the CPU with the intensiveness of the applications being run.
So, for now this addresses the issue although it is probably more of a band-aid than a permanent solution.
BTW, I did check the power consumption as I mentioned in my earlier post. 4.13.0-16 with intel_pstate governor definitely pulled more watts, so the CPU was most likely running at a much higher frequency than 800MHz as it was reported by /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq.
Not to kick a dead horse, but 4.11.0-14 works flawlessly on the exact same machine, so the question remains what has changed so drastically in 4.13?
Nice! Version 4.13.12 has just been released and I tested it on my system: the problem I brought up above has been fixed. Intel's intel_pstate driver works well (although I also like acpi_cpufreq after using it for a whole day).
(As a footnote; intel_pstate seems to reduce power consumption better, yet acpi_cpufreq gives more punch to the system, especially when a large app is about to start. For instance if you start video editing with kdenlive the power advantage of acpi_cpufreq is obvious. With some fine tuning it is probably possible to optimize both in their weakest areas but I only used them with their respective default settings)