suspend/resume porblems with centrino duo

I have the same exact problem, so it is confirmed.

This is a kubuntu Edgy 6.10 install on a Toshiba A100-TA6.

It has T2250 Centrino Duo.

When the laptop is rebooted, both CPUs are running at 800MHz most of the time, and one or the other goes up to the full 1733MHz.

This happens upon resuming from suspend, or from hibernate. The fan also goes fast and I can feel air coming out of the vents.

It goes back to normal if I reboot the laptop.

See this:

$ grep MHz /proc/cpuinfo
cpu MHz : 800.000
cpu MHz : 1733.000

The puzzling part is that both CPUs are in the same ACPI state regardless:

$ diff /proc/acpi/processor/CPU?
diff /proc/acpi/processor/CPU0/info /proc/acpi/processor/CPU1/info
1,2c1,2
< processor id: 0
< acpi id: 0
---
> processor id: 1
> acpi id: 1
diff /proc/acpi/processor/CPU0/power /proc/acpi/processor/CPU1/power
6c6
< *C2: type[C2] promotion[--] demotion[C1] latency[001] usage[01822333] duration[00000000007367703269]
---
> *C2: type[C2] promotion[--] demotion[C1] latency[001] usage[01743842] duration[00000000007432976070]

Same problem here, using Dell Inspiron 9400 with Intel Centrino Core Duo T2250@1.73GHz, so it is confirmed.

Before suspend/resume, second core governor is ondemand, running at 800000 KHz.
After suspend/resume, second core governor is performance, running at 1733000 KHz.

A workaround was posted in the forums: http://www.ubuntuforums.org/showpost.php?p=1791164&postcount=21

Were you able to manually reduce the speed of the second cpu?

If so, how?

I could not use acpi (echo to /proc/...) to do that.

According to the forums post, you have to create a script in /etc/acpi/resume.d to restart powernowd (that sets your cpu power config to default, ondemand in both cores in my case). Further instructions in the link in my previous comment.
If you want to manually change your cpu speed you can use cpufreq-selector.

Here is a solution that worked for me.

Create the following script. in /etc/acpi/resume.d/75-dual-core-cpu-freq.sh

#!/bin/sh

SYS_DIR=/sys/devices/system/cpu
#POLICY=performance
###
# POLICY can be any of:
# userspace powersave ondemand conservative performance
#
POLICY=ondemand

for CPU in `ls $SYS_DIR`
do
  echo -n $POLICY > $SYS_DIR/$CPU/cpufreq/scaling_governor
done
#==========

Now the policy will be set correctly after a resume from hibernate or suspend state.

Nice fix, it should be faster than restarting the whole powernowd service, although i'm not sure if something else has to be fixed after resuming. Thanks.

I found another problem.

Even though the above fix takes care of the CPU speed, the fan keeps going at high speed after a resume (from suspend or hibernate).

Anyone got that solved?

Fans working as expected here (no high speed after resuming).

Khalid Baheyeldin's script works well here on my Dell Inspiron 9400 (Core 2 Duo T7200 2GHz). My fans continue to work as expected.

The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Note that we'll keep this report open against the actively developed kernel but this will be closed against 2.6.17. Thanks.

Hi,

On a clean install of Hardy Heron Alpha 5, upgraded to Alpha 6 with the newest kernel in the repository -- this problem still exists. After resume (from standby to RAM), the govenor is set to performance causing the cpu frequency to stay at the maximum.

This bug may be a duplicate of https://bugs.launchpad.net/ubuntu/+source/hal/+bug/124797

Not confirmed here on Hardy with latest updates. All cpufreq related stuff works normally.

A problem occours with iwl3945 not re-hooking to the wifi network; may I file a bug on this?

This bug (scaling_governor not restored on any CPU) can reproduced here on Hardy current with a Core 2 Duo Notebook (Deel XPS M1330).

Set priority.

@Gabriele: Yes, you should report a separate bug.

This bug has been resolved in pm-utils 0.99.2-3ubuntu5. If you continue to encounter it with versions after that, please re-open.

With Hardy Release Candidate and pm-utils 0.99.2-3ubuntu9 I am still experiencing this bug on a Core 2 Duo Dell Inspiron 1420N. After resuming from sleep or hibernate CPU0 is in "ondemand" mode as it should be, but CPU1 is stuck on "performance" mode.

Minor correction: CPU0 is in a functioning "ondemand" mode while CPU1 claims to be "ondemand" but is in fact locked at 100% CPU usage.

I can confirm running Hardy w/latest updates
dell xps m1330, intel core 2 duo

after resume from suspend, the second cpu core is locked at 100% while the first scales properly.

the issue doesn't appear to exist with resume from hibernate.

Still broken after latest updates.

Can confirm problem no longer occurs when resuming from hibernation.

is this bug cosmetic? I remember reading somewhere that someone from Intel was insisting that the two cores cannot be set independently of one-another. Can anyone confirm whether this is true?

They appeared to scale separately as of the last time I used Gutsy, including upon resuming from suspend.

I believe this is a duplicate (excuse if anachronistic) of bug 183033, and is still present in later versions of the kernel

If so, it is NOT simply cosmetic -- upon resume from suspend, cat /proc/cpuinfo | grep MHz indicates that one cpu is scaling while the other isn't. My power consumption jumps +3-4 watts/hr.

XPS m1330 w/8.04 running latest
2.6.24-16-generic kernel

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.