After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 320296 - cpufreq applet only pushes frequencies up, never down
cpufreq applet only pushes frequencies up, never down
Status: RESOLVED NOTGNOME
Product: gnome-applets
Classification: Other
Component: cpufreq
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-31 10:18 UTC by Nicolas Mailhot
Modified: 2005-11-12 16:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Mailhot 2005-10-31 10:18:38 UTC
Version details: gnome-applets-2.12.1-2
Distribution/Version: Fedora Core Devel (Raw Hide), 31.10.2005

Once you've used the cpufreq applet to raise frequencies, they never go down,
either automatically or when you try to use the frequency menu. This lowers the
value of the applet a lot

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164147 for several
people reporting the same problem
Comment 1 Nicolas Mailhot 2005-11-12 15:07:17 UTC
I've just notoced 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
Comment 2 Nicolas Mailhot 2005-11-12 16:20:05 UTC
After more testing, the bug is in one small patch Red Hat uses -> closing