Processor turbo dsiabled/throttled after suspend

Bug #1738534 reported by Shaun Crampton
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned
thermald (Ubuntu)
New
Undecided
Unassigned

Bug Description

After suspending/resuming my laptop on battery power, I noticed choppy video playback. I've narrowed it down to the CPU being locked to lower frequencies after suspend/resume (only on battery). Plugging the laptop back in does not restore the normal performance, nor does suspend/resume after plugging it back in. The performance doesn't drop until after the suspend/resume, I'm not sure if it is _supposed_ to throttle when on battery, but either way the behaviour is wrong.

Doing a full shutdown and restart restores the performance to normal.

Prior to a suspend/resume cycle, cpupower reports:

$ sudo 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: 800 MHz - 3.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3.00 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.26 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    2800 MHz max turbo 4 active cores
    2800 MHz max turbo 3 active cores
    2800 MHz max turbo 2 active cores
    3000 MHz max turbo 1 active cores

Afterwards, the frequency is clamped (cpufreq-set -r --max=3.0GHz has no effect) and turbo is disabled:

$ sudo 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: 800 MHz - 3.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 1.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 950 MHz (asserted by call to kernel)
  boost state support:
    Supported: no
    Active: no
    2800 MHz max turbo 4 active cores
    2800 MHz max turbo 3 active cores
    2800 MHz max turbo 2 active cores
    3000 MHz max turbo 1 active cores

Trying to re-enable turbo mode by setting the no_turbo intel_pstate /sys/ entry back to 0 is rejected:

$ echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
0
tee: /sys/devices/system/cpu/intel_pstate/no_turbo: Operation not permitted

However, these two commands *do* work around the problem, forcing turbo mode back on and then restoring the normal frequency range:

sudo x86_energy_perf_policy --turbo-enable 1
sudo cpufreq-set -r --min=0.8GHz --max=3.0GHz

I also see this error in dmesg after some resumes (but the above problem sometimes happens without this error message):

Dec 16 11:36:25 shauns-laptop kernel: intel_pstate: Turbo disabled by BIOS or unavailable on processor

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-image-4.13.0-19-generic 4.13.0-19.22
ProcVersionSignature: Ubuntu 4.13.0-19.22-generic 4.13.13
Uname: Linux 4.13.0-19-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.6
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: shaun 1194 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sat Dec 16 11:18:12 2017
InstallationDate: Installed on 2017-12-14 (1 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
Lsusb:
 Bus 001 Device 004: ID 2232:1024 Silicon Motion
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X4C/900X4D
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.13.0-19-generic root=UUID=7352de8c-0017-44e1-81fb-0145ad9c1185 ro rootflags=subvol=@ quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.13.0-19-generic N/A
 linux-backports-modules-4.13.0-19-generic N/A
 linux-firmware 1.169.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/12/2012
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: P03AAC
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: SAMSUNG_NP1234567890
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: FAB1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP03AAC:bd07/12/2012:svnSAMSUNGELECTRONICSCO.,LTD.:pn900X3C/900X3D/900X4C/900X4D:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1:
dmi.product.family: ChiefRiver System
dmi.product.name: 900X3C/900X3D/900X4C/900X4D
dmi.product.version: 0.1
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

Revision history for this message
Shaun Crampton (fasaxc) wrote :
Revision history for this message
Shaun Crampton (fasaxc) wrote :

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.)

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Shaun Crampton (fasaxc) wrote :

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

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Shaun Crampton (fasaxc) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
richu (richursa)
Changed in linux (Ubuntu):
status: Expired → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
richu (richursa) wrote :

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

Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
Nicolás Abel Carbone (nicocarbone) wrote :

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

Revision history for this message
Mustapha Hadid (mhadidg) wrote :
Download full text (3.6 KiB)

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...

Read more...

Revision history for this message
wwweb (wwweb-sinet) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.