I'm not sure if this is being tracked elsewhere, but I'm certainly
finding that /sys/devices/system/cpu/cpufreq/ondemand/up_threshold (for
example) gets reset after resume from sleep.
I'm using sysfsutils and my workaround is to drop a script in
/etc/pm/sleep.d/90_sysfsutils:
#!/bin/sh
# Tell gr
Hi!
I'm not using Ubuntu right now. Running Gentoo with kernel 2.6.25 with
processor ACPI compiled in the kernel as well as cpu frequency scaling
and governors and the problem do exists on my setup. Maybe this confirm
it's a kernel issue. Any information i can provide, just ask.
Running on Dell
sudo modprobe -r acpi_cpufreq is not allowed, requiring full reboot to
fix cpu scaling
"FATAL: Module acpi_cpufreq is in use."
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification because you ar
Dell XPS m1330
Intel Core 2 Duo 1.5ghz
Hardy 8.04 w/latest
I am NOT running powernowd -- I am using ondemand directly via and made
permanent via sysfs.conf
I can confirm after resume from suspend, CPU1 is locked at its maximum.
This is not a cosmetic bug, as powertop reports ~3-4 watts greater us
I am also experiencing this on Dell Latitude D830, running 64_x86 8.04
beta + updates. I logged output from "dmesg", "cat
/sys/devices/system/cpu/*/cpufreq/*" (and "cat /proc/cpuinfo" for the
heck of it) both before a suspend (both cores in ondemand mode) and
after coming back from suspend (core#1
I have the a similar problem with Hardy.
After resume, both cpu cores are set to performance governor
and full speed.
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification because you are a membe
Setting status back to confirmed since previous fix apparently doesn't
work as expected.
** Changed in: acpi-support (Ubuntu)
Status: Fix Released => Confirmed
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You recei
Tested this with the new Hardy Alpha 5 LiveCD.
CPU1 gets stuck at 2 GHz (full speed) again now after resuming from a
suspend.
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification because you are
I think I have the same problem. on the early Gutsy final versions, CPU1
got stuck on 2 GHz (full speed) most of the time after a suspend-to-ram.
But now CPU1 always gets stuck at 800 MHz (lowest speed) after a
suspend. Performance scaling with CPU0 works fine.
I have added a more detailed comment
I have seen this bug report and the dups. Not sure which one to choose.
This seems to be the best. I have attached the output of $cpufreq-info.
I always have this problem since upgrade to 7.10. Does not require a
suspend. Alway the same. The output
current policy: frequency should be within 1000 M
Does anyone else think this might be a duplicate of #124797 or #183033
(or both?)
It's hard to tell, but they definitely seem related to me.
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification
Problem still exists for me: No /sys/devices/system/cpu/cpu1/cpufreq on
resume. I am using acpi-support scripts to suspend my system instead of
powersaved, however, because powersaved does not resume my nVidia
graphics card properly.
I'm on Gutsy (7.10) right now, is there a fix available yet?
--
An addition: the governor on CPU1 is now 'userspace' after suspend.
However, it still stays at top speed without any usage.
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification because you are a
It still does not work on a Lenovo T60.
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://bugs.launchpad.net/bugs/68191
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing
acpi-support (0.94) feisty; urgency=low
* Save and restore values that the kernel does not preserve across
suspend/resume and hibernate/resume:
- /sys/class/net/eth*/device/rf_kill
(Closes: LP #37010)
- /proc/acpi/ibm/bluetooth
(Closes: LP #37175)
- /sys/devices/system/cp
** Changed in: acpi-support (Ubuntu)
Assignee: (unassigned) => Paul Sladen
Status: Confirmed => In Progress
--
cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.
https://launchpad.net/bugs/68191
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
htt
We did some investigation into this (see bug #78512). Turns out that
the kernel hotunplugs the CPUs during a suspend/resume, so the CPUs
actually /disappear/ and therefore can't retain their state.
Ideally this is fixed in 'udev' in the long run with hotplug CPU
support; in the medium term we'll
17 matches
Mail list logo
