Bug 1806246

forgot to mention driver

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 
intel_pstate

and cpu listed fine

$ cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
800163

Created attachment 1665167 [details]
dmesg.log

Created attachment 1665168 [details]
cpuinfo

result of cat /proc/cpuinfo

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.5.7-100.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

still the same with 5.5.7-100

$ uname -a
Linux happyfed 5.5.7-100.fc30.x86_64 #1 SMP Fri Feb 28 17:32:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: Invalid argument

Changing this to mate-applets. The culprit should be cpupower: Revert library ABI changes from commit ae2917093fb60bdc1ed3e in the 5.4.19 kernel, but this is reverting a change that broke ABI back in 5.0.  Unfortunately mate-cpufreq changed to go along with it, but did so in a way that doesn't actually check the ABI, only checks the kernel version.  As this patch is going back to all stable kernel releases, mate will have to change how they did their implementation.

Justin.
mate-cpufreq doesn't check for kernel version any more since 10 Aug 2019, see https://github.com/mate-desktop/mate-applets/commit/bd0cf4893b267762cd35fb68f900b4be9de81138
Is this wrong or can this be a problem?

Sorry forgot to mention because at first sight missed it.
now mate cpufreq absolutely disappeared and suppose it's their problem
-----
$ mate-cpufreq-selector 
mate-cpufreq-selector: symbol lookup error: mate-cpufreq-selector: undefined symbol: cpufreq_get_frequencies
-----

But as I understand this is absolutely related to kernel
-----
$ mate-cpufreq-selector 
mate-cpufreq-selector: symbol lookup error: mate-cpufreq-selector: undefined symbol: cpufreq_get_frequencies
-----


As result as far as I can understand in CPU power I see this
"Unable to determine current policy"

------
$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.00 GHz
  available cpufreq governors: performance powersave
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency: 800 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

------

Again sorry wrong paste about

But as I understand this is absolutely related to kernel
-----
$ cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: Invalid argument

-----

Right, so they backed out the specific version number check. It doesn't change the fact that they code still builds one way or the other. It does however make it so that it probably just needs to be recompiled with new kernel-headers, as opposed to actually changing the code. I Am not telling you that kernel did not change, I am telling you that it did change to revert an incompatible ABI change, and it is not going to undo that. There will be no fix for this in kernel, mate-applets has to make that fix.  You could probably help the maintainer out by doing a scratch rebuild of mate-applets and verifying that it does fix the issue.

I am using amd ryzen cpu for myself, in result i can't really reproduce the issue to decide that a rebuild is needed.
Anyway, i will do a rebuild for f31 and f30 branches.
Justin,
Last mate-applets build for master/f32 was from Tue, 11 Feb 2020 12:46:44 UTC https://koji.fedoraproject.org/koji/buildinfo?buildID=1458926
Do we need a rebuild for master/f32 ?

Ok, looks like that master and f32 branch needs a rebuild too.
From https://kojipkgs.fedoraproject.org//packages/mate-applets/1.24.0/1.fc32/data/logs/x86_64/root.log
DEBUG buildroot.py:517:  kernel version == 5.4.8-200.fc31.x86_64

But honestly, i don't get why a rebuild of mate-applet should fix this output.

-----
$ cat  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: Invalid argument

-----

Any way, rebuilds are on the run.

FEDORA-2020-bd957fb403 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd957fb403

FEDORA-2020-96db6b0a2b has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-96db6b0a2b

 Yura, can you please test new build of mate-applets.

Package are build against

-f30
DEBUG util.py:598:   kernel-tools-libs-devel        x86_64 5.5.6-100.fc30               build  12 k
DEBUG util.py:598:   kernel-headers                 x86_64 5.5.6-100.fc30               build 1.3 M
DEBUG util.py:598:   kernel-tools                   x86_64 5.5.6-100.fc30               build 186 k
DEBUG util.py:598:   kernel-tools-libs              x86_64 5.5.6-100.fc30               build  19 k

-f31
DEBUG util.py:598:   kernel-tools-libs-devel          x86_64   5.5.6-200.fc31         build    14 k
DEBUG util.py:598:   kernel-headers                   x86_64   5.5.6-200.fc31         build   1.2 M
DEBUG util.py:598:   kernel-tools                     x86_64   5.5.6-200.fc31         build   190 k
DEBUG util.py:598:   kernel-tools-libs                x86_64   5.5.6-200.fc31         build    21 k

And mate-applets checks for this ABI from kernel-tools-libs.

checking for cpufreq.h... yes
checking for cpupower_is_cpu_online in -lcpupower... yes
checking for cpufreq_get_frequencies in -lcpupower... no

mate-applets-1.22.2-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd957fb403

mate-applets-1.22.2-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-96db6b0a2b

Sorry for the delay.
Yes it's fixed now. Everything works fine.
kernel 5.5.8-100
mate-applets-1.22.2-2

Governor returned fine by cat command and mate cpu frequency works fine

Thank you

I am so happy that i could help you :)
Can you please leave karma at bodhi?

Can you please leave karma at bodhi?

done. it's took a while for me to realize what does it mean :)

mate-applets-1.22.2-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

mate-applets-1.22.2-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days