Bug 164147 - CPU Frequency Scaling Monitor turns CPU up, but not down.
Summary: CPU Frequency Scaling Monitor turns CPU up, but not down.
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-applets
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Mike McLean
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
Reported: 2005-07-25 12:05 UTC by Rodd Clarkson
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-14 18:32:38 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 320296 0 None None None Never

Description Rodd Clarkson 2005-07-25 12:05:23 UTC
Description of problem:

On my laptop (a Centrino 2.0GHz 533FSB) the CPU sits at 800MHz to start with,
and will scale up and down as the load increases and decreases.

If I click on the icon and select 2.0GHz from the list, then the CPU is shown as
running at 2.0GHz and cat /proc/cpuinfo shows the CPU running at

      cpu MHz         : 1995.231

Close enough.

If I then click on the 800MHz option (the lowest setting) the CPU stays at 2.0GHz.

If then run something CPU intensive and stop it (glxgears) the CPU then scales
back to 800MHz.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

See above.

Actual results:

CPU doesn't scale back down.

Expected results:

I would expect the CPU to go back to running at 800Mhz

Comment 1 Nicolas Mailhot 2005-10-31 10:00:31 UTC
Same thing here, there's no way to lower frequencies once they've been pushed up :

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3500+
stepping        : 0
cpu MHz         : 2211.357
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
pni lahf_lm
bogomips        : 4427.40
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


Comment 2 Ingo Schaefer 2005-11-08 09:58:36 UTC

I think, one should need more information to find out what happens.

Could you please post the content of

or (better) the output of

As far as I could see in my (older) FC4 version, the applet sets the frequency
correctly and the governor sets it back after a short time. So maybe they are
interfering in some way.

I think, the gnome-cpufreq-applet should set the givernor to userspace, if the
user changes the frequency. (and it should have some kind of way to set it back
to the governor before)

Comment 3 Nicolas Mailhot 2005-11-08 14:20:31 UTC
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

No cpufreq-info on this system

Comment 4 Rodd Clarkson 2005-11-08 23:25:29 UTC
ditto for me:

[rodd@localhost ~]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

No cpufreq-info on this system

Comment 5 Ingo Schaefer 2005-11-09 10:11:26 UTC
Hi there,

it seems to me, that one of the patches applied by redhat in the rpm build
process is wrong.

If you install the src.rpm of gnome-applets, you can find 

which contains the following:
-        command = g_strdup_printf ("%s -f %d", path, freq);
+        command = g_strdup_printf ("/usr/bin/cpufreq-selector -f %d", path, freq);

As you can see, the function g_strdup_printf is called with three parameters,
but the first one (format string) contains only one parameter to be substituted.)

I can't figure out, what the result of this is and/or if it causes your problem
- but this patch was not there in versions before 2.11.1

I have no laptop with rawhide around, so I neither check this nor create a new
rpm without this line


Comment 6 Nicolas Mailhot 2005-11-12 15:06:24 UTC
I've just noticed this interetgin bit in /var/log/secure :

- When asking for 2,2 GHz :

Nov 12 16:05:19 rousalka userhelper[17254]: running '/usr/sbin/cpufreq-selector
-f 6476944' with root privileges on behalf of 'nim'

- When asking for 1 GHz

Nov 12 16:06:32 rousalka userhelper[17268]: running '/usr/sbin/cpufreq-selector
-f 6539776' with root privileges on behalf of 'nim'

So it seems the root of the problem is the applet calling
/usr/sbin/cpufreq-selector with bogus parameters

I'll try the fix you proposed ASAP - needs to get my system back in bootable
state first

Comment 7 Nicolas Mailhot 2005-11-12 16:16:37 UTC
Ok, I can confirm the obvious fix 

-        command = g_strdup_printf ("%s -f %d", path, freq);
+        command = g_strdup_printf ("/usr/bin/cpufreq-selector -f %d", freq);

fixes the the applet. So it's a bug in the Fedora patch, not in the upstream version

-> promoting to FC5Blocker as the fix is known, and closing the upstream bug

Comment 8 Ray Strode [halfline] 2005-11-14 18:32:38 UTC

Thanks guys for figuring this out.  Fix should be in tomorrow's rawhide.

Note You need to log in before you can comment on or make changes to this bug.