Processor speed limited after suspend in 15.10.

[Aisteru]

I just noticed today that my CPU frequency is limited when I wake my computer from suspend. The maximum CPU speed is set to 3.10 GHz when I first boot, but is 2.48 GHz after suspending an waking the system. This drops again after each suspend, bottoming out at 1.24 GHz.

The same thing happens with either intel_pstate enabled or the older acpi-cpufreq, but the numbers are different: with intel_pstate the numbers are 3.10 GHz, 2.48 GHz, 1.86 GHz, and 1.24 GHz., but with acpi-cpufreq the numbers are 2.5 GHz, 2 GHz, 1.5 GHz, 1 GHz, as reported by cpufreq-info. This would mean that it is falling by .62 GHz with one driver, and by .5 GHz with the other. I don't know if this could be important.

When using the acpi_cpufreq driver, unlike when using intel_pstate, the maximum when first booted is set at 1.5GHz. This can be changed by using cpufreq-set, but after suspending it drops as described above, and cpufreq-set cannot raise it.

Can anyone clue me in as to what might be lowering the CPU speed? Any help would be appreciated.

[Doug S]

I have heard of this before, but don't know the root issue.

While running with the intel_pstate frequency scaling governor, and while you have the issue could you do these commands and provide the output for your computer:

doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_max_freq
3800000
3800000
3800000
3800000
3800000
3800000
3800000
3800000
doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq
1600000
1600000
1600000
1600000
1600000
1600000
1600000
1600000
doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
3800000
3800000
3800000
3800000
3800000
3800000
3800000
3800000
doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq
1600000
1600000
1600000
1600000
1600000
1600000
1600000
1600000
doug@s15:~$ grep . /sys/devices/system/cpu/intel_pstate/*
/sys/devices/system/cpu/intel_pstate/max_perf_pct:100
/sys/devices/system/cpu/intel_pstate/min_perf_pct:42
/sys/devices/system/cpu/intel_pstate/no_turbo:0
/sys/devices/system/cpu/intel_pstate/num_pstates:23
/sys/devices/system/cpu/intel_pstate/turbo_pct:18
doug@s15:~$ sudo modprobe msr
doug@s15:~$ sudo rdmsr -a 0x19a  <<< you needs msr-tools package for this one.
0
0
0
0
0
0
0
0
doug@s15:~$

[Aisteru]

This is what I got:

timmy@unicorn:~$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_max_freq
cat: /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_max_freq: No such file or directory
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq
cat: /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq: No such file or directory
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
cat: /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq: No such file or directory
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq
cat: /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq: No such file or directory
timmy@unicorn:~$ grep . /sys/devices/system/cpu/intel_pstate/*
/sys/devices/system/cpu/intel_pstate/max_perf_pct:80
/sys/devices/system/cpu/intel_pstate/min_perf_pct:25
/sys/devices/system/cpu/intel_pstate/no_turbo:0
/sys/devices/system/cpu/intel_pstate/num_pstates:24
/sys/devices/system/cpu/intel_pstate/turbo_pct:25
timmy@unicorn:~$ sudo modprobe msr
[sudo] password for timmy: 
timmy@unicorn:~$ sudo rdmsr -a 0x19a
8
8
8
8
timmy@unicorn:~$

After poking around looking for the missing files, I discovered I have no /sys/devices/system/cpu/cpufreq/policy* folders. Inside /sys/devices/system/cpu/ I find what seems to be a directory for each virtual core (amoung other things,) but none of those have policy directories. The closest I could come to matching what you asked for was:

timmy@unicorn:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq 
3100000
3100000
3100000
3100000
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_min_freq
800000
800000
800000
800000
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
2480000
2480000
2480000
2480000
timmy@unicorn:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
800000
800000
800000
800000
timmy@unicorn:~$

[Doug S]

re: no policy directory: I guess 15.10 still has an older version of the intel_pstate driver. Sorry, I thought it was up to date.

I do not know why or how /sys/devices/system/cpu/intel_pstate/max_perf_pct gets set to 80%. You can set it back via:

echo "100" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct

While you are reading an odd value from the clock modulation register (19A), it is disabled (which is good).

Your numbers seem to indicate max_perf_pct goes from 100% to 80% to 60% to 40% with each subsequent suspend. Could you confirm?

When running with the acpi-cpufreq frequency scaling driver, and when stuck at 1.5 GHz, what do you get reading register 19A?

What is the make and model of your computer?

[Aisteru]

I tried

echo "100" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct

but when I used 'cat' to read the value, it printed '80'

You are correct, max_perf_pct does go from 100% to 80% to 60% to 40% with each subsequent suspend.

When running with the acpi-cpufreq frequency scaling driver, I get the same results from the 'rdmsr -a 0x19a' command as before:

root@unicorn:~# rdmsr -a 0x19a
8
8
8
8

And lastly, the computer in question is a Lenovo g510 Laptop.

[Doug S]

the computer in question is a Lenovo g510 Laptop.

The other similar case is Lenovo also. I wonder about a BIOS issue.

Are you running any thermal daemon, such as thermald or tlp or whatever? If yes, could you try to disable, just as a test.

[Aisteru]

It hadn't started causing noticeable problems until recently, but I guess it could be a BIOS issue.

Thermald was running, but stopping it didn't seem to change the behavior. If I understood better what was going on when I hit suspend, I'd have a better idea of where to look for the cause. I suspect there is something wrong with the suspend-time scripts, but I don't know where to look; when I tried researching suspend-related issues before, i didn't have much luck finding up-to-date information on what goes on under the hood.

[Doug S]

It hadn't started causing noticeable problems until recently, but I guess it could be a BIOS issue.

Could you go back and try a previous kernel? You could also try the most recent release candidate kernel, to see if the issue is fixed.

If I understood better what was going on when I hit suspend, I'd have a better idea of where to look for the cause. I suspect there is something wrong with the suspend-time scripts, but I don't know where to look; when I tried researching suspend-related issues before, i didn't have much luck finding up-to-date information on what goes on under the hood.

Is there anything in the /var/log directory? You could also suspend and resume manually, and see if there is anything in the /var/log/pm-suspend.log file.

[Aisteru]

Could you go back and try a previous kernel? You could also try the most recent release candidate kernel, to see if the issue is fixed.

Wow! I tried an older kernel (I think it's 4.2.0-19-lowlatency) and now things seem to be back as they should be, at least as far as this issue. Thank you so much for all the help!

Is there anything in the /var/log directory? You could also suspend and resume manually, and see if there is anything in the /var/log/pm-suspend.log file.

I did see a lot of information in /var/log/pm-suspend.log about the suspend/hibernate scripts, so thanks for pointing that out as well.

I'm going to mark this thread as solved.

I wonder if you could shed some light on my other problem? http://ubuntuforums.org/showthread.php?t=2315306 I don't mean to impose, but no one has offered any ideas yet.

[Doug S]

What is the problematic kernel version? (I want to mention it on that other thread.)
If interested, you could continue to help with this issue by trying the current 4.5-rc7 kernel and by filing a bug report if it still has the issue. The next step would be to bisect the kernel to isolate the offending commit.

Did you try the older kernel for your other thread? Otherwise, I don't have a suggestion for it.