Hi all,
I’m running ArchLinux.
I set up my FrameWork laptop back in September, and I could have sworn that the CPU frequency scaling worked correctly and went up and down depending on what I was doing.
Now, I see that that CPU frequency is locked at 2800 MHz on 7 cores, and 1 core goes down to 900 MHz
The only work around I have found is the following:
echo passive > /sys/devices/system/cpu/intel_pstate/status
cpupower frequency-set -g ondemand
With that, my frequency drops down to 400 MHz and scales up under load.
To anyone out there with /sys/devices/system/cpu/intel_pstate/status in active
What CPU frequencies are you observing?
P.S. I have had the CPU also clock down to 200 MHz, but that is due to the displayport/USB-C sticker issue. I have removed the adapter, and also fixed the sticker since then, and the pstate driver still seems to be acting weird.
1 Like
Hey Jan,
I’m running Ubuntu 21.04, kernel version 5.11.0-40-generic. I verified that /sys/devices/system/cpu/intel_pstate/status is set to active. Shortly after a cold boot, with nothing but terminal and a resource monitor running, my clock speeds are as follows: 1.18, 1.16, 1.18, 1.25, 1.17, 1.24, 1.14, 1.15 (GHz).
My command was cpufreq-info | grep "frequency is".
Hi Jacob,
Thanks for the reply, do you mind running two more commands and including the output here?
cd /sys/devices/system/cpu/intel_pstate
for x in *; do echo $x; cat $x; echo ""; done
cd /sys/devices/system/cpu/cpufreq/policy1
for x in *; do echo $x; cat $x; echo ""; done
Small update to my own question:
I think htop and cat /proc/cpuinfo are showing incorrect information, when the pstate driver is active: intel_pstate CPU Performance Scaling Driver — The Linux Kernel documentation
The correct place to check is: cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq
htop shows incorrect information, because it is not using that path: https://github.com/htop-dev/htop/pull/478
I’m able to control the scaling, and actually see the difference in power draw (acpi -V) through the following options in the policy* directories:
scaling_max_freq
scaling_min_freq
energy_performance_preference
scaling_available_governors
Woops, didn’t see these posts. I should’ve set this to “watching” to get notifications.
Sounds like you’ve made progress, but just in case, here’s what I get:
hwp_dynamic_boost
0
max_perf_pct
100
min_perf_pct
8
no_turbo
0
num_pstates
44
status
active
turbo_pct
44
Second part:
affected_cpus
1
base_frequency
2800000
cpuinfo_max_freq
4700000
cpuinfo_min_freq
400000
cpuinfo_transition_latency
0
energy_performance_available_preferences
default performance balance_performance balance_power power
energy_performance_preference
balance_performance
related_cpus
1
scaling_available_governors
performance powersave
scaling_cur_freq
1281577
scaling_driver
intel_pstate
I have the same problem on Manjaro KDE. Mine oscillates between 200MHz and 2400MHz every second, causing horrible lag every second. It sometimes will disappear out of nowhere, and even after a cold boot will not happen maybe 1 every 5 times. I tried setting Kernel parameters acpi_osi='Windows 2020' i915.enable_psr=0 without success.
1 Like
The frequency should not drop below 400.
I had the exact same <400 issue: it would happen sometimes, it would go away (sometimes), and would disappear after a cold reboot.
I was able to immediately fixed it without reboot, by taking out the displayport adapter.
After reaching out to support, I had the sticker issue, for which the fix is described here:
After fixing the stickers, I have not had it come back (3 weeks so far).
2 Likes
