If you're using powernowd, you should be using the userspace governor, not the ondemand one. powernowd will automatically set this when starting up, which is why restarting powernowd solves the problems you are all seeing.
When the system goes to sleep and comes back, apparently the kernel (or Ubuntu suspend scripts) aren't saving/restoring the right governor settings. This, to me, is a real bug, as suspend/restore is supposed to restore the system exactly how it was. powernowd has no way of knowing when a suspend happened, nor should it. I can try and work around this in powernowd by periodically polling the scaling_governor file and resetting it to userspace if someone changes it out from under us. But I know of use cases where that would break other people (some people like to run powernowd all the time, and just "temporarily disable it" by changing the governor to performance for a while, and then change it back to userspace and powernowd just works again, all without restarting powernowd. ) my guess is, if you run powernowd with the -d -vv options by hand and then suspend/resume, you'll see that it's actually chugging along as normal, trying to control both cpus, but it speed change requests are ignored by the fact the system is using the wrong governor after suspend. john.c (powernowd author, and someone who just noticed this on his company's macbook pro core duo running edgy) -- After hibernation, powernowd only controls one CPU https://launchpad.net/bugs/47513 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
