pm-utils changes default cpu policy after resuming from suspend-to-ram

[Luke12]

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.

[mtvoid (mtvoid)]

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.

[Chris Irwin (chrisirwin)]

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.

[Thomas Novin (thomasn80)]

Is this related to bug 19062 perhaps?

[mtvoid (mtvoid)]

Is 19062 the correct bug number? It appears totally unrelated.

[Steve (st3v3)]

This has been patched upstream

[Steve (st3v3)]

...which made it into debian svn as r5748 (as part of the new upstream release)

http://svn.debian.org/wsvn/collab-maint/ext-maint/pm-utils/trunk/pm/hooks/?rev=5748&sc=1

Thanks
Steve

[Chris Irwin (chrisirwin)]

Still experiencing this on up-to-date Hardy. This is annoying for desktop users, but very problematic for Laptop users.

[jnewton (nevion)]

Seriously, lets get this fixed, its been around for a long time now. Up to date and still happens every resume.

[vlowther (victor-lowther)]

This patch will fix it.

Cpus that share cpufreq settings have their cpufreq settings symlinked together. What is happening is that we are saving several conflicting cpufreq settings (depending on the number of cores that share the same settings). The first time settings are saved for a given cpu group the correct ones are saved, the ones after that are all userspace. If the order in which the settings are restored are not the exact opposite, we will get the settings wrong.

The easiest way to avoid the whole situation is to skip any cores that are symlinked when saving settings. Their settings will be restored correctly when we restore the settings for whatever non-symlinked core they are grouped with.

[vlowther (victor-lowther)]

it would have been if I hadn't have reversed the logic and the patch. :(

Updated patch attached.

[Jörn Schmidt (josc)]

vlowther: your patch works for me.
thanks :)

[Aurimas Fišeras (aurimas-gmail)]

+ [ -L $x/cpugreq ] && continue
there is a typo (cpufreq) in your path, but generally it works, thanks.

[Chris Jones (cmsj)]

Fixed vlowther's patch

[Launchpad Janitor (janitor)]

This bug was fixed in the package pm-utils - 0.99.2-3ubuntu5

---------------
pm-utils (0.99.2-3ubuntu5) hardy; urgency=low

  * Fix typo in 95-fix-config-file-parsing.patch which made loading
    configs from /etc/pm/config.d/* break. LP: #190679
  * Add 35-skip-linked-cpus-cpufreq.patch which skips all CPUs whose speed
    is shared with other CPUs (or cores) when saving state. LP: #162652.

 -- Tollef Fog Heen <email address hidden> Wed, 26 Mar 2008 09:00:25 +0100

[zakimak (zakimak)]

I am sorry but i think that there is still a little problem with some users : https://bugs.launchpad.net/dell/+bug/183033 (3 users reported that this fix don't work)

[Cé (cedric-dewijs-telfort)]

I have the same problem. To reproduce:

I set CPU0 at 800Mhz (via CPU Frequency Scaling Monitor 2.24.1). Both CPU0 and CPU1 then goto 800Mhz (lowest setting)
 Then I suspend, then I come back from suspend, and my CPU0 and CPU1 are set to 1800Mhz (Highest setting)

I run PM-utils 1.1.2.4-1ubuntu8.1 on ubuntu 8.10
I have a Dell Vostro 1710
Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz stepping 0d