Starting with Linux kernel 4.13 the current cpu frequencies are no longer exported through /proc/cpuinfo. Instead you have to use the sysfs interface. The special handling of the Intel pstate driver in the cpufreq-plugin should therefore be removed for kernels >= 4.13.
Created attachment 7465 plugin is working again. But not sure if it is proper solved I changed some lines in the code and the plugin is working again. Don't know if I made a correct modification. I have to admitt that I did not fully understand the Code. Maybe it helps ....
I think it is also sufficient just to comment out cpuFreq->intel_pstate = ips; in xfce4-cpufreq-linux.h
äh... I mean xfce4-cpufreq-linux.c
(In reply to Thomas from comment #1) > Created attachment 7465 > plugin is working again. But not sure if it is proper solved > > I changed some lines in the code and the plugin is working again. Don't know > if I made a correct modification. I have to admitt that I did not fully > understand the Code. Maybe it helps .... Thanks, works great for me :D I was trying to change the code myself.... but my skills are rusted and not like they used to be. I hope the XFCE team can fix this issue, as even I can see it's an easy to solve issue that a person who knows the code can fix in no time.
Created attachment 7538 git commit to repair intel p-state with recent linux kernels I removed extra handling of intel p-state drivers as the newer drivers are utilizing sysfs now. I did not test the code if it runs on older kernels but it should work as well since the fallback is to use /proc/cpuinfo if opening sysfs files fails.
(In reply to Timo from comment #5) > Created attachment 7538 > git commit to repair intel p-state with recent linux kernels > > I removed extra handling of intel p-state drivers as the newer drivers are > utilizing sysfs now. I did not test the code if it runs on older kernels but > it should work as well since the fallback is to use /proc/cpuinfo if opening > sysfs files fails. Cheers. Will report back, as soon as I get an update.
Funny, I have a Haswell CPU running Linux 4.15.13 and the plugin is working fine, with or without this patch (which is good thing).
(In reply to Andre Miranda from comment #7) > Funny, I have a Haswell CPU running Linux 4.15.13 and the plugin is working > fine, with or without this patch (which is good thing). Yeah indeed they changed the kernels behaviour again because many userland tools seem to rely on it and a sheer shitstorm broke loose. However, using sysfs instead of proc seems a good idea to me as proc is more or less deprecated for this purpose.
@Timo, I can't tell from your patch, but based on your comment we're safe to roll it and cpufreq is likely to work on kernels < 4.13, since it falls back to /proc/cpuinfo if sysfs is not available. Unfortunately I can't test your patch with previous kernels (boot partition full, ssd almost full, cpufreq does not work on VMs, no time to setup another machine). Therefore I would like to hear from people on this thread if cpufreq with this patch works on kernels < 4.13.
Created attachment 7662 P-State patch Since I reported the bug, I am running with this patch without problems. I just changed the order of the relevant if / else blocks, so it also falls back to /proc/cpuinfo if the sysfs interface should not be available. Timo's patch is most likely better, but consider the chunk affecting cpufreq_linux_init from my patch.
When's the next version going to be shipped? I fear I'll be in Taiwan for a business trip for a few weeks at the end of the month but if I can avoid going there I should find the time to compile a few fringe and ancient kernels and test the patch. Furthermore: What about including the ability to set the cpu frequency governors by the drop down menues? Is a non-root-user even allowed to do that using polkit or something? If that was the case I could implement setting the governors via sysfs as well.
@Ingo, your patch seems to be less risky, since it only changes the order of how the freqs reading falls back: /sys/.../cpufreq -> /sys/.../intel_pstate -> /proc/cpufreq @Timo, why remove intel_pstate handling code? Are you sure it will never be used in any case (I mean even when using old kernels provided by current distros such as CentOS)? Also, it'll be released when it's ready =) wrt the feature to change the governors, see Bug #3428. If you think it's a doable, please craft a patch, I will gladly review/test it. All in all, I'm more inclined to push Ingo's patch, unless someone reports some problem.
@André: Well, /proc is the common denominator here and will always work if sysfs doesn't provide the necessary interface. I presume the pstate driver got some extra handling because Intel makes such a fuzz about it with their pseudo frequency and cpu-internal governor and such. So somebody wanted to be prepared for everything, right? Then again, we're happy to be on Linux which does a terrific job of abstracting the hardware. In my eyes the extra handling of pstate just adds complexity without added value since it reads out /proc anyway even though it's kind of deprecated. But really I won't be upset if you favour Ingo's solution. Thanks for the link to #3428.
Timo Adler referenced this bugreport in commit 1fa2d8286dfa60abb01cb710fd3a91b31a54126c Drop Intel p-state (Bug #13835) https://git.xfce.org/panel-plugins/xfce4-cpufreq-plugin/commit?id=1fa2d8286dfa60abb01cb710fd3a91b31a54126c
Andre Miranda referenced this bugreport in commit 2410acb0bb6261f88fb16a0406a32fd6018a947d Prefer sysfs to Intel pstate in cpufreq_linux_init (Bug #13835) https://git.xfce.org/panel-plugins/xfce4-cpufreq-plugin/commit?id=2410acb0bb6261f88fb16a0406a32fd6018a947d
You (Timo) have convinced me, that portion of code is already too messy, less cruft the better. And if these changes break the plugin for anybody, we can always revert them make a new release. Thank you all for your contributions and patience, I hope to make a new release by next week, if this doesn't happen, feel free to poke me.