Bug 164147

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


gnome-applets-2.12.1-2
kernel-2.6.14-1.1632_FC5

Hello,

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

Could you please post the content of
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

or (better) the output of
cpufreq-info

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)

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace

No cpufreq-info on this system

ditto for me:

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

No cpufreq-info on this system

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 
/usr/src/redhat/SOURCES/gnome-applets-2.11.1-cpufreq.patch

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

Regards,
Ingo

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

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

Hi,

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