Freq capped at 800 MHz

[steffen-stell]

I just installed the extension on a device. Unfortunately, the frequency is now capped at 800 MHz with noticeable performance impact, yet the sliders to set min/max frequency in the app are missing. Deactivating the extension does not change that.

System: Host: fedora Kernel: 5.11.21-300.fc34.x86_64 x86_64 bits: 64 Desktop: GNOME 40.1 Distro: Fedora release 34 (Thirty Four) Machine: Type: Desktop Mobo: Gigabyte model: Z87M-D3H v: x.x serial: UEFI: American Megatrends v: F8 date: 08/03/2013 CPU: Info: Quad Core Intel Core i7-4770 [MT MCP] speed: 798 MHz max: 800 MHz

[konkor]

I think it could be a Linux kernel issue. You can try other distro like Debian etc. Otherwise you can turn off (disable) intel_pstate driver in the kernel boot parameters if you have Intel CPU.

[iamSlightlyWind]

This is happening to me too. Used to works fine, without disabling intel_pstate at boot. btw I think disabling intel_pstate also stop you from boosting over base clock?

[konkor]

@iamSlightlyWind No, disabling intel_pstate driver doesn't affect Turbo Boost. It works fine. Just Linux kernels before 4.18 couldn't show current frequency higher of max one. It was required to use MSR kernel module to see real current frequency. Now you see real current frequency with kernel's acpi drivers too.

[CrackalackingZ]

I had the same issue, after updating to Manjaro 21.0.7 when I switched from 5.4.124-1 to 5.10.42-1, locked to 800 Mhz, cpufreq would show driver ACPI, max/min sliders gone. I tried the presets and my desktop would start to flicker and shift. I disabled the extension, which stopped the flickering and shifting. Rolled back to 5.4.124-1, re-enabled the cpufreq and everything was back working: driver Intel PState, presets, boost, sliders, etc.

[cvrobot]

Same issue.

[iamSlightlyWind]

Same issue.

@cvrobot this might be solved by adding intel_pstate=disable to your grub entry as konkor mentioned. Works on both of my laptop. One using an i7 2760qm and an i5 4200m

[cvrobot]

Fix this issue by: Step 1: sudo apt-get install acpi-support acpid acpi Step 2: edit /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"

[stillpointx]

This issue is back again after kernel update in ubuntu 20.04.3 tried

Step 1: sudo apt-get install acpi-support acpid acpi Step 2: sudo nano /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable" and tried GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=disable acpi=force" sudo update-grub

The CPU frequency is still stuck at 800mhz any other recommendations? s-tui

rt@sys76:~$ sudo journalctl -b | grep -i cpu

Sep 27 22:52:32 sys76 set-cpufreq[1527]: Setting ondemand scheduler for all CPUs
Sep 27 22:53:05 sys76 gnome-session[2981]: gnome-session-binary[2981]: WARNING: Could not parse desktop file indicator-cpufreq.desktop or it references a not found TryExec binary
Sep 27 22:53:05 sys76 gnome-session-binary[2981]: WARNING: Could not parse desktop file indicator-cpufreq.desktop or it references a not found TryExec binary
Sep 27 22:53:10 sys76 gnome-shell[3021]: Usage of object.actor is deprecated for Cpufreq
                                         _init@/home/rt/.local/share/gnome-shell/extensions/cpufreq@konkor/extension.js:128:5
                                         enable@/home/rt/.local/share/gnome-shell/extensions/cpufreq@konkor/extension.js:483:13
Sep 27 22:53:10 sys76 gnome-shell[3021]: Usage of object.actor is deprecated for Cpufreq
                                         _init@/home/rt/.local/share/gnome-shell/extensions/cpufreq@konkor/extension.js:129:5
                                         enable@/home/rt/.local/share/gnome-shell/extensions/cpufreq@konkor/extension.js:483:13

https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts-significant-throttling-of-intel-i7-processor#

[ROldenburg]

I have the same issue. Right away after enabling cpufreq the cpu ran fine but after allowing it to install helper modules, frequency got stuck at 798Mhz. What are these helper modules, can they be removed?

[Tsubajashi]

how can i remove changes made by that extension? that really just locked down my CPU to 800MHz and i really not want to reinstall.

[elcodedocle]

Same issue here, using Debian bullseye on a i5-4300U, kernel 5.10, default grub options:

I recovered by:

1. Disabling the extension
2. sudo apt install linux-cpupower
3. sudo vi /etc/default/cpupower

# Define CPUs governor
# valid governors: ondemand, performance, schedutil
governor='ondemand'

# Limit frequency range
# Valid suffixes: Hz, kHz (default), MHz, GHz, THz
min_freq="800MHz"
max_freq="2.90GHz"

# Specific frequency to be set.
# Requires userspace governor to be available.
# Do not set governor field if you use this one.
#freq=

# Utilizes cores in one processor package/socket first before processes are 
# scheduled to other processor packages/sockets.
# See man (1) CPUPOWER-SET for additional details.
#mc_scheduler=

# Utilizes thread siblings of one processor core first before processes are
# scheduled to other cores. See man (1) CPUPOWER-SET for additional details.
#smp_scheduler=

#  Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the  processor. See man (1) CPUPOWER-SET for additional details.
#perf_bias=

# vim:set ts=2 sw=2 ft=sh et:

Unfortunately as soon as I enable back the extension, I get back to being stuck at 800MHz:

I hope someone finds an easy fix for this. It looks like something that should be easy enough to tune so perhaps I'll dare to dive in and try to find a solution myself if I find the time.

BTW this is an amazing gnome extension. I have been using it for years and it works flawlessly on all my other machines and distros. Kudos to @konkor and all contributors for doing such a great job maintaining it!

[elcodedocle]

Quick workaround:

(It will be reverted back to 800MHz max as soon as I open the extension details, but I can live with that)

[elcodedocle]

So it turns out there are no scaling_available_frequencies for my scaling_driver intel_cpufreq:

I do not know how to fix this, but it is relatively easy to prevent the extension from trying to set an invalid min or max frequency when this happens, by simply checking that the available frequencies array is not empty.

The available frequencies array is populated on initialization:

And used to calculate and set the min (prf.core[key].a) and max (prf.core[key].b) frequencies for each core and profile, as well as get_freq(0) and get_freq(100):

So, by simply checking that the available frequencies array is populated before doing these operations, we can work around the issue:

This solution may be too ad-hoc. It is possible that a better way of dealing with it is something more generic that deals with the root "no scaling_available_frequencies" issue. Or falling back to minimum_freq = minfreq, maximum_freq = maxfreq, and frequencies = [minfreq, maxfreq] if (!frequencieslist), instead of returning without setting those values on get_frequencies() init function. Anyway, it works for me and it is simple enough to implement for anyone else who runs into the same issue, so I am dropping it here in case anyone else is interested.