GNOME Bugzilla – Bug 367393
CPU Frequency Scaling Monitor 2.16.0.1 second core monitor does not update after hibernation/resume
Last modified: 2006-11-20 11:52:13 UTC
Please describe the problem: I find that when I resume2 the monitor applet does not report the status of my second core (cpu1) correctly indicating only that it is at "performance" and 100% 2.16G even though the actual status is correctly reported in the system. spitfire cpu # cd cpu1/ spitfire cpu1 # ls cache cpufreq online topology spitfire cpu1 # cd cpufreq/ spitfire cpufreq # ls affected_cpus ondemand scaling_driver stats cpuinfo_cur_freq scaling_available_frequencies scaling_governor cpuinfo_max_freq scaling_available_governors scaling_max_freq cpuinfo_min_freq scaling_cur_freq scaling_min_freq spitfire cpufreq # cat scaling_cur_freq 1000000 spitfire cpufreq # cat scaling_governor ondemand Steps to reproduce: 1. Have both cores displaying in deskbar 2. hibernate and resume 3. see the second core with the icon showing full speed and compare with system state. Actual results: notice that after I suspend my Gnome (2.16 and 2.14) cpufreq panel applet : CPU Frequency Scaling Monitor 2.16.0.1 only shows the correct freq and governor on CPU 0 after resuming from hibernation. CPU1 sits at 100% and reports performance governor. I can confirm that the CPU itself is Ondemand and at the level of CPU0 directly. Code: spitfire cpu # cd cpu1/ spitfire cpu1 # ls cache cpufreq online topology spitfire cpu1 # cd cpufreq/ spitfire cpufreq # ls affected_cpus ondemand scaling_driver stats cpuinfo_cur_freq scaling_available_frequencies scaling_governor cpuinfo_max_freq scaling_available_governors scaling_max_freq cpuinfo_min_freq scaling_cur_freq scaling_min_freq spitfire cpufreq # cat scaling_cur_freq 1000000 spitfire cpufreq # cat scaling_governor ondemand spitfire cpufreq # and yet the applet shows 2.17G Performance. If I restart the cpufreqd service with the init script or even cpufreqd and cpufrequtils the problem remains. It is only resolved with a reboot or by removing and readding the CPU1 applet. Expected results: Correct indication of the second core state. Does this happen every time? yes Other information: Gentoo thread here: http://forums.gentoo.org/viewtopic-t-510522-highlight-.html no responses so far.
I think this is a gnome-applets bug. Reassigning
Thanks a lot for the bug report, it provides very useful information. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 356694 ***