su root -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo"
su root -c "echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo"
Turbo boost disabled after suspend as well for me, so you have to add these lines to systemd script. The value itself is not changed (always 0), you just have to toggle it.
It's all happens on Dell M4700 laptop. Also useful to trick BIOS if you don't use original power adapter from Dell. Mine is not reporting its wattage, so I get power adapter warning on startup and the CPU is downclocked to 900Mhz. Previously I've had to remove the power cord before boot, but now it is all fixed.
]]>After resume :
$ uname -a
Linux malta 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux
$ sudo rdmsr -a 0x19a
10
10
10
10
$ 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: 400 MHz - 2.80 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 2.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: 264 MHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes
$ sudo wrmsr -a 0x19a 0x0
$ sudo rdmsr -a 0x19a
0
0
0
0
$ 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: 400 MHz - 2.80 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 2.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: 2.09 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes
Yaaay! I can now switch between firefox tabs without having to go take a coffee break!
I'll go ahead and create my systemd unit.
Oh, and a little context on this issue : it is not observed every time I resume from suspend, but yesterday evening I suspended on battery, and this morning (when it was observed) I resumed on battery also. Before going ahead and writing MSR registries, I tried several suspend (closing lid)/resume cycles on AC, and it did not help.
And my BIOS is up to date (1.4.4) as stated here : https://wiki.archlinux.org/index.php/De … OS_updates
I will add a quick note to this wiki page, pointing here.
Many thanks to you guys for the debug information!
]]>I'm running Ubuntu 14.04 on a Dell Latitude E6420, and had the same issue with very slow performance on resume when running on battery. CPU freq was down to ~600MHz. Setting the 0x19a register back to 0x0 solved it for me as well.
Just in case it helps anyone else, I had to go a slightly different route to run this fix on resume, as Ubuntu 14.04 doesn't use systemd.
Make a new file '/etc/pm/sleep.d/zero_clock_mod_msr':
#!/bin/bash
case "$1" in
thaw|resume)
modprobe msr
wrmsr -a 0x19a 0x0
;;
esac
Make file executable with 'chmod 755 /etc/pm/sleep.d/zero_clock_mod_msr'.
Thanks!
]]>So, today I bring my laptop up from resume and we're back to slow performance and 0x1c in the msr registers - looks like the new bios isn't a reliable fix after all....
Fortunately, the script described here still fixes the issue.
]]>Hurrah!
If there's anything else I can help with then please let me know.
]]>cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
]]>Thanks for the detailed explanation.
Note that on my laptop switching to acpi-cpufreq seems to bring its own problem - the CPU is locked to minimum frequency. So if that's a solution people are using it wouldn't be acceptable for me.
This is different to pstate where the cpu frequency scales correctly until I suspend/resume the machine. Once resumed the frequencies do vary but they are reported as being less than the minimum frequency for the CPU and subjectively that's how it feels.
There's a chance that acpi-cpufreq is being affected by laptop-mode, which I've got installed, but the behaviour is different under the same conditions between acpi & pstate.
Let me know if there's anything else you'd like me to test - I'm curious to know if a BIOS upgrade will make a difference.
]]>For the acpi-cpufreq test: Please note that it is what the register reads after a resume from suspend on battery that I want. You wouldn't necessarily notice issues with CPU frequencies, as that driver responds different to Clock Modulation. The theory is that this Clock Modulation issue also occurs with the acpi-cpufreq scaling driver, but most users don't even notice. I am trying to gather evidence to support the theory. There are two root issues here: First, it seems that Dell uses Clock Modulation when resuming on battery, and it shouldn't; Secondly, in its current form, the intel_pstate driver is completely NOT compatible with Clock Modulation and will always drive the target pstate to minimum (force the CPU frequency to minimum, regardless of load).
By far, it seems that most people are merely disabling the intel_pstate driver and moving on using the acpi-cpufreq driver. I am attempting to determine the magnitude of the issue.
]]>Yes I can help out.
I can confirm I've got a Dell laptop a Lattitude E6220 - I've seen that it's not running the latest BIOS from Dell. I was going to upgrade the BIOS but I'll hold off to help out with some testing.
The problem does occur on battery power - I will have to check whether it is a problem on AC (of course my psu is in the office right now!).
I see CPU frequencies in the range 630000 - 790000, but my i5's minimum frequency is 800000.
rdmsr -a returns 1c for each of the 4 cores.
I've tried the acpi-cpufreq and I don't see the problem, but it's probably not a valid test - even from a fresh reboot the frequency seems to be set on the minimum regardless of the load. I'm not sure if I need some daemon running to take control of the CPU frequency?
]]>