Public bug reported:
Binary package hint: pm-utils
Hardy x86_64
pm-utils-0.99.2-3ubuntu1
When transitioning into S3 or S4, pm-utils saves off current cpufreq
scaling governors in sleep.d/94cpufreq. For each cpufreq-supporting CPU
(identified by $x) in /sys/devices/system/cpu/ it does:
savestate ${x}_governor ${cat $x/cpufreq/scaling_governor}
sh -c "echo performance > $x/cpufreq/scaling_governor" > /dev/null 2>&1
i.e. saves off the current state and then puts the CPU into performance
mode (presumably to speed up the sleep transition). The states are
restored on thaw.
The problem is that on a, say, dual-core machine, cpu0 and cpu1 are
actually the same physical CPU. The first time through the loop, it
saves off the cpu0 governor - let's say ondemand - and then puts cpu0
into performance. However, because cpu0 is effectively cpu1, this also
puts cpu1 into performance, so the next time round the loop, cpu1 gets
its state saved as performance when it should actually be ondemand. The
problem manifests itself on thaw, when state is resumed in FIFO order
meaning that the machine gets brought back up into the spurious
performance governor rather than the desired ondemand governor.
Expected: machine thaws back to original governor
Actual: machine thaws back to performance, always
** Affects: pm-utils (Ubuntu)
Importance: Undecided
Status: New
--
pm-utils incorrectly handles multi-core cpufreq on sleep
https://bugs.launchpad.net/bugs/197646
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
