Processor turbo dsiabled/throttled after suspend

Just tried another scenario. If I do the full power cycle while on battery power, then it boots up with turbo disabled and frequency locked. This command then seems to work (cpupower then reports turbo is active/supported):

sudo x86_energy_perf_policy --turbo-enable 1

But this command has no effect:

sudo cpufreq-set -r --min=0.8GHz --max=3.0GHz

(Where, int he previous scenario, it did work.)

This change was made by a bot.

As a workaround, I created a post-resume script that runs the above commands at /lib/systemd/system-sleep/throttle-workaround. It works in the first scenario, but not if the full power cycle was done on battery power.

#!/bin/sh

# Action script to prevent CPU throttling after resume.

set -e

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "${1}" in
        post)
  x86_energy_perf_policy --turbo-enable 1
  cpufreq-set -r --max=3.0GHz
                ;;
esac

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.15 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc4

It may have been as early as the upgrade to 16.04. I remember having some performance/overheating issues at that time so I disabled intel_pstate for a while; but I never fully diagnosed the issue. The 17.10 install was a fresh install though, I wiped the system.

I'll try the new kernels.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Status changed to 'Confirmed' because the bug affects multiple users.

This bug affects a lot of users including me , any fix ?

I am still having this problem on a Dell XPS 9360 running Ubuntu 21.04.

I'm experiencing the same issue on Ubuntu 21.04 (5.11.0-22-generic)

-------
DistroRelease: Ubuntu 21.04
InstallationDate: Installed on 2020-03-14 (487 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200309)
ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21
UpgradeStatus: Upgraded to hirsute on 2021-06-03 (40 days ago)
dmi.bios.date: 11/30/2020
dmi.bios.release: 1.41
dmi.bios.vendor: LENOVO
dmi.bios.version: BHCN41WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Legion Y540-15IRH-PG0
dmi.ec.firmware.release: 1.41
dmi.modalias: dmi:bvnLENOVO:bvrBHCN41WW:bd11/30/2020:br1.41:efr1.41:svnLENOVO:pn81SY:pvrLegionY540-15IRH-PG0:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegionY540-15IRH-PG0:
dmi.product.family: Legion Y540-15IRH-PG0
dmi.product.name: 81SY
dmi.product.sku: LENOVO_MT_81SY_BU_idea_FM_Legion Y540-15IRH-PG0
dmi.product.version: Legion Y540-15IRH-PG0
dmi.sys.vendor: LENOVO

lscpu
-------
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Stepping: 10
CPU MHz: 2600.000
CPU max MHz: 2600.0000
CPU min MHz: 800.0000
BogoMIPS: 5199.98
Virtualization: VT-x
L1d cache: 192 KiB
L1i cache: 192 KiB
L2 cache: 1.5 MiB
L3 cache: 12 MiB
NUMA node0 CPU(s): 0-11
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX vulnerable
Vulnerability Mds: Vulnerable; SMT vulnerable
Vulnerability Meltdown: Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
Vulnerability Spectre v2: Vulnerable, IBPB: disabled, STIBP: disabled
Vulnerability Srbds: Vulnerable
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1g
                                 b rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_c
                                 pl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2...

The problem still persists.
Using latest stable Debian 11 and having the same issue - every time after suspend CPU turbo is disabled.

5.10.0-23-amd64 #1 SMP Debian 5.10.179-2 (2023-07-14) x86_64 GNU/Linux

A workaround I've found is to edit /etc/sysfs.conf:

mode power/state = 0777
owner power/state = root:root
devices/system/cpu/cpu0/cpufreq/boost = 1
devices/system/cpu/cpu1/cpufreq/boost = 1
devices/system/cpu/cpu2/cpufreq/boost = 1
devices/system/cpu/cpu3/cpufreq/boost = 1
devices/system/cpu/cpu0/cpufreq/scaling_governor = performance
devices/system/cpu/cpu1/cpufreq/scaling_governor = performance
devices/system/cpu/cpu2/cpufreq/scaling_governor = performance
devices/system/cpu/cpu3/cpufreq/scaling_governor = performance

change scaling_governor to any other supported mode (ondemand, conservative, etc.), then restart sysfsutils:

sudo service sysfsutils restart

and then change scaling_governor back to performance and restart sysfsutils again.