CPU 1 runs at 100% after suspend to disk

Bug #80212 reported by Martin on 2007-01-17
Affects Status Importance Assigned to Milestone
GNOME Applets
Fix Released
gnome-applets (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

I am running Ubuntu 6.10 on a Fujitsu-Siemens Lifebook C1410 (Dual Core) and after a suspend to disk, the application that shows CPU frequency shows 100% for Core 1. Running top I cannot find anything special running, so it might just be a bug in the application.

Martin (martin-wetterstedt) wrote :

The CPU (Core) to the right is showing 100% avtivity (or at least frequency scaling)

Brian Murray (brian-murray) wrote :

Thanks for your bug report. Could you please execute top after resuming from suspend to see if it something with the system monitoring applet? Thanks in advance.

Martin (martin-wetterstedt) wrote :

As I wrote in the bug description, there is no process running excessively.

Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description doesn't yet have enough information.
Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command 'uname -a' in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command 'dmesg > dmesg.log' and attach the resulting file 'dmesg.log' to this bug report.
3. Please run the command 'sudo lspci -vvnn > lspci-vvnn.log' and attach the resulting file 'lspci-vvnn.log' to this bug report.
For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks in advance!

emvy (mate-varga) wrote :

I add some information as you've requested (my problem is exactly the same, with the addition that suspend-to-ram has the same effect).

CPU: Yonah T2500 (Core Duo 2.0 GHz)

 uname -a:
Linux mv-t60 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux
(note: situation does not change when running 2.6.20-15)

emvy (mate-varga) wrote :


emvy (mate-varga) wrote :

I have to mention that the scaling-governor is "ondemand" for both cpu-s (as CPU1's cpufreq dir is a symlink to CPU0's cpufreq dir).

Restarting powernowd or unloading/reloading it before/after suspend does not help.

Antti P Miettinen (apm) wrote :

I noticed something similar but for me it is just the CPU frequency applet in the gnome panel that gets somehow stuck. If I e.g. kill and reload the applets, they then correctly reflects what is in /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq.

emvy (mate-varga) wrote :

It's the same at me. It seems that there is no problem with CPU scaling, just the gnome panel applet gets stuck. I think this entry should be moved.

Jean Jordaan (jean-jordaan) wrote :

Confirmed here too -- applet doesn't correctly reflect CPU frequency.

Changed in linux-source-2.6.20:
assignee: brian-murray → ubuntu-kernel-acpi
importance: Undecided → Medium
status: Needs Info → Confirmed
Gintautas Miliauskas (gintas) wrote :

Confirmed here too -- it's only the applet that gets stuck. The problem occurs both after suspend-to-RAM and suspend-to-disk.

CPU: Intel Core 2 T5500
gnome-applets: 2.18.0-0ubuntu1
kernel: 2.6.20-16-generic

Changed in linux-source-2.6.20:
assignee: ubuntu-kernel-acpi → nobody
laksdjfaasdf (laksdjfaasdf) wrote :

Can confirm this bug - seems that applet is the problem.
cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
running a few times on console always gives me lowest frequency the CPU can run with.

uname -a:
Linux thinkubuntuz29 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

cat /proc/version_signature:
Ubuntu 2.6.20-16.29-generic

laksdjfaasdf (laksdjfaasdf) wrote :
Sebastien Bacher (seb128) wrote :
Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Medium → Low
status: Confirmed → Triaged
Changed in gnome-applets:
status: Unknown → Fix Released
Pedro Villavicencio (pedro) wrote :

Is somebody experiencing the same issue with a Hardy Heron installation?

Changed in gnome-applets:
status: Triaged → Incomplete
Sebastien Bacher (seb128) wrote :

no recent comment about a similar issue nor duplicate and the upstream bug has been closed, closing this task, feel free to reopen if you still have the bug on hardy though

Changed in gnome-applets:
status: Incomplete → Fix Released
Changed in gnome-applets:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.