FS#66104 - [cpupower] All CPUs on max frequency when upgraded to 5.6 on 5.5.13 kernel
Attached to Project:
Community Packages
Opened by Marcin Rzeźnicki (mrzeznicki) - Saturday, 04 April 2020, 00:14 GMT
Last edited by Sébastien Luttringer (seblu) - Thursday, 09 April 2020, 19:44 GMT
Opened by Marcin Rzeźnicki (mrzeznicki) - Saturday, 04 April 2020, 00:14 GMT
Last edited by Sébastien Luttringer (seblu) - Thursday, 09 April 2020, 19:44 GMT
|
Details
Description:
It probably does *NOT* make sense to upgrade the package to 5.6 when the kernel remains 5.5.x . In my case all CPUs stay on the maximum frequency constantly after the upgrade from 5.5 (measured by powertop). It very likely works with 5.6.x kernels (?) but upgrading this package BEFORE the kernel gets upgraded does not seem right Additional info: * package version(s) cpupower - 5.6 linux - 5.5.13.arch2-1 * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: Upgrade the package, listen to your fans, notice something is wrong, fire powertop or anything that shows you CPU freqs, downgrade |
This task depends upon
Closed by Sébastien Luttringer (seblu)
Thursday, 09 April 2020, 19:44 GMT
Reason for closing: Won't fix
Thursday, 09 April 2020, 19:44 GMT
Reason for closing: Won't fix
In any case - the bug is that Intel CPUs are locked to the highest frequency once cpupower is upgraded to 5.6 (it's apparently Intel's thing - AMDs seem to work fine). The question is if it goes away "magically" with a kernel update
Anyway, dependencies (sysfs, procfs, syscalls) doesn't mean we have to deal with them in packaging.
IMHO, the solution adopted by kernel developers is far better than your proposal.
When tools/ was added, the upstream said something like, in-tree tools should behave like out-of-tree tools (e.g btrfs, ethtool) and adapt their behavior to the running kernel.
They can safely be used on older kernels and new versions fixes issues for all kernels.
So, I will reconsider upgrade policy if there is a change from upstream.
Finally, if you think there is a compatibility issue with an older running kernel version, you may help upstream to fix it by reporting it.
Ok, if this is the policy then it was just a bug then and it had, in fact, nothing to do with packaging. Cpupower did not adapt its behavor and, in my experience, it was not the first time. Many thanks for the explanation. I think there is no reason to keep this "bug" around then. Thank you
Even right now.
dolores ~ 0 $ uname -a
Linux dolores 5.5.0-seblu #1 SMP PREEMPT Tue Jan 28 05:37:52 CET 2020 x86_64 GNU/Linux
dolores ~ $ btrfs version
btrfs-progs v5.6
dolores ~ $ cpupower -v
cpupower 5.6-1
Report errors and bugs to linux-pm@vger.kernel.org, please.