Bug 197017 - CPU frequency stuck to maximum
Summary: CPU frequency stuck to maximum
Status: CLOSED DUPLICATE of bug 197009
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Chen Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-21 13:49 UTC by Hal
Modified: 2017-11-08 23:12 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.13.x
Subsystem:
Regression: No
Bisected commit-id:


Attachments
4.13.5 installation process output (4.36 KB, text/plain)
2017-10-09 16:09 UTC, Hal
Details
4.13.5 dmesg output (58.09 KB, text/plain)
2017-10-09 16:11 UTC, Hal
Details
4.13.5 grep 1 command output (3.95 KB, text/plain)
2017-10-09 16:11 UTC, Hal
Details
4.13.5 grep 2 output (358 bytes, text/plain)
2017-10-09 16:12 UTC, Hal
Details
4.13.5 turbostat output (1.28 KB, text/plain)
2017-10-09 16:13 UTC, Hal
Details
cpu frequency readout (4.41 KB, image/png)
2017-10-09 16:14 UTC, Hal
Details
xfce cpu frequency plugin about info (24.71 KB, image/png)
2017-10-09 16:15 UTC, Hal
Details
4.13.5 dmesg output (58.07 KB, text/plain)
2017-10-09 16:45 UTC, Hal
Details
4.13.5 dmesg output (58.01 KB, text/plain)
2017-10-09 16:49 UTC, Hal
Details

Description Hal 2017-09-21 13:49:20 UTC
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:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.3/

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.

Hal
Comment 1 Chen Yu 2017-10-09 06:21:57 UTC
Hi Hal,
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?
Thanks.
Comment 2 Hal 2017-10-09 15:14:51 UTC
Hello Chen,

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?

Thanks
Comment 3 Hal 2017-10-09 16:09:36 UTC
Created attachment 258761 [details]
4.13.5 installation process output
Comment 4 Hal 2017-10-09 16:11:12 UTC
Created attachment 258763 [details]
4.13.5 dmesg output
Comment 5 Hal 2017-10-09 16:11:44 UTC
Created attachment 258765 [details]
4.13.5 grep 1 command output
Comment 6 Hal 2017-10-09 16:12:22 UTC
Created attachment 258767 [details]
4.13.5 grep 2 output
Comment 7 Hal 2017-10-09 16:13:32 UTC
Created attachment 258769 [details]
4.13.5 turbostat output
Comment 8 Hal 2017-10-09 16:14:36 UTC
Created attachment 258771 [details]
cpu frequency readout
Comment 9 Hal 2017-10-09 16:15:29 UTC
Created attachment 258773 [details]
xfce cpu frequency plugin about info
Comment 10 Hal 2017-10-09 16:28:23 UTC
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.
Comment 11 Hal 2017-10-09 16:45:27 UTC
Created attachment 258777 [details]
4.13.5 dmesg output
Comment 12 Hal 2017-10-09 16:49:25 UTC
Created attachment 258779 [details]
4.13.5 dmesg output
Comment 13 Zhang Rui 2017-10-11 03:37:25 UTC
(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/*
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800007
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:853104
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:1840197
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:3115340


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
2. make
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?
Comment 14 Zhang Rui 2017-10-11 05:49:12 UTC
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 ***
Comment 15 Zhang Rui 2017-10-11 05:51:15 UTC
Or I should say this is a duplicate of bug #197009

*** This bug has been marked as a duplicate of bug 197009 ***
Comment 16 Len Brown 2017-10-17 01:18:55 UTC
The xfce plug-in needs to be fixed to use
/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
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.
Comment 17 Rob Thomas 2017-11-02 04:13:31 UTC
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.
Comment 18 Hal 2017-11-07 19:58:58 UTC
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.
Comment 19 Hal 2017-11-08 04:46:55 UTC
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?
Comment 20 Hal 2017-11-08 23:12:08 UTC
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).

Thanks everyone.

(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)

Note You need to log in before you can comment on or make changes to this bug.