cpu frequency is reset to maximum after resume from suspend if governor is userspace
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cpufrequtils (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
steps to reproduce:
1) use cpufreq-applet to set cpu freqency to a fixed value (userspace governor) that is not maximum (e.g. 800mhz on a 1.7ghz cpu)
2) suspend
3) resume
4) see that cpu freqency governor is still userspace but frequency is maximum (e.g. 1.7ghz, userspace)
i use the cpufreq-applet for all monitoring and manipulating cpu frequency scaling, but i don't think this is a bug of the applet itself. i didn't select any package because i don't know which one. ubuntu version is 9.04. please tell me which further information i should provide.
EDIT: i'm an idiot, i've been getting these messages for days when resuming from standby, i just didn't take notice:
cpufreq: suspend failed to assert current frequency is what timing core thinks it is
cpufreq: resume failed to assert current frequency is what timing core thinks it is
summary: |
- cpufreq reset to maximum after resume from suspend if governor=userspace + cpufreq reset to maximum after resume from suspend if governor is + userspace |
summary: |
- cpufreq reset to maximum after resume from suspend if governor is - userspace + cpu frequency is reset to maximum after resume from suspend if governor + is userspace |
description: | updated |
Changed in cpufrequtils (Ubuntu): | |
status: | Incomplete → Confirmed |
Changed in cpufrequtils (Ubuntu): | |
status: | Confirmed → Triaged |
importance: | Undecided → Medium |
I'm also hitting this in Lucid, though without the messages reported by Andreas. I originally reported it as bug 512686.