Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coming Back From Suspend, Freq Number Doesn't change #32

Closed
dsreyes1014 opened this issue Apr 23, 2016 · 4 comments
Closed

Coming Back From Suspend, Freq Number Doesn't change #32

dsreyes1014 opened this issue Apr 23, 2016 · 4 comments

Comments

@dsreyes1014
Copy link

When coming back on from suspend the frequency number doesn't change no matter what profile I use.

@martin31821
Copy link
Member

Is this reproducable?
Can you try to set the frequency manually using cpufreqctl?

@Znert
Copy link

Znert commented May 1, 2016

I am not sure how to reproduce this error, but I have the same issue.

I noticed however, that the governor of my CPU is always set to "performance" (not only after suspend but also when plugging the laptop in) which does not allow frequency changes.
Apparently this is intended behavior, however, as it is less efficient to calculate how high the frequency should be for the next task.

So I don't think that it's the fault of the extension but rather the kernel's.

A workaround is to set the governor back to powersave via "sudo cpufreq-set -g powersave" (or any other governor which allows freqency changes, check "cpufreq-info" for more details for your CPU).

Not sure if it's helpful or not, but my CPU is Intel i5-4210U.

@martin31821
Copy link
Member

When using intel pstate, you shouldn't use any kind of governor as this is the oldfashioned acpi power management.
Please check if you are actually using the pstate driver to manage your frequency.

@Znert
Copy link

Znert commented May 2, 2016

Yesterday I updated my laptop to Ubuntu Gnome 16.04, which did not go down smoothly at all and so I had to reinstall Ubuntu as a whole...

The good thing is, the problem no longer persist and I can freely change the frequency at any time.

The bad thing however, I no longer can reproduce the error myself and also can't double check if I was using psate or not. But still, I am convinced that I actually was using intel pstate according to "cpufreq-info"...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants