Bug 90421 - Intel pstate stops working after resuming from suspend on haswell
Summary: Intel pstate stops working after resuming from suspend on haswell
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: intel_pstate (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: Kristen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-28 13:00 UTC by Alex Lochmann
Modified: 2016-03-22 15:36 UTC (History)
11 users (show)

See Also:
Kernel Version: 3.18.0
Tree: Mainline
Regression: No


Attachments
output of /proc/cpuinfo (3.99 KB, text/plain)
2014-12-28 13:00 UTC, Alex Lochmann
Details
kernel config (128.81 KB, text/plain)
2014-12-28 13:01 UTC, Alex Lochmann
Details
Adds some required debug information to perf (4.84 KB, text/plain)
2015-03-08 18:37 UTC, Doug Smythies
Details
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped) (1.25 MB, application/octet-stream)
2015-05-11 09:36 UTC, Marien Zwart
Details
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped) (609.75 KB, application/octet-stream)
2015-05-11 09:36 UTC, Marien Zwart
Details
dmesg (98.21 KB, text/plain)
2015-05-11 09:37 UTC, Marien Zwart
Details
.config (80.82 KB, text/plain)
2015-05-11 09:38 UTC, Marien Zwart
Details
debug infos (1.45 KB, application/gzip)
2015-05-18 21:42 UTC, Alex Lochmann
Details
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped) (2.77 MB, application/gzip)
2015-05-18 21:43 UTC, Alex Lochmann
Details
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped) (2.77 MB, application/gzip)
2015-05-18 21:44 UTC, Alex Lochmann
Details
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped) (2.89 MB, application/gzip)
2015-05-19 08:18 UTC, Alex Lochmann
Details
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped) (2.44 MB, application/gzip)
2015-05-19 08:18 UTC, Alex Lochmann
Details
Alex "before" CPU frequencies (20.41 KB, image/png)
2015-05-19 15:11 UTC, Doug Smythies
Details
perf sleep 300 before -- minimal load (1.05 MB, application/gzip)
2015-05-20 08:22 UTC, Alex Lochmann
Details
perf sleep 300 after -- minimal load (1.06 MB, application/gzip)
2015-05-20 08:22 UTC, Alex Lochmann
Details
turbostat sleep 10 before -- minimal load (2.62 KB, text/plain)
2015-05-20 08:22 UTC, Alex Lochmann
Details
turbostat sleep 10 after -- minimal load (2.60 KB, text/plain)
2015-05-20 08:23 UTC, Alex Lochmann
Details
after frequencies (20.81 KB, image/png)
2015-05-20 15:04 UTC, Doug Smythies
Details
after durations (32.18 KB, image/png)
2015-05-20 15:06 UTC, Doug Smythies
Details
before frequencies (15.71 KB, image/png)
2015-05-20 15:07 UTC, Doug Smythies
Details
before durations (35.52 KB, image/png)
2015-05-20 15:09 UTC, Doug Smythies
Details
A patch to deal with the target pstate not getting set (1.91 KB, patch)
2015-05-23 01:54 UTC, Doug Smythies
Details | Diff
Same patch but based against an unmodfied kernel 4.0 (1.92 KB, patch)
2015-05-25 04:46 UTC, Doug Smythies
Details | Diff
Same patch done a different way (3.56 KB, patch)
2015-05-29 03:08 UTC, Doug Smythies
Details | Diff

Description Alex Lochmann 2014-12-28 13:00:55 UTC
Created attachment 162021 [details]
output of /proc/cpuinfo

Hi folks!

I'm a little bit desperate. I recently installed Ubuntu 14.10 on a Lenovo X240 with Intel Core-i7 4600U. I built a custom (mainline) kernel.
I didn't manage to configure the kernel in the right way to resume frequency scaling after resuming from suspend to ram.
The frequency stucks at the maximum available frequency. The concrete value depends on /sys/devices/system/cpu/intel_pstate/no_turbo. If it is 0, it is 3.1 GHz.

