Created attachment 258537 [details] kernel config The 4.13 kernel with intel_pstate=passive (or active) does not appear to correctly update the CPU frequency in /proc/cpuinfo After booting the reported frequency (but not the real frequency) is stuck on one value and does not update: $ grep MHz /proc/cpuinfo cpu MHz : 2194.859 cpu MHz : 2194.859 cpu MHz : 2194.859 cpu MHz : 2194.859 hardware: ThinkPad X250 cpu: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz kernel: 4.13.3 vanilla (config attached) As far as I remember this worked in 4.11 and broke after 4.12, I can double check if needed.
That is correct, and was intentional. It just lists tsc now. To get the actual CPU frequencies, you have to use: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq Or, I guess, more correctly these days: cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq
Thanks! Didn't know about that. Resolving this now.
(In reply to Doug Smythies from comment #1) > That is correct, and was intentional. It just lists tsc now. > > To get the actual CPU frequencies, you have to use: > > cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq > > Or, I guess, more correctly these days: > > cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq They are both pointing to the same file. The former is link to the later one.
*** Bug 197017 has been marked as a duplicate of this bug. ***
I'm trying to figure out if I've hit a bug or not... My laptop CPU now doesn't seem to clock down - meaning the temps are higher and the laptop CPU fan is always running - even when idle. I noticed it used the intel_pstate driver, I disabled this and tried the acpi_cpufreq driver, however I see the following: # cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq 2828056 2890338 2889348 2800463 The frequencies supported are: 2901000 2900000 2800000 2700000 2500000 2400000 2300000 2200000 2000000 1900000 1800000 1700000 1600000 1400000 1300000 1200000 I've tried the ondemand and performance gov with no changes. Is this an actual problem (I think so), or am I checking the freq settings in the wrong place and the values displayed are making me bark up the wrong tree?
This appears to be a regression, and Linus has made it reasonably clear that he's unhappy with regressions - http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02474.html is a recent example. This breaks a bunch of userspace stuff that is relying on /proc/cpuinfo to provide an accurate, or even SLIGHTLY accurate, representation of the current CPU speed. Can this be readdressed?
As an update, this has been fixed and backported to 4.13 https://www.spinics.net/lists/stable/msg195663.html
The "fix" in 4.13.12 was undone/reversed in 4.13.13 and subsequent releases, including 4.13.14 and 4.14.0. Therefore we are back to square one with this issue, whether you call it a bug, a regression or the improvement of the code. This has a significant impact on power consumption on some machines, especially laptops and passive cooling type setups. The issue that was reported as "CPU Frequency Monitor showing the maximum frequency of the CPU in XFCE at all times" is just the tip of the iceberg. It is far from being a cosmetic issue. It functionally is very disruptive. On laptops it drains the battery at a rate far greater than normal. It makes the difference of being or not being able to use your laptop during a 4 hr flight. Going back to acpi_cpufreq instead of intel_pstate is a temporary solution on some hardware, but not always, as acpi_cpufreq doesn't seem to have the same level of power savings optimizations as in intel_pstate. What would it take to "reopen" this issue as it looks like from a "bug" point of view this is now set aside.
This ticket is specifically in regards to /proc/cpuinfo not displaying the correct speed, which is a cosmetic issue. This has nothing to do with the ACTUAL speed of the CPUs. The revert of the revert was in this commit: https://www.spinics.net/lists/stable/msg197162.html Again, this ticket is purely about a cosmetic issue. Nothing else, as you can see by the code. If you're having problems with REAL power consumption, I suggest you open a new ticket, or see if you can find an existing ticket that is your actual problem.
Hi Rob. Thanks for your message. I opened the ticket https://bugzilla.kernel.org/show_bug.cgi?id=197017 which was marked as a DUPLICATE of this ticket and closed. That's why I came here to comment and ask my question. I don't want to waste anyone's time and post in the wrong place, but in my experience the /proc/cpuinfo has ramifications beyond just the frequency meter showing the top speed CPU as opposed to the actual real time CPU speed, at least in XFCE according to my experience. Here is why? 1) Starting with 4.13.0 and with every subsequent version of the kernel (including 4.14.0), when used on Linux Mint 18.2 64bit with XFCE, it causes the "CPU Frequency Monitor" to show the top speed of the CPU, not the actual, instantaneous frequency (in average mode). Note that with any prior version, that is not the case and it works as it should. 2) Now, after I posted my bug report, I was let to understand that this was because the XFCE panel plugin read the information from the wrong location, aka "/proc/cpuinfo" rather than "/sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq". Then my bug report was marked as duplicate of this one and closed. 3) Fetching the CPU info in the wrong place might be only a "cosmetic" issue if it is not being used for anything other than just showing info on the screen. But it seems to be used for more than that. It somehow has a direct impact on "intel_pstate" driver which gets disturbed and results in far greater power consumption. When I observed that, I switched to "acpi_cpufreq" driver and the power consumption got lower but not to the minimum as it was the case with "intel_pstate" when running with an older kernel. I don't know where "acpi_cpufreq" is getting its CPU speed cue but somehow it behaves better than "intel_pstate" on this affected series of kernels. 4) The only exception to this occurrence is with kernel version 4.13.12-041312-generic #201711080535, which I currently use, and which makes my machine behave EXACTLY as it did with older kernel versions. So, for me it WAS a solution. 5) But the fix in 4.13.12 was reversed because apparently it caused to much CPU IPI, etc. I can understand that a different fix is necessary. But I question the wisdom of closing this ticket, unless there is another one that I haven't been able to find yet. As to the "cosmetic" vs "functional" aspect of the issue, it worries me even more because it sounds like I am the only one out there observing power consumption issues. Again to reiterate, on my 6 month old Intel Pentium G4560 desktop I see this issue, on my HP high end laptop with Intel i7-4710HQ, same behavior, and on a low end unbranded laptop with Intel Celeron N3450 same tune! (All three systems running Linux Mint 18.2 XFCE 64 bit in various state of update) I understand this is not a discussion forum and only bug reports should be made with useful information for the developers, and that's what I was trying to do.
For what its worth, this seems exactly like my Comment 5 above. I still have no solution or leads on how / where to follow this up.
(In reply to Steven Haigh from comment #11) > For what its worth, this seems exactly like my Comment 5 above. > > I still have no solution or leads on how / where to follow this up. Please open a separate bug entry for this.
Now, whatever is reported as "cpu MHz" in /proc/cpuinfo in 4.13 and later has a little to do with the intel_pstate driver in any case. It always comes from some code outside of this driver, this way or another. That said, there is mainline commit 7d5905dc14a8 (x86 / CPU: Always show current CPU frequency in /proc/cpuinfo) causing "cpu MHz" in /proc/cpuinfo to report the current frequency again. It is going to be backported to 4.13.y and 4.14.y if all goes well.
Re Comment 12 - I have lodged the issue here: https://bugzilla.kernel.org/show_bug.cgi?id=197945