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
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)
--
pm-utils changes default cpu policy after resuming from suspend-to-ram
https://bugs.launchpad.net/bugs/162652
You received this
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
Fixed vlowther's patch
** Attachment added: fix typo
http://launchpadlibrarian.net/12882741/fix-94cpufreq-in-pm-utils.patch
--
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
+ [ -L $x/cpugreq ] continue
there is a typo (cpufreq) in your path, but generally it works, thanks.
--
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
Seriously, lets get this fixed, its been around for a long time now. Up
to date and still happens every resume.
--
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
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
it would have been if I hadn't have reversed the logic and the patch. :(
Updated patch attached.
** Attachment added: fix-94cpufreq-in-pm-utils.patch
http://launchpadlibrarian.net/12827339/fix-94cpufreq-in-pm-utils.patch
--
pm-utils changes default cpu policy after resuming from
vlowther: your patch works for me.
thanks :)
--
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 subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Still experiencing this on up-to-date Hardy. This is annoying for
desktop users, but very problematic for Laptop users.
--
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
** Changed in: pm-utils (Ubuntu)
Status: New = Confirmed
--
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 subscribed to Ubuntu.
--
Is this related to bug 19062 perhaps?
--
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 subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Is 19062 the correct bug number? It appears totally unrelated.
--
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 subscribed to Ubuntu.
--
This has been patched upstream
** Attachment added: 264aea5efe616901dcf8183d428ae4a43d9b2a5a.txt
http://launchpadlibrarian.net/12351717/264aea5efe616901dcf8183d428ae4a43d9b2a5a.txt
--
pm-utils changes default cpu policy after resuming from suspend-to-ram
...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=5748sc=1
Thanks
Steve
--
pm-utils changes default cpu policy after resuming from suspend-to-ram
https://bugs.launchpad.net/bugs/162652
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 -
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
17 matches
Mail list logo