Besides this issue, i've got some trouble to make the kernel scale a cores frequency. If i boot the kernel as it is, it scales the frequency just down to 2.1 GHz or it even stucks at 3.1 GHz, which is the turbo boost frequency.
After i change the values of /sys/kernel/debug/pstate_snb/*_gain_pct from
i_gain_pct = 0
d_gain_pct = 0
p_gain_pct = 20

to

i_gain_pct = 50
d_gain_pct = 0
p_gain_pct = 0
, things getting better. The average load among all cores is about 25% according to htop.

I tested nearly the same kernel config with a 3.18.1 kernel on a old X220 (Intel Core-i3 2300M). It just works... The kernel scales the frequency and resumes its work after wakeup.

I attached the output of cpuinfo for the 4600U cpu and the kernel config.
Pls, help me. :-)


Greetings,
Alex
Comment 1 Alex Lochmann 2014-12-28 13:01:13 UTC
Created attachment 162031 [details]
kernel config
Comment 2 Alex Lochmann 2015-01-07 18:42:39 UTC
This bug might be related or even a duplicate of this one: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Comment 3 tomasi 2015-01-12 13:18:54 UTC
You are correct Alex.
This issue is in kernel for about one year not fixed.
I have Lenovo T440s with Intel 4200U. Tried latest kernels - from 3.12.7 to 3.17.
Every time cpu after suspend stuck on 2.45 GHz
Comment 4 Paul Johnson 2015-02-27 17:09:36 UTC
I see similar on Dell ultrabook 6430u, but symptom is slightly different. I don't think CPU is actually stuck, I think it varies in narrow range. 

After a suspend, I see frequencies "stuck" near the minimum when in powersave mode. (Works fine on restart, CPU frequencies fluctuate across whole range). After suspend, cpupower says it is able to scale up, it does not.  Always stays slow after suspend. 

$ 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: 0.97 ms.
  hardware limits: 800 MHz - 3.30 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.30 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 647 MHz.
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores

The symptom of this is that the computer becomes unresponsive and sometimes freezes up altogether. 


Here is a workaround I learned in one forum. Manually speed up and slow down.  

To run faster, switch to performance mode with this script. 

## Call this cpu_performance.sh
sudo cpupower frequency-set -g performance

IF you don't need to be fast, run this

## Call this cpu_powersave.sh
sudo cpupower frequency-set -g powersave

In the cpu_powersave, my speeds fluctuate narrowly in a band around 2.1GHz, not at the 3.3 reported possible by cpupower.


$ 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: 0.97 ms.
  hardware limits: 800 MHz - 3.30 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.30 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.08 GHz.
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores


I see similar to your report, but I'm not "stuck" at the max, but about 2/3 of the max.

If I switch back to powersave mode, I am back into the super slow range. IT is not "stuck there" 
 
In case it matters, I'm observing the cpu frequency with the XFCE applet
CPU frequency monitor.
Comment 5 Andrei 2015-03-05 14:56:08 UTC
I can confirm this happens on my Lenovo Y510p using an i7-4200MQ CPU. After a fresh reboot, frequencies used at idle are mostly in the range of 800 MHz - 1.9 GHz, but after waking up from sleep the CPU sits mostly at 2.5 - 3.1 GHz even with 1% usage.
Comment 6 tomasi 2015-03-05 14:59:55 UTC
This problem exists from 2013-12-05 ([Bug 65301]). One year and 3 months.
I  have latest kernel 3.19. Bug is still there.
Comment 7 Paul Johnson 2015-03-05 18:01:48 UTC
I notice the problem occurs only when you are ON the power cord when the suspend occurs and then DISCONNECTED from power when you resume from suspend. If you resume with power connected, then frequency scaling works properly with the "powersave" governor in place.  That is new information so far as I can tell.

$ uname -a
Linux dellap14 3.16.0-31-generic #41-Ubuntu SMP Tue Feb 10 15:24:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ 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: 0.97 ms.
  hardware limits: 800 MHz - 3.30 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.30 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 886 MHz.
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores
Comment 8 Andrei 2015-03-05 20:16:12 UTC
(In reply to Paul Johnson from comment #7)
> I notice the problem occurs only when you are ON the power cord when the
> suspend occurs and then DISCONNECTED from power when you resume from
> suspend. If you resume with power connected, then frequency scaling works
> properly with the "powersave" governor in place.  That is new information so
> far as I can tell.
> 
> $ uname -a
> Linux dellap14 3.16.0-31-generic #41-Ubuntu SMP Tue Feb 10 15:24:04 UTC 2015
> x86_64 x86_64 x86_64 GNU/Linux
> 
> $ 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: 0.97 ms.
>   hardware limits: 800 MHz - 3.30 GHz
>   available cpufreq governors: performance, powersave
>   current policy: frequency should be within 800 MHz and 3.30 GHz.
>                   The governor "powersave" may decide which speed to use
>                   within this range.
>   current CPU frequency is 886 MHz.
>   boost state support:
>     Supported: yes
>     Active: yes
>     25500 MHz max turbo 4 active cores
>     25500 MHz max turbo 3 active cores
>     25500 MHz max turbo 2 active cores
>     25500 MHz max turbo 1 active cores

To me, this happens when I'm connected to AC power when resuming as well. The powersave governor shows as being active and all the driver parameters seem to be fine, but the CPU uses high frequencies constantly anyway.
Comment 9 Doug Smythies 2015-03-08 18:37:53 UTC
Created attachment 169891 [details]
Adds some required debug information to perf

I am unable to re-create this situation on my computer (I have an older i7).
Could one or more of you apply the attached patch to a kernel >= 3.19 and then on an otherwise idle system do:

sudo perf record -a --event=power:pstate_sample sleep 300

And post the resulting perf.data file back here.

If your computer will suspend or whatever in that 5 minute sample time, then prevent it from doing so.

Do the test after a fresh boot and again after a resume from suspend. i.e. before (control sample) and after the issue is present.
Comment 10 Paul Johnson 2015-05-07 22:33:55 UTC
I'm sorry, I can't help debug because I'm back running the kernel from Ubuntu, 3.16.xx.

I do still see problem that when system is re-awaken and it is NOT on the power cord, then the cpu frequencies are stuck in a very small range.  If I re-awaken on the power cord, then all is well, scaling works perfectly.
Comment 11 Marien Zwart 2015-05-11 09:36:02 UTC
Created attachment 176371 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
Comment 12 Marien Zwart 2015-05-11 09:36:44 UTC
Created attachment 176381 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Comment 13 Marien Zwart 2015-05-11 09:37:38 UTC
Created attachment 176391 [details]
dmesg
Comment 14 Marien Zwart 2015-05-11 09:38:00 UTC
Created attachment 176401 [details]
.config
Comment 15 Marien Zwart 2015-05-11 09:43:10 UTC
I'm seeing what's hopefully the same problem. This is on a desktop, where according to turbostat turbo boost stops working after resuming from suspend: Bzy_MHz tops out at 3500 MHz after suspend while it's 3900 MHz before.

I've attached dmesg, .config, and "sudo perf record -a --event=power:pstate_sample sleep 300" before and after suspend, all from the same boot. This is with 4.0.2 with the "Adds some required debug information to perf" patch applied.

Note I do not know which kernel version this started happening on (on this particular system).

If there's anything else you need to help debug this, don't hesitate to ask (including if it's "that's not the same bug at all", but the symptoms at least sound pretty close...).
Comment 16 Doug Smythies 2015-05-11 14:40:42 UTC
@Marien: Thank you for the data you supplied. Your frequency scaling driver appears to be using the performance mode governor. What it is being told to do by the intel_pstate driver aside, processor response is as though turbo is disabled after the suspend event.

Could you please supply a little additional information: Both before and after suspend, the output from:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
cat /sys/devices/system/cpu/intel_pstate/no_turbo
cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
cat /sys/devices/system/cpu/intel_pstate/min_perf_pct

Also the before and after output from:

sudo turbostat -d sleep 10

I think it will be desirable to test again with the powersave mode governor.

I don't know if it is relevant or not, but CPU 0 has different intel_pstate driver execution time gaps (durations) before and after suspend.
Comment 17 Marien Zwart 2015-05-12 09:35:01 UTC
Before suspend:

/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor: performance
/sys/devices/system/cpu/intel_pstate/no_turbo: 0
/sys/devices/system/cpu/intel_pstate/max_perf_pct: 100
/sys/devices/system/cpu/intel_pstate/min_perf_pct: 100

Same results after suspend.

"turbostat -d sleep 10" before suspend:

turbostat version 4.1 10-Feb, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 13 CPUID levels; family:model:stepping 0x6:3c:3 (6:60:3)
CPUID(6): APERF, DTS, PTM, No EPB
RAPL: 3121 sec. Joule Counter Range, at 84 Watts
cpu0: MSR_NHM_PLATFORM_INFO: 0x80838f3012300
8 * 100 = 800 MHz max efficiency
35 * 100 = 3500 MHz TSC frequency
cpu0: MSR_IA32_POWER_CTL: 0x0000005d (C1E auto-promotion: DISabled)
cpu0: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008400 (UNdemote-C3, UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=0: pc0)
cpu0: MSR_NHM_TURBO_RATIO_LIMIT: 0x25262727
37 * 100 = 3700 MHz max turbo 4 active cores
38 * 100 = 3800 MHz max turbo 3 active cores
39 * 100 = 3900 MHz max turbo 2 active cores
39 * 100 = 3900 MHz max turbo 1 active cores
cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x30000000 (Active: ) (Logged: MultiCoreTurbo, Transitions, )
cpu0: MSR_GFX_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
cpu0: MSR_RING_PERF_LIMIT_REASONS, 0x0c000000 (Active: ) (Logged: PkgPwrL1, PkgPwrL2, )
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061 Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x000002a0 (84 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x4282d0001c82a0 (UNlocked)
cpu0: PKG Limit #1: ENabled (84.000000 Watts, 16.000000 sec, clamp DISabled)
cpu0: PKG Limit #2: ENabled (90.000000 Watts, 0.002441* sec, clamp DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: Cores Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: GFX Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00641400 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88470800 (29 C)
cpu0: MSR_IA32_THERM_STATUS: 0x88470000 (29 C +/- 1)
cpu1: MSR_IA32_THERM_STATUS: 0x884a0000 (26 C +/- 1)
cpu2: MSR_IA32_THERM_STATUS: 0x884b0000 (25 C +/- 1)
cpu3: MSR_IA32_THERM_STATUS: 0x88470000 (29 C +/- 1)
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp PkgWatt CorWatt GFXWatt
       -       -      11    0.28    3867    3500       0   17.81    0.75    0.52   80.63      29      32   11.24    0.89    0.01
       0       0       5    0.14    3841    3500       0   43.24    0.01    1.60   55.00      29      32   11.24    0.89    0.01
       0       4      37    0.96    3887    3500       0   42.43
       1       1      10    0.27    3871    3500       0    8.10    0.12    0.04   91.47      27
       1       5       0    0.01    3757    3500       0    8.36
       2       2       7    0.19    3827    3500       0   15.22    0.31    0.26   84.02      26
       2       6       2    0.04    3855    3500       0   15.37
       3       3      23    0.60    3858    3500       0    4.59    2.57    0.19   92.04      27
       3       7       1    0.02    3774    3500       0    5.18
10.000621 sec

Same after suspend:

turbostat version 4.1 10-Feb, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 13 CPUID levels; family:model:stepping 0x6:3c:3 (6:60:3)
CPUID(6): APERF, DTS, PTM, No EPB
RAPL: 3121 sec. Joule Counter Range, at 84 Watts
cpu0: MSR_NHM_PLATFORM_INFO: 0x80838f3012300
8 * 100 = 800 MHz max efficiency
35 * 100 = 3500 MHz TSC frequency
cpu0: MSR_IA32_POWER_CTL: 0x0000005d (C1E auto-promotion: DISabled)
cpu0: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008400 (UNdemote-C3, UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=0: pc0)
cpu0: MSR_NHM_TURBO_RATIO_LIMIT: 0x25262727
37 * 100 = 3700 MHz max turbo 4 active cores
38 * 100 = 3800 MHz max turbo 3 active cores
39 * 100 = 3900 MHz max turbo 2 active cores
39 * 100 = 3900 MHz max turbo 1 active cores
cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
cpu0: MSR_GFX_PERF_LIMIT_REASONS, 0x04000000 (Active: ) (Logged: PkgPwrL1, )
cpu0: MSR_RING_PERF_LIMIT_REASONS, 0x0c000000 (Active: ) (Logged: PkgPwrL1, PkgPwrL2, )
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061 Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x000002a0 (84 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x4282d0001c82a0 (UNlocked)
cpu0: PKG Limit #1: ENabled (84.000000 Watts, 16.000000 sec, clamp DISabled)
cpu0: PKG Limit #2: ENabled (90.000000 Watts, 0.002441* sec, clamp DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: Cores Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: GFX Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00641400 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88470800 (29 C)
cpu0: MSR_IA32_THERM_STATUS: 0x88470000 (29 C +/- 1)
cpu1: MSR_IA32_THERM_STATUS: 0x884b0000 (25 C +/- 1)
cpu2: MSR_IA32_THERM_STATUS: 0x884c0000 (24 C +/- 1)
cpu3: MSR_IA32_THERM_STATUS: 0x88480000 (28 C +/- 1)
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp PkgWatt CorWatt GFXWatt
       -       -     249    7.11    3500    3500       0   20.83    0.10    0.05   71.90      29      30   14.51    4.73    0.02
       0       0      25    0.71    3493    3500       0    3.06    0.28    0.08   95.87      29      30   14.51    4.73    0.02
       0       4       0    0.01    3472    3500       0    3.77
       1       1      33    0.95    3499    3500       0   16.56    0.09    0.05   82.35      28
       1       5       1    0.03    3495    3500       0   17.48
       2       2      34    0.96    3500    3500       0   27.70    0.02    0.02   71.30      28
       2       6       3    0.08    3500    3500       0   28.58
       3       3      46    1.30    3499    3500       0   60.52    0.03    0.05   38.10      29
       3       7    1851   52.88    3500    3500       0    8.94
10.000559 sec

The change (other than frequency and temperature changes) is:

-cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x30000000 (Active: ) (Logged: MultiCoreTurbo, Transitions, )
-cpu0: MSR_GFX_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
+cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
+cpu0: MSR_GFX_PERF_LIMIT_REASONS, 0x04000000 (Active: ) (Logged: PkgPwrL1, )
Comment 18 Marien Zwart 2015-05-12 10:35:18 UTC
Toggling the governor fixes things for me. That is: if I change it to "powersave" CPU frequency starts varying between small (1Ghz or so) and full turbo (3.9GHz) values, and if I then switch it back to "performance" turbo still works. Other people affected by this might want to try switching to the "wrong" governor and back, and seeing if anything changes.

After resuming from suspend, I write "powersave" to /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor. Now I see this change from powerstat -d:

-cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
+cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x10000000 (Active: ) (Logged: MultiCoreTurbo, )

and Bzy_MHz drops (to around 1200). If I spin up a CPU hog, it rises to above 3800 (good: turbo boost is working).

If I then change the governor back to "performance", I see this change (compared to right after resume from suspend):

-cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x00000000 (Active: ) (Logged: )
+cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x30001000 (Active: MultiCoreTurbo, ) (Logged: MultiCoreTurbo, Transitions, )

and Bzy_MHz is still above 3800. To recap: no turbo after resume, but if I toggle from the "performance" to the "powersave" governor and back, turbo re-enables.

Next, I suspended while on the "powersave" governor, and got:

turbostat version 4.1 10-Feb, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 13 CPUID levels; family:model:stepping 0x6:3c:3 (6:60:3)
CPUID(6): APERF, DTS, PTM, No EPB
RAPL: 3121 sec. Joule Counter Range, at 84 Watts
cpu0: MSR_NHM_PLATFORM_INFO: 0x80838f3012300
8 * 100 = 800 MHz max efficiency
35 * 100 = 3500 MHz TSC frequency
cpu0: MSR_IA32_POWER_CTL: 0x0000005d (C1E auto-promotion: DISabled)
cpu0: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008400 (UNdemote-C3, UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=0: pc0)
cpu0: MSR_NHM_TURBO_RATIO_LIMIT: 0x25262727
37 * 100 = 3700 MHz max turbo 4 active cores
38 * 100 = 3800 MHz max turbo 3 active cores
39 * 100 = 3900 MHz max turbo 2 active cores
39 * 100 = 3900 MHz max turbo 1 active cores
cpu0: MSR_CORE_PERF_LIMIT_REASONS, 0x14000000 (Active: ) (Logged: PkgPwrL1, MultiCoreTurbo, )
cpu0: MSR_GFX_PERF_LIMIT_REASONS, 0x04000000 (Active: ) (Logged: PkgPwrL1, )
cpu0: MSR_RING_PERF_LIMIT_REASONS, 0x0c000000 (Active: ) (Logged: PkgPwrL1, PkgPwrL2, )
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061 Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x000002a0 (84 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x4282d0001c82a0 (UNlocked)
cpu0: PKG Limit #1: ENabled (84.000000 Watts, 16.000000 sec, clamp DISabled)
cpu0: PKG Limit #2: ENabled (90.000000 Watts, 0.002441* sec, clamp DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: Cores Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x00000000 (UNlocked)
cpu0: GFX Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00641400 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88470800 (29 C)
cpu0: MSR_IA32_THERM_STATUS: 0x88470800 (29 C +/- 1)
cpu1: MSR_IA32_THERM_STATUS: 0x884a0800 (26 C +/- 1)
cpu2: MSR_IA32_THERM_STATUS: 0x884a0800 (26 C +/- 1)
cpu3: MSR_IA32_THERM_STATUS: 0x88480800 (28 C +/- 1)
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp PkgWatt CorWatt GFXWatt
       -       -      83    2.14    3886    3500       0   33.61    0.06    0.02   64.16      30      30   16.48    3.21    0.02
       0       0       4    0.09    3838    3500       0   52.94    0.03    0.00   46.94      30      30   16.48    3.21    0.02
       0       4       0    0.01    3800    3500       0   53.03
       1       1     168    4.30    3898    3500       0   75.84    0.05    0.02   19.79      28
       1       5     429   11.02    3892    3500       0   69.12
       2       2      40    1.05    3810    3500       0    4.57    0.05    0.02   94.30      26
       2       6       2    0.05    3806    3500       0    5.57
       3       3      22    0.57    3828    3500       0    3.62    0.13    0.05   95.63      28
       3       7       0    0.01    3780    3500       0    4.19

So there's still turbo, and power draw seems higher than expected for "powersave". After toggling to "performance" and then back to "powersave", Bzy_MHz dropped again.

I haven't quite worked out why I'm getting the "performance" governor in the first place, or which governor best suits my needs. I haven't configured this anywhere I recall, and Documentation/cpu-freq/intel-pstate.txt doesn't quite explain what the performance and power implications are.
Comment 19 Paul Johnson 2015-05-12 14:03:43 UTC
Marien:

You don't mention if you are plugged into the power when you do this. For me, it makes a big difference.  Waking up while plugged in will help quite a lot and changing the governor works well, as you say.  If I am not plugged in, I don't see same change.
Comment 20 Doug Smythies 2015-05-12 14:15:31 UTC
(In reply to Paul Johnson from comment #19)
> Marien:
> 
> You don't mention if you are plugged into the power when you do this.

A desktop computer is mentioned, so I have been assuming always on AC power.
Comment 21 Marien Zwart 2015-05-13 09:24:10 UTC
Right, this is a desktop, it doesn't work off AC power. I'm more concerned about intel_pstate not throttling up rather than down, but the "doesn't work after suspend" bit seemed similar to what you're seeing.
Comment 22 Alex Lochmann 2015-05-18 12:05:53 UTC
In my case, it is a Lenovo X240 with a Intel Core i7 4600U.
If plug it into my docking station (using AC) it is stuck at its max frequency. The pstate driver returns to its normal operation as soon as i unplug it from the docking station.
Changing the scaling governor (performance --> powersave --> performance) has no effect.
Comment 23 Doug Smythies 2015-05-18 13:57:23 UTC
(In reply to Alex Lochmann from comment #22)
> Changing the scaling governor (performance --> powersave --> performance)
> has no effect.

I am confused. If the frequency governor is "performance" then the CPU frequencies will be maximum, That is what they are supposed to be on performance mode. Under extremely light load the processor itself might backoff the frequency, but your post number 1 says there is always significant load.
Comment 24 igor 2015-05-18 17:06:45 UTC
I'm having the same issue on Lenovo z50-70, with i7-4510u. When first started, cpu works fine in "powersave" mode, with normal frequency range. But after hibernating, governor switches to "performance" automatically. Manualy swithcing the governor back seems to work, but it still stays in kinda high frequency range after.
Comment 25 Alex Lochmann 2015-05-18 21:35:21 UTC
(In reply to Doug Smythies from comment #23)
> (In reply to Alex Lochmann from comment #22)
> > Changing the scaling governor (performance --> powersave --> performance)
> > has no effect.
> 
> I am confused. If the frequency governor is "performance" then the CPU
> frequencies will be maximum, That is what they are supposed to be on
> performance mode. Under extremely light load the processor itself might
> backoff the frequency, but your post number 1 says there is always
> significant load.

Sorry. My fault.
Some threads on the internet mentioned changing the governor back and forth solved their issue, which did not work in my case.
That was the only thing i wanted to say. ;)
Comment 26 Alex Lochmann 2015-05-18 21:42:59 UTC
Created attachment 177241 [details]
debug infos

The tarball contains the following files:
- output of 'cat /sys/devices/system/cpu/intel_pstate/*'
- output of turbostat -d sleep 10

Each command was executed before and after a suspend.
Comment 27 Alex Lochmann 2015-05-18 21:43:49 UTC
Created attachment 177251 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Comment 28 Alex Lochmann 2015-05-18 21:44:39 UTC
Created attachment 177261 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
Comment 29 Doug Smythies 2015-05-19 02:46:42 UTC
(In reply to Alex Lochmann from comment #27)
> Created attachment 177251 [details]
> "perf record -a --event=power:pstate_sample sleep 300" after suspend
> (gzipped)

Alex, thanks for the trace data. Unfortunately, I am unable to use the post-pocesssing tools on it, because the patch (see  my post 0 above) was not added.
Comment 30 Alex Lochmann 2015-05-19 08:17:02 UTC
Damt it. I knew i forgot something after i built the 4.0.3 kernel....
I applied your patch and started perf again (while running on AC).
I collected the data after a fresh boot running my usual desktop applications.
As you can see below, the governor was set to powersave before and after suspend:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

In either case the frequency stuck at 3.2 GHz.
Comment 31 Alex Lochmann 2015-05-19 08:18:00 UTC
Created attachment 177311 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Comment 32 Alex Lochmann 2015-05-19 08:18:23 UTC
Created attachment 177321 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
Comment 33 Doug Smythies 2015-05-19 15:11:26 UTC
Created attachment 177361 [details]
Alex "before" CPU frequencies

Alex, thanks for your trace data.

From your turbostat data, I had expected your "before" trace data to have an average busy frequency of about 2.3 GHz, but that is not what the trace data shows. Actually, I see pretty much no difference between the before and after trace data. Your CPUs have a lot going on, and the results are O.K. for the scenario and for the algorithms currently being used. Some modifications to the current algorithms have been proposed, and I think (actually, I know) they would would bring your CPU frequencies down some.

I might be able to do a better analysis if you turn off all that extra stuff that is running on your system for these trace samples (as per my post #9 instructions). I'm suggesting turning off: yukuake; amarok; tmux; puslesudio; byobu-status; firefox; chromium-browse; pavucontrol; skype; solaar; lyx: ...
Comment 34 Alex Lochmann 2015-05-19 21:39:51 UTC
Ok. I will reboot my notebook tomorrow and gather the required trace data.
I will just login onto my account and have nothing else than the desktop itself running.
Would that be sufficient?
Comment 35 Alex Lochmann 2015-05-20 08:22:02 UTC
Created attachment 177391 [details]
perf sleep 300 before -- minimal load
Comment 36 Alex Lochmann 2015-05-20 08:22:21 UTC
Created attachment 177401 [details]
perf sleep 300 after -- minimal load
Comment 37 Alex Lochmann 2015-05-20 08:22:47 UTC
Created attachment 177411 [details]
turbostat sleep 10 before -- minimal load
Comment 38 Alex Lochmann 2015-05-20 08:23:15 UTC
Created attachment 177421 [details]
turbostat sleep 10 after -- minimal load
Comment 39 Doug Smythies 2015-05-20 15:04:46 UTC
Created attachment 177461 [details]
after frequencies

Alex: Your particular processor is prone to a math lockup issue within the intel_pstate driver. I suspect the other processor you tried is less prone to the issue. Really you need to try my proposed patch set.

There is something subtle going on between before and after. From all the trace data, it is not clear to me what it is. It is clearly evident that there are more executions of the intel_pstate driver, which means that the CPU is in the C0 state more often upon a jiffy boundary, This is very similar to another bugzilla report (I'll look up the number later (it might be bug 92111)).

Attached is graph 1 of 4 that I will attach. After CPU frequencies.
Comment 40 Doug Smythies 2015-05-20 15:06:18 UTC
Created attachment 177471 [details]
after durations

graph 2 of 4. After durations (the times between intel_pstate driver executions, per CPU.
Comment 41 Doug Smythies 2015-05-20 15:07:44 UTC
Created attachment 177481 [details]
before frequencies

graph 3 of 4: Before Frequencies. Notice the subtle differences between this graph and the after graph.
Comment 42 Doug Smythies 2015-05-20 15:09:43 UTC
Created attachment 177491 [details]
before durations

graph 4 of 4: Before Durations (time between intel_pstate executions, per CPU). Notice the differences between the after graph.
Comment 43 Alex Lochmann 2015-05-20 20:31:44 UTC
(In reply to Doug Smythies from comment #39)
> Created attachment 177461 [details]
> after frequencies
> 
> Alex: Your particular processor is prone to a math lockup issue within the
> intel_pstate driver. I suspect the other processor you tried is less prone
> to the issue. Really you need to try my proposed patch set.
Which patch set are you talking about? :)
I'm sorry. I didn't get it... :(
Comment 44 Doug Smythies 2015-05-20 22:56:50 UTC
Alex: See: https://bugzilla.kernel.org/show_bug.cgi?id=62851#c78
Comment 45 Doug Smythies 2015-05-21 06:32:16 UTC
@Marien: I have re-created your situation on my test computer, so I should be able to make progress now.
Comment 46 Alex Lochmann 2015-05-21 10:19:33 UTC
(In reply to Doug Smythies from comment #44)
> Alex: See: https://bugzilla.kernel.org/show_bug.cgi?id=62851#c78

Thanks. I applied the patch set and rebuild my kernel. Lets see what happens...
Do you need further trace data?
Comment 47 Doug Smythies 2015-05-21 13:53:59 UTC
(In reply to Alex Lochmann from comment #46)
> I applied the patch set and rebuild my kernel. Lets see what
> happens...
> Do you need further trace data?

Not just yet, I am going to focus on the Marien scenario on my computer for now.
Comment 48 Alex Lochmann 2015-05-22 18:15:35 UTC
Btw, it looks good. :-)
The driver still scales the frequency correctly, even  resuming from suspend. :-)
Comment 49 Doug Smythies 2015-05-22 19:04:45 UTC
(In reply to Alex Lochmann from comment #48)
> Btw, it looks good. :-)
> The driver still scales the frequency correctly, even  resuming from
> suspend. :-)

Alex: Please confirm or deny that you are using the "powersave" governor.
There is an issue with the performance mode governor, as Marien pointed out and that I can now repeat on my system. See also the comment I just added to another bug report (https://bugzilla.kernel.org/show_bug.cgi?id=62851#c83).
Comment 50 Doug Smythies 2015-05-23 01:54:38 UTC
Created attachment 177601 [details]
A patch to deal with the target pstate not getting set

@Marien and anybody else that wants to: Please try the attached patch for your performance mode resume from suspend issue.

Note that there are other failure scenarios, but the "performance" governor one is the easiest to re-produce.

Note: that patch was added on top of my 5 patch set, but it might apply on its own (I didn't try).
Comment 51 Marien Zwart 2015-05-23 02:43:01 UTC
Assuming your "5 patch set" is intel_pstate/rebase_to_k4.1, it doesn't apply to 4.0.4 (somewhat unsurprisingly given the name). First patch conflict occurs because stable does not have 6a82ba6d4fda21e5f9fda0f4126add3b88522f02. And attachment 177601 [details] does not apply without your patchset (either on 4.0.4 or 4.1rc2).

I'm sure I can get around these issues (by upgrading to Linux 4.1, or by applying 4.1's intel_pstate changes to 4.0 so your patchset applies, or by figuring out what attachment 177601 [details] does and making the same change to intel_pstate without your patchset), but it'll take a while before I get around to it.
Comment 52 Doug Smythies 2015-05-25 04:46:24 UTC
Created attachment 177741 [details]
Same patch but based against an unmodfied kernel 4.0

Maybe this version will work for you.
Comment 53 Marien Zwart 2015-05-25 10:38:00 UTC
Thanks! That applies, and according to turbostat turbo works after suspend (without switching governors around). If you need any further debug information from me, just let me know.
Comment 54 Doug Smythies 2015-05-29 03:08:45 UTC
Created attachment 178221 [details]
Same patch done a different way

@Marien (or anybody else): Attached is the same patch, but done a different way. If you would like to test it, I'll add tested by to your name before I submit it.

That patch was created against Kernel 4.1RC5.
Comment 55 Marien Zwart 2015-05-30 02:16:44 UTC
I've tested attachment 178221 [details], and it works for me.

Tested against commit aaa20fc23341be3df7b17810e330f12244abcf29 (a bit more recent than 4.1rc5). Without the patch, turbostat shows the cpu reaching 3900MHz before suspend and 3500MHz after. With the patch, it's 3900MHz before and after.
Comment 56 Alex Lochmann 2015-06-01 07:35:45 UTC
@Doug: Will the proposed patchset (the math lockup issue) be merged into the mainline kernel?
Comment 57 Doug Smythies 2015-06-01 14:21:45 UTC
@Alex (or anybody):
The patch set 1 to 5 of 5 was submitted on 2015.04.11. Note that Intel has to do a bunch of tests of various platforms. Patch 1 of 5 has been accepted and will be in Kernel 4.2RC1. A concern was raised on patch 2 of 5, and I have asked for clarification, particularly considering that patch 2 of 5 is just bringing back something that used to be in the driver. The hope was that the entire patch set would be included in Kernel 4.2RC1.

Please note that the math lockup issue is fundamentally due to the processor being in some bizarre state upon exit from suspend, and my patch set does not deal with that fundamental issue, it just doesn't lock up. On another bug report (bug 62851), I have asked for some additional trace data in an attempt to understand some lingering unexplained issues.

The other patch, the one that Marien tested, the one that deals with possibly never sending new target pstates, was submitted a day ago. It has been rejected, and will be re-submitted with the required corrections within a day.
Comment 58 Doug Smythies 2015-07-06 15:36:14 UTC
@Marien: I have used your method to test Kernel 4.2RC1 and the issue is resolved. Please confirm or deny by testing also.
Comment 59 Zhang Rui 2015-09-01 05:26:26 UTC
patches have been shipped in upstream kernel 3.2-rc1.
bug closed.
Comment 60 Paul Johnson 2015-09-08 03:48:49 UTC
In case other people come looking for the "frequency is stuck after resume" problem, here's some info. Apparently, there are separate problems, not all of which trace back to this particular kernel patch.

I installed kernel 4.2 from here: 

http://linuxg.net/install-kernel-4-2-on-ubuntu, 

still see trouble that CPU frequency is stuck in the 600s, although minimum is supposed to be 800. 

$ uname -a
Linux dellap14 4.2.0-040200-generic #201508301530 SMP Sun Aug 30 19:31:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I found Doug Smythies's posts in a thread here

https://bbs.archlinux.org/viewtopic.php?id=199922

and found his msr-related workaround does help.  Loading the msr kernel module and then the following sequence jolts the system back into a proper state:

rdmsr -a 0x19a

## if that does not produce 0's, then reset like this
wrmsr -a 0x19a 0x0
rdmsr -a 0x19a

This laptop is Dell 6430u. The problem only happens when running on battery, not on the cord.
Comment 61 Doug Smythies 2015-09-08 06:53:54 UTC
@Paul Johnson:

Thanks for your posting. I am trying to find examples such as you provided. And yes, all these bug reports often have entries for multiple issues. We are claiming that the main issue for this one has been solved. However, I know Alex still has some issues.

In the link you provided, you will see that I asked jat255 do do the same test, but using the acpi-cpufreq driver. While he said he would, it hasn't been done yet. Would you try it? Quoting myself from that link:

[with the acpi-cpufreq scaling driver] "The resulting effect on performance would be much less obvious, and some users might not even notice."
Comment 62 Piotr Kołaczkowski 2015-11-13 20:30:57 UTC
Just tried kernel 4.3.0  from ppa/mainline.
I have exactly the same problem as Paul Johnson.

After resume on battery:
pkolaczk@m4600 ~ $ sudo rdmsr -a 0x19a
1c
1c
1c
1c
1c
1c
1c
1c
rdmsr: No CPU 8


The workaround to write the msr register 0x19a to 0x0 works.

Previously I've been using all intel pstate patches from Doug with kernel 4.1.x and everything was fine. Did kernel 4.2.x and 4.3.0 not receive all of them?
Comment 63 Paul Johnson 2015-11-14 00:03:54 UTC
Running Ubuntu, with this kernel

Linux dellap14 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I see some new wrinkles after updating the Dell BIOS Firmware (version 6430uA10.exe, which was released 2015-11-04).  Before that, I was on a much older version of their BIOS.

Good news:  

The CPU used to max out at either 2.6GHz (on first boot on power) or 2.1GHz (after suspend).  Now it maxes out at 3.3GHz.    I'm absolutely certain that the maximum CPU frequency was 2.6MHz before the Bios upgrade. 
$ cpufreq-info -c3
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.30 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.30 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 859 MHz.

I can't say its actually doing work more quickly. Like re-labeling an amplifier so it goes up to 11, you know.

Bad news: 

After suspend I'm almost always locked at the super low CPU settings, but once I've seen it locked between 3.0 - 3.2GHz.

Doug's fix from before now works again. I see all "1c" for the rdmsr output and rewriting those to 0 restores the CPUs to a responsive state.

I was suspecting the DELL BIOS upgrade was the problem, but now I realize the Ubunutu kernel update came along immediately after that BIOS updated.

To save you the google, here is a link to Dell's page on that BIOS:

http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=DCPYK&fileId=3494492606&osCode=W864&productCode=latitude-6430u-ultrabook&languageCode=EN&categoryId=BI&DCP=DNDTAG

While in Dell's website, I found a forum with a bunch of Dell users complaining about this, and I see Doug Smithies has exerted himself to help those people too. Good work Doug!
Comment 64 Doug Smythies 2015-11-15 17:12:19 UTC
(In reply to Piotr Kołaczkowski from comment #62)
> 
> Previously I've been using all intel pstate patches from Doug with kernel
> 4.1.x and everything was fine. Did kernel 4.2.x and 4.3.0 not receive all of
> them?

Piotr,
My proposed patch set was recently rejected.
Thanks to you and several others for all the testing you helped with and test data you provided.
Comment 65 Piotr Kołaczkowski 2015-12-09 12:21:29 UTC
That's a real pity. Does that mean it won't be ever fixed? 
Funny, the wrmsr trick sometimes works and sometimes doesn't and I have to reboot.
Comment 66 Paul Johnson 2016-03-08 03:22:36 UTC
Problem has disappeared on my Dell 6430u ultrabook by this kernel update in Ubuntu:

4.2.0-30-generic #35-Ubuntu SMP Fri Feb 19 13:52:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I don't know if the kernel update was the fix, or some accompanying firmware or such.  

Will eagerly wait for additional updates that make this stop working again...
Comment 67 Joey Dumont 2016-03-22 14:43:22 UTC
This is still an issue for me. After suspend, processors will sometimes be "stuck" at lower frequencies.

valandil ~ $ uname -a
Linux terra 4.4.5-1-ARCH #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 x86_64 GNU/Linux

The mrmsr trick did not work for me, and neither did the powersave -> performance -> powersave governor cycling. Only a reboot seems to restore the ability to scale the frequencies.
Comment 68 Doug Smythies 2016-03-22 15:11:55 UTC
(In reply to Joey Dumont from comment #67)

Please provide the make and model number of your computer. Also the make and model number of your CPU (grep "model name" /proc/cpuinfo).
Comment 69 Joey Dumont 2016-03-22 15:15:53 UTC
I have a Lenono Y510P laptop. 

valandil ~ $ grep "model name" /proc/cpuinfo 
model name	: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
Comment 70 Doug Smythies 2016-03-22 15:36:13 UTC
(In reply to Joey Dumont from comment #69)
> I have a Lenono Y510P laptop. 
> 
> valandil ~ $ grep "model name" /proc/cpuinfo 
> model name    : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz

Your problem is this one: https://bugzilla.kernel.org/show_bug.cgi?id=114551

Note You need to log in before you can comment on or make changes to this bug.