pm-utils changes default cpu policy after resuming from suspend-to-ram
Bug #162652 reported by
Luke12
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pm-utils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: pm-utils
I am using a Dell Inspiron 6400. After resuming from suspend using pm-utils, the default policy changes to "top performance" regardless of the policy I set in gnome-power-manager (yes, I reconfigured gnome-applets to be able to do that as a user and also hacked with gconf-editor to be able to set the policy in the power-manager program. IMHO this should be done by default, as in Windows and KDE :) ). Acpi does not show a similar behaviour, leaving the correct policy set. I do not know if in a standard Gutsy installation (with no user access to cpu policies) this bug would show up as well.
Related branches
Changed in pm-utils: | |
status: | New → Confirmed |
To post a comment you must log in.
I see this happening too, since I started tracking hardy which has made the switch to the pm-utils infrastructure. I have to resort to restarting powernowd every time after I resume. Looking at /var/log/ pm-suspend. log, it appears that all the resume hooks are running, which includes /usr/lib/ pm-utils/ sleep.d/ 94cpufreq. That script should set the governor back to ondemand, but apparently that's not happening, and the governor remains performance instead of switching back to ondemand.