** Changed in: linux
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/326149
Title:
ondemand cpufreq governor reacts too slowly
To manage notifications about
** Changed in: linux
Status: In Progress => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/326149
Title:
ondemand cpufreq governor reacts too slowly
To manage notifications about t
Bump?
I'd prefer to continue here instead of opening a new report as the
automated scripts wrote. Please set this bug to "Confirmed" or confirm
that a new page is really what is intended in this case.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
** Changed in: linux
Status: Unknown => In Progress
** Changed in: linux
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/326149
Title:
ondemand cpufreq governo
Please reopen this bug. According to the upstream report on kernel.org
it is still an issue with 2.6.37 and probably 2.6.38.
A workaround is mentioned there: set .../cpufreq/ondemand/sampling_rate
to sampling_rate_min
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Bug watch added: Linux Kernel Bug Tracker #30712
http://bugzilla.kernel.org/show_bug.cgi?id=30712
** Also affects: linux via
http://bugzilla.kernel.org/show_bug.cgi?id=30712
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of U
This bug was filed against a series that is no longer supported and so
is being marked as Won't Fix. If this issue still exists in a supported
series, please file a new bug.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
I am also affected by this. CPU's slow to respond to increased demand
while in On Demand mode set by Frequency Scaling applet. Resulting in
applications greying out for a few moments.
I am going to try the fix posted by Rocko
*
Modifying /etc/init.d/ondemand (this sets both CPUs' up thresh
I also have this issue. Since the ondemand up_threshold is set default
at 80, browsing is somewhat less responsive compared to using
performance governor. I fixed this by modifying the /etc/init.d/ondemand
to set the up_threshold to 20. However, this is not a permanent fix.
When I switch power prof
I was looking to post a bug report about the ondemand governor, but this one
looks similar enough [see what you guys think, I'll open a new report if it's
too different].
My problem is similar, except it's not that the governor reacts too slowly,
more that it doesn't give enough Hz when doing so
I have another X2 running Hardy LTS (i386) and haven't noticed this
behavior before with cpu frequency scaling.. for reference,
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold on the system
that always just worked was a paltry 31. This issue probably explains
why a somewhat slower syste
I have noticed this as well, but mostly when watching video content that
stresses the CPU more at certain points, when there is a lot of
movement. Totem starts having to drop frames, by the time the CPU
frequency increases, the need for more performance has often passed. I
am running jaunty amd64
Just confirming that modifying /etc/init.d/ondemand works for me (this
sets both CPUs' up threshold to 40):
echo -n ondemand > $CPUFREQ
# set a more aggressive upscale factor. This should set both
cpu0 and cpu1
echo -n 40 >
/sys/devices/system/cpu/
Jaunty has a startup script called /etc/init.d/ondemand which sleeps for
60 seconds to allow login and then tries to set the governor to ondemand
(that explains why sometimes my Jaunty boots up in performance mode, not
ondemand mode). You could try adding the 'echo 30 >
/sys/devices/system/cpu/cpu0
Since upgrading to jaunty, the entry in /etc/rc.local no longer works,
as the CPU is on "performance" during startup (thus the sysfs files for
ondemand are not there).
Is there another way to make the fix permanent?
--
ondemand cpufreq governor reacts too slowly
https://bugs.launchpad.net/bugs/3
I'm experiencing something like this bug, but only after the computer
has been running for a while. It's most noticeable playing games under
wine: after rebooting I get a good frame rate, whereas after the
computer has been on for some hours if I play the same game I have to
set the CPUs to perform
After a recent reinstall of my laptop (got a new HDD and wanted to start
fresh), this affects my laptop, too. After applying the lower
up_threshold, especially scrolling in the web browser feels much
snappier.
To keep it permanent, I just added the line to my /etc/rc.local.
As a refinement, one c
As a workaround, I have these lines in my rc.local to fix my two cores:
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 30 > /sys/devices/system/cpu/cpu1/cpufreq/ondemand/up_threshold
The default value of 95 seems tad high. I think it takes about 2 seconds
here before CP
** Attachment added: "dmesg.txt.gz"
http://launchpadlibrarian.net/22042568/dmesg.txt.gz
--
ondemand cpufreq governor reacts too slowly
https://bugs.launchpad.net/bugs/326149
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-
19 matches
Mail list logo
