Bug 90421
Created attachment 162031 [details]
kernel config
This bug might be related or even a duplicate of this one: https://bugzilla.kernel.org/show_bug.cgi?id=66581 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 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.
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. This problem exists from 2013-12-05 ([Bug 65301]). One year and 3 months. I have latest kernel 3.19. Bug is still there. 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
(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. 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.
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. Created attachment 176371 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
Created attachment 176381 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Created attachment 176391 [details]
dmesg
Created attachment 176401 [details]
.config
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...). @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. 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, ) 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. 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. (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. 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. 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. (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. 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. (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. ;) 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.
Created attachment 177251 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Created attachment 177261 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
(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. 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. Created attachment 177311 [details]
"perf record -a --event=power:pstate_sample sleep 300" after suspend (gzipped)
Created attachment 177321 [details]
"perf record -a --event=power:pstate_sample sleep 300" before suspend (gzipped)
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: ...
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? Created attachment 177391 [details]
perf sleep 300 before -- minimal load
Created attachment 177401 [details]
perf sleep 300 after -- minimal load
Created attachment 177411 [details]
turbostat sleep 10 before -- minimal load
Created attachment 177421 [details]
turbostat sleep 10 after -- minimal load
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. Created attachment 177471 [details]
after durations
graph 2 of 4. After durations (the times between intel_pstate driver executions, per CPU.
Created attachment 177481 [details]
before frequencies
graph 3 of 4: Before Frequencies. Notice the subtle differences between this graph and the after graph.
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.
(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... :( @Marien: I have re-created your situation on my test computer, so I should be able to make progress now. (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? (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. Btw, it looks good. :-) The driver still scales the frequency correctly, even resuming from suspend. :-) (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). 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).
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. Created attachment 177741 [details]
Same patch but based against an unmodfied kernel 4.0
Maybe this version will work for you.
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. 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.
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.
@Doug: Will the proposed patchset (the math lockup issue) be merged into the mainline kernel? @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. @Marien: I have used your method to test Kernel 4.2RC1 and the issue is resolved. Please confirm or deny by testing also. patches have been shipped in upstream kernel 3.2-rc1. bug closed. 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. @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." 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? 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! (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. 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. 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... 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. (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). I have a Lenono Y510P laptop. valandil ~ $ grep "model name" /proc/cpuinfo model name : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz (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 |
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