This bug is Dependant on broken cpufreq in bug #183033 The problem is that cpu1 does not have it's own cpufreq control as it did in Hardy
# ls -l /sys/devices/system/cpu/cpu* | grep cpufreq drwxr-xr-x 3 root root 0 Feb 5 15:24 cpufreq lrwxrwxrwx 1 root root 0 Feb 5 16:39 cpufreq -> ../../../../devices/system/cpu/cpu0/cpufreq When suspending, pm-utils switches the CPUs to performance governor (not sure why, but probably a reliability issue). The steps are: 1. Save CPU0 governor 2. Set CPU0 to performance 3. Save CPU1 governor (which is picking up performance as set on cpu0) 4. Set CPU1 to performance Since they share cpufreq settings, it ends up saving the following states: cpu0_governor_STATE=ondemand cpu1_governor_STATE=performance Naturally, it follows that on resume it will restore the ondemand governor (which applies to both CPUs), then replace it with the performance governor. -- pm-utils changes default cpu policy after resuming from suspend-to-ram https://bugs.launchpad.net/bugs/162652 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
