Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1

Bug #183033 reported by enigma_0Z
72
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
Ubuntu
Invalid
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
Intrepid
Invalid
Undecided
Unassigned
linux (Ubuntu)
Fix Released
Low
Tim Gardner
Hardy
Fix Released
Low
Tim Gardner
Intrepid
Fix Released
Low
Tim Gardner
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned
Hardy
Won't Fix
Undecided
Unassigned
Intrepid
Won't Fix
Undecided
Unassigned

Bug Description

My system:

Dell Vostro 1400
Intel Core 2 Duo @ 2.0 GHz
3 GB Ram
1 GB Swap

I recently got suspend & hibernate working on my system by modifying the hal scripts to use acpi-support sleep.sh and hibernate.sh instead of powersaved. Now, however, I have found a bug regarding the suspend and resume scripts:

When I resume from a suspend (suspend to ram, in particular), /proc/cpuinfo reports that CPU1 is running @ 1994 MHz. Further investigation reveals that /sys/devices/system/cpu/cpu1/cpufreq is gone entirely (It normally is a symlink to cpu0's cpufreq directory).

If there's any extra info I can provide, I am more than willing to.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Dmesg log--did a dmesg -c, here's the dmesg output after a suspend & resume

Revision history for this message
Matt@Notts (daelyn) wrote :

Maybe this is a silly question, but, I can see no reference what so ever that it recognizes Core0 (CPU0) in that dmesg, which makes me "wonder." It recognizes the CPU ID correctly though, as far as I know.

Gotta test on mine at home and see if there is a similiar output.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

--snip--
[ 4758.160000] Disabling non-boot CPUs ...
[ 4758.276000] CPU 1 is now offline
[ 4758.276000] SMP alternatives: switching to UP code
[ 4758.276000] CPU1 is down
[ 4758.276000] PM: Entering mem sleep
[ 4758.276000] Back to C!
[ 4758.276000] PM: Finishing wakeup.
[ 4758.276000] Enabling non-boot CPUs ...
[ 4758.288000] SMP alternatives: switching to SMP code
[ 4758.288000] Booting processor 1/1 eip 3000
[ 4758.296000] Initializing CPU#1
[ 4758.376000] Calibrating delay using timer specific routine.. 3989.92 BogoMIPS (lpj=7979850)
[ 4758.376000] CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd 00000000 00000001
[ 4758.376000] monitor/mwait feature present.
[ 4758.376000] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 4758.376000] CPU: L2 cache: 4096K
[ 4758.376000] CPU: Processor Core ID: 1
[ 4758.376000] CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd 00000000 00000001
[ 4758.376000] CPU1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz stepping 0a
[ 4758.376000] ACPI Error (psloop-0136): Found unknown opcode 17 at AML address f88563c3 offset 0, ignoring [20070126]
[ 4758.376000] ACPI Error (psargs-0355): [DBþÿ] Namespace lookup failure, AE_NOT_FOUND
[ 4758.376000] ACPI Error (psparse-0551): Method parse/execution failed [\_PR_.CPU1._PCT] (Node df8323c0), AE_NOT_FOUND
[ 4758.376000] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]
[ 4758.376000] CPU1 is up
[ 4758.380000] Switched to high resolution mode on CPU 1
--snip--

It says that it's disabling CPU1 (a non-boot CPU) so... AFAIK on Intel systems CPU1 is hot (un)plugged on suspend, so when the system resumes, I imagine that CPU0 would in fact be absent from dmesg because there's nothing necessary to do for CPU0. But I'm no ACPI expert.

What makes me wonder is the ACPI errors in the last few lines of the above snip.

Also, when the system resumes, top reports that both processors are receiving load independently, so it's not like it's not working...

Revision history for this message
David Tomaschik (matir) wrote :

This looks like a duplicate of bug #124797, but I'm not certain. I seem to be having the same behavior as well (CPU pegged on resume).

Revision history for this message
David Tomaschik (matir) wrote :

After more research, I'm fairly certain this is a duplicate of bug #68191, which has far more detail.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I'm not too sure that it is a duplicate, but it may be related. #68191, the /sys/devices/system/cpu/cpu1/cpufreq/scaling_govenor reports "performance" or "userspace" whereas on my system two things are different:

1. /sys/devices/system/cpu/cpu1/cpufreq is a symlink to ../../../../devices/system/cpu/cpu0/cpufreq
2. That symlink is gone on resume, rather than being different that what it should be.

Possibly also related: my two cores do not scale independently--If one goes up they both go up. Possibly related to said symlink. Is this normal behavior?

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1

enigma_0Z wrote:
> I'm not too sure that it is a duplicate, but it may be related. #68191,
> the /sys/devices/system/cpu/cpu1/cpufreq/scaling_govenor reports
> "performance" or "userspace" whereas on my system two things are
> different:
>
> 1. /sys/devices/system/cpu/cpu1/cpufreq is a symlink to ../../../../devices/system/cpu/cpu0/cpufreq
> 2. That symlink is gone on resume, rather than being different that what it should be.
>
> Possibly also related: my two cores do not scale independently--If one
> goes up they both go up. Possibly related to said symlink. Is this
> normal behavior?

Of course, if your monitoring tool uses /sys/devices/system/cpu/... to
get the info, and cpu1/cpufreq is a symlink to cpu0/cpufreq, then
naturally it's going to display the same values for both cores.

On my system (Core 2 Duo as well) the two cores scale independently. Are
you sure you have a Core 2 Duo and not a Core Duo? IIRC the Core Duo
cores do not scale independently.

Cheers,
Bart

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Hmm.... lshw reports:

Intel(R) Core(TM)2 Duo CPU

Can you tell me if /sys/devices/system/cpu/cpu1/cpufreq is an independent file or a symlink on your system? As far as monitoring tools for the CPU Frequencies, /proc/cpuinfo is what I use, is there something better?

My system is a Centrino laptop, but (as above) it has a Core 2 Duo CPU in it. Maybe something is set up wrong on my system? Is there some relevant config files for the CPU Frequencies? And what controls what goes into /sys/devices/system/cpu/*?

Revision history for this message
Bart Samwel (bart-samwel) wrote :

enigma_0Z wrote:
> Hmm.... lshw reports:
>
> Intel(R) Core(TM)2 Duo CPU
>
> Can you tell me if /sys/devices/system/cpu/cpu1/cpufreq is an
> independent file or a symlink on your system? As far as monitoring tools
> for the CPU Frequencies, /proc/cpuinfo is what I use, is there something
> better?

Hmmm, I don't think you have many other options. In fact, I just tried
it, and on my system it's a symlink as well. However, I know for sure
that they *did* work independently earlier, because at some point in the
7.04-7.10 area the second core got stuck at 2GHz after resuming from
suspend. For the record:

# uname -a
Linux bakbeest 2.6.24-3-generic #1 SMP Thu Jan 3 22:50:33 UTC 2008
x86_64 GNU/Linux

> My system is a Centrino laptop, but (as above) it has a Core 2 Duo CPU
> in it. Maybe something is set up wrong on my system? Is there some
> relevant config files for the CPU Frequencies? And what controls what
> goes into /sys/devices/system/cpu/*?

AFAIK it's the kernel, and nothing but the kernel. So this must be a
kernel problem.

Revision history for this message
David Tomaschik (matir) wrote :

Because of the differences in the behavior of /sys/devices/system/cpu/cpu?/cpufreq, I've removed the duplicate status on this bug.

According to the Intel documentation, Speedstep and Sleep states are independently controllable per-core. To me that means they should NOT be symlinked together, but should be controlled independently.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Maybe it's already fixed in Hardy...

Has anyone tried the hardy kernel? (Or is it too unstable for real use?)

Revision history for this message
David Tomaschik (matir) wrote :

I'm using Hardy.

cpu1/cpufreq is a symlink to cpu0/cpufreq. After resume, the CPU is switched to "performance" cpufreq governor (and thus pegged at MAX CPU speed).

Revision history for this message
Chris Irwin (chrisirwin) wrote :

Same issue here, and I can indeed confirm that with Gutsy kernel the cores scaled separately (Easily noticed by building some large source tree and see the cores alternating the load)

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I'm using gutsy now, and the cores aren't independent. Do you mean Edgy?

Revision history for this message
Chris Irwin (chrisirwin) wrote :

No, scaling was per-core on Gutsy. I have two core 2 duo machines here, one on Gutsy and one on Hardy. Both machines when running Gutsy act the same regarding CPU scaling. I used the output from two machines to avoid swapping hard disks and rebooting.

On Gutsy each CPU had it's own cpufreq directory:
# ls -l /sys/devices/system/cpu/cpu* | grep cpufreq
drwxr-xr-x 4 root root 0 2008-02-05 16:48 cpufreq
drwxr-xr-x 4 root root 0 2008-02-05 16:48 cpufreq

On Hardy, the second CPU shares the first (I would assume the same would be true in a quad-core system)
# ls -l /sys/devices/system/cpu/cpu* | grep cpufreq
drwxr-xr-x 3 root root 0 Feb 5 15:24 cpufreq
lrwxrwxrwx 1 root root 0 Feb 5 16:39 cpufreq -> ../../../../devices/system/cpu/cpu0/cpufreq

To test scaling, I ran the command `cat /dev/urandom > /dev/null`. While this was going, I checked CPU speed

On Gutsy, cores scale separately:
# cat /proc/cpuinfo | grep MHz
cpu MHz : 1596.000
cpu MHz : 2394.000

On Hardy they scale together:
# cat /proc/cpuinfo | grep MHz
cpu MHz : 2200.000
cpu MHz : 2200.000

On Gutsy you can also set a different scaling governor on a per-cpu basis (one performance, the other powersave) and it would act accordingly.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

That's really funny. On my system they're not independent to begin with...

Did you make some configuration changes to make that independent?

What packages (powernow, powersave, acpi-support, etc) do you have installed? I may have something wrong in my setup.

Revision history for this message
Chris Irwin (chrisirwin) wrote :

Nothing special, and only what is installed by default for scaling..

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Hmm, maybe you're just lucky. Does anyone know what stuff Ubuntu installs by default for scaling? It seems that powersaved doesn't really like me as suspend only works with the acpi-support scripts...

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

To me, this bug looks very much like a duplicate of bug #124797 but I'll leave it to someone else to mark it as such.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :
Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

The attached dmesg is from booting normally, working for a while, then suspending and resuming. The suspend begins at timestamp 5712. In particular, the line

[ 0.574649] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c3efb60), AE_NOT_FOUND

looks interesting. Could that affect cpufreq scaling?

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I'm no kernel hacker, but that does look very interesting... in fact, the lines before and after look related as well:

[ 0.574636] ACPI Error (psloop-0136): Found unknown opcode 17 at AML address ffffc200008b27c3 offset 0, ignoring [20070126]
[ 0.574645] ACPI Error (psargs-0355): [DBþÿ] Namespace lookup failure, AE_NOT_FOUND
[ 0.574649] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c3efb60), AE_NOT_FOUND
[ 0.574685] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]
[ 0.574690] CPU1 is up

It seems that there's an issue with acpi just before CPU1 is brought up...

But considering the topic of that bug is the scaling monitor, not the actual scaling, I really didn't consider this a dupe, but the circumstances seem to be the same. I'll post this over there too.

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

Same problem as in description happens to me, with the following system:

Ubuntu 7.10
Kernel: Linux moria 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
Dell Latitude D630 Laptop
Processor: Intel Core 2 Duo T7300 (2x 2 GHz)

Before suspend, frequency scaling is working normally.
After suspend, frequency governor is only settable for CPU0 and this CPU is scaling normally. CPU1 stays at 800 MHz.
Attached are outputs of cpufreq-info before suspending and after one suspend.
Also the output of 'sudo dmesg -c' from boot to directly after suspend. Suspend happens at 435.

NB: In the early Gutsy final version, CPU1 got stuck at 2 GHz *most of the time* after a suspend (not every time). From some point on the behaviour apparently changed and CPU1 gets now *always* stuck at 800 MHz.

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :
Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

To clarify, I'm talking about Suspend-to-RAM.

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

Tested with LiveCD of new Hardy Alpha 5:

CPU1 now stays at 2 GHz after resume from suspend. (Same behaviour as with older Gutsy Kernels)

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

For a dmesg log from booting, directly suspending and resuming, please see http://launchpadlibrarian.net/12235140/dmesg . This is on a Dell Inspiron 1420 running 2.6.24-10-generic.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Try this:

--code--

modprobe -r acpi_cpufreq
modprobe acpi_cpufreq

--/code--

This restored the symlink to CPU0's cpufreq dir for me. I've modified the acpi-scripts directory in etc (/etc/acpi/resume, specifically) to do this now, and everything's fine. I've added those lines to /etc/acpi/resume.d/72-acpi-pain.sh at the end.

But, for some reason the HAL scripts (/usr/lib/hal/scripts/linux) in Ubuntu prefer to use powersaved to sleep & hibernate instead of the ACPI scripts. I modified the two appropriate scripts (hal-system-power-hibernate-linux and hal-system-power-suspend-linux) to prefer to use the scripts in /etc/acpi. I'm not entirely sure why Ubuntu has to have both powersaved and acpi-support to begin with, but whatever.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

For completeness, output from "sudo lspci -vvnn" : http://launchpadlibrarian.net/12033791/lspci

As for unloading acpi-cpufreq, that doesn't work for me since it's marked "in use" by the kernel.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Hmm. Try adding it to /etc/acpi/resume.d/72-acpi-pain.sh, and running /etc/acpi/sleep.sh. It shouldn't be in use when the system is waking up.

Revision history for this message
LEVIS Cyril (atlas95) wrote :

Same problem on my xps m1330, cpufreq problem after resume.

Revision history for this message
Mario Limonciello (superm1) wrote :

This may have been fixed after the recent update to pm-utils.
Can someone encountering it verfify?

pm-utils (0.99.2-3ubuntu5) hardy; urgency=low

  * Fix typo in 95-fix-config-file-parsing.patch which made loading
    configs from /etc/pm/config.d/* break. LP: #190679
  * Add 35-skip-linked-cpus-cpufreq.patch which skips all CPUs whose speed
    is shared with other CPUs (or cores) when saving state. LP: #162652.

 -- Tollef Fog Heen < <email address hidden>> Wed, 26 Mar 2008 09:00:25 +0100

Revision history for this message
zakimak (zakimak) wrote :

Arf, no changes after this upgrade ...

Revision history for this message
Jose De la Rosa (jose-de-la-rosa) wrote :

On the XPS M1330 with pm-utils (0.99.2-3ubuntu5) hardy, issue appears to be fixed. After several suspend and hibernate cycles, both CPU cores scale properly. The scaling governor on both cores is set to ondemand.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

Jose, what method do you use for suspending/hibernating?

Revision history for this message
Mario Limonciello (superm1) wrote :

I can confirm that the latest pm-utils solves the problem reported. I tested on both a Dell Inspiron 1525 and XPSM1330. I issued a suspend by choosing "Suspend" from the gnome logout button.

Changed in dell:
status: New → Fix Released
Changed in linux:
status: New → Fix Released
Revision history for this message
zakimak (zakimak) wrote :

I have a XPS M1330 on Hardy with the latest updates including pm-utils 0.99.2-3ubuntu5, and i still have the same problem :

[ 0.579517] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f88507ca offset 7, ignoring [20070126]
[ 0.579522] ACPI Error (psloop-0136): Found unknown opcode 16 at AML address f88507cc offset 9, ignoring [20070126]
[ 0.579527] ACPI Error (psloop-0136): Found unknown opcode 19 at AML address f88507d0 offset D, ignoring [20070126]
[ 0.579534] ACPI Error (psargs-0355): [C\Uffffffff\Uffffffff^I] Namespace lookup failure, AE_NOT_FOUND
[ 0.579538] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f7c4f420), AE_NOT_FOUND
[ 0.579574] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]

i don't understand :(

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

I have a Dell Latitude D630, Intel Core 2 Duo T7300.

I still have the problem.

I used the Hardy beta LiveCD, updated pm-utils to 0.99.2-3ubuntu6 (newest version), and then tried suspend directly from the LiveCD.
After suspend Core 1 was stuck at 2 GHz. (max), and scaling was only working on Core 0.

Suspend was initiated from the gnome logout menu.

Is it possible that I have to suspend by another method, or that I have to do something after updating pm-utils, to get it working?

Furthermore, in up-to-date Gutsy the second core now also *again* gets stuck at 2 GHz, since a few weeks or so. Before that, it would get stuck at 800 MHz.

Did something related to suspend or cpu scaling get updated in Gutsy in the near past? Or what could have triggered this differing behaviour? Maybe that could lead to the source of the bug.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I managed a somewhat hackish fix by unloading and re-loading acpi-cpufreq when the computer is resuming (added this to /etc/acpi.d/resume.d/72-acpi-pain.sh ...

I'm actually upgrading to hardy right now (I suppose it has to be pretty stable, only approx. 30 days until it's released), so I'll see what this does on my lappy

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend, CPUFrequency Scaling is gone on CPU1

Please test from a daily CD including this fix if you are going to only
test on a LiveCD. There are other related packages that need to be
updated too (and some of them require a reboot to update).
n Thu, 2008-03-27 at 20:24 +0000, Janne Hyötylä wrote:

> I have a Dell Latitude D630, Intel Core 2 Duo T7300.
>
> I still have the problem.
>
> I used the Hardy beta LiveCD, updated pm-utils to 0.99.2-3ubuntu6 (newest version), and then tried suspend directly from the LiveCD.
> After suspend Core 1 was stuck at 2 GHz. (max), and scaling was only working on Core 0.
>
> Suspend was initiated from the gnome logout menu.
>
> Is it possible that I have to suspend by another method, or that I have
> to do something after updating pm-utils, to get it working?
>
>
> Furthermore, in up-to-date Gutsy the second core now also *again* gets stuck at 2 GHz, since a few weeks or so. Before that, it would get stuck at 800 MHz.
>
> Did something related to suspend or cpu scaling get updated in Gutsy in
> the near past? Or what could have triggered this differing behaviour?
> Maybe that could lead to the source of the bug.
>

---
Mario Limonciello
Dell | Linux Engineering
Desk : (512) 723-0582
<email address hidden>

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

On my fully up-to-date Inspiron 1420 running Hardy, this bug is NOT fixed. After resume from suspend-to-ram:

$ ls /sys/devices/system/cpu/cpu1/
cache cpuidle crash_notes online thermal_throttle topology

Note the absence of the cpufreq directory. Also, I still get the same errors in dmesg when resuming:

 [ 0.575047] ACPI Error (psloop-0136): Found unknown opcode 17 at AML address ffffc200008d87c3 offset 0, ignoring [20070126]
[ 0.575055] ACPI Error (psargs-0355): [DB<FE><FF>] Namespace lookup failure, AE_NOT_FOUND
[ 0.575059] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c3b1720), AE_NOT_FOUND
[ 0.575095] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]
[ 0.575100] CPU1 is up

Changed in linux:
status: Fix Released → Confirmed
Changed in dell:
status: Fix Released → Confirmed
Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

Jose and Mario, what bios versions do you have? I believe this could make a difference. I'm running version a06 on my Inspiron 1420. I'm waiting for the Dell bios repository to include version a07 so I can see if this upgrade helps.

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

Mario:
Also not fixed here on Daily LiveCD (2008-03-27).

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

Reflashing my bios to the latest available (A07) did not help either.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

I found a workaround: recompiling the kernel with CONFIG_MODULE_FORCE_UNLOAD=y allows forced unloading with "rmmod -f acpi_cpufreq" and then you can modprobe the module again on resume.

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Still not fixed.

uname -r:
2.6.24-15-generic

Incl. linux-backport-modules

Revision history for this message
Pavel Malyshev (afunix) wrote :

Dell Inspirion 1520, updated Hardy
Issue not fixed.
[ 0.595106] ACPI Error (psloop-0136): Found unknown opcode 17 at AML address f884a3c3 offset 0, ignoring [20070126]
[ 0.595114] ACPI Error (psargs-0355): [DB<FE><FF>] Namespace lookup failure, AE_NOT_FOUND
[ 0.595119] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f7c243c0), AE_NOT_FOUND
[ 0.595156] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]

Additionally, after resuming from suspend-to-ram, my hard disk starts clicking (starting-stopping?). I know about this old bug and I have this /etc/acpi/suspend.d/99-hdd-spin-fix.sh

Revision history for this message
Mario Limonciello (superm1) wrote :

I confirmed that this has returned on the XPS 1530.

Changed in linux-source-2.6.22:
status: Confirmed → Won't Fix
Revision history for this message
Mario Limonciello (superm1) wrote :

Particularly, it's the symlink in /sys/devices/system/cpu/cpu1/cpurfreq that is normally pointing to ../../../../devices/system/cpu/cpu0/cpufreq that dissappears.

Revision history for this message
Mario Limonciello (superm1) wrote :
Revision history for this message
Tim Gardner (timg-tpi) wrote :

While annoying, this bug is cosmetic. Intel assures us that Core 2 Duo CPUs cannot operate at different frequencies.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Low
milestone: none → ubuntu-8.04.1
Revision history for this message
enigma_0Z (enigma-0za) wrote :

Then what happens with the second CPU? Is the second CPU turned off, or does it simply follow the first CPU as it does normally?

Can someone do some power consumption and performance testing? Or is that even necessary?

Revision history for this message
Geoff Jacobsen (geoffj) wrote :

I ran powertop with my machine not yet suspended power was about 17W after suspending and resuming power usage went up to 18 - 21 Watts

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I was just going to comment on this...

If this bug is only cosmetic, is this a related cosmetic issue as well? On my system, it seems that it idles at approx 14.2 watts before suspend, and at 15~17 watts after... but the jump when the system is active... it jumps to more than 30 watts, which AFAIK is rediculous for my system--only when playing a 3D game does my power even approach that level.

Revision history for this message
sjn (steve-snewbury) wrote :

As I understand it, each core is logically scaled seperately but the hardware itself is set to the minimum frequency needed to meet the maximum frequency of both cores. This means that if frequency scaling is not enabled for one of the cores the minimum frequency is pegged at the frequency of the non-cpufreq core. The other core will appear to scale, but in fact never does. This is NOT merely cosmetic! :-(

Revision history for this message
Tobias Heinemann (theine) wrote :

Tim, are you very sure about that? I could swear that the fan in my laptop is doing much more work after resume -- which fits with my naive interpretation of

$ cat /proc/cpuinfo | grep MHz
cpu MHz : 800.000
cpu MHz : 1994.556

Revision history for this message
sjn (steve-snewbury) wrote :

Tobias, as I tried to explain, core0 will be running at 1994.556 MHz, not 800 Mhz as you'd expect. The CPU will only get clocked down to 800 MHz if both cores are (logically) clocked to 800 MHz. That isn't going to happen with cpufreq not working for the second core! Tim is technically correct in that the cores do not run at different frequencies (physically), but his conclusion is wrong. This is a serious bug, cpufreq really isn't working at all (despite appearences), not a cosmetic one!

Revision history for this message
zimous (zimous) wrote :

Hi all,
I had the same problem on Dell Vostro 1500, Core 2 Duo. After resume, CPU1 was stuck on 1994 MHz and there were analogous ACPI error messages in log. I tried newest BIOS, switching CPU1 off --- without success, but finally I found a workaround at:

http://gnugeneration.epfl.ch/users/fasnacht/d630_cpufreq

Briefly, the problem is probably in the acpi-cpufreq module. If you remove it before suspend (by force: rmmod -f) and insert back after resume, frequency scaling works ok for both cores. Of course, acpi-cpufreq has to be compiled as a module (which is likely with distribution kernel) and you should stop your cpufreq/power daemon first. I know nothing about *buntu (using gentoo), but this can help you too.

Btw. 1994 is the default frequency, which my C2D starts at without any cpufreq support.

Revision history for this message
ethanay (ethan-y-us) wrote :

confirming on dell xps m1330 8.04 w/latest

adding
modprobe -r acpi_cpufreq
modprobe acpi_cpufreq

to the 72-pain script seems to fix the issue

Revision history for this message
Tobias Heinemann (theine) wrote :

Not confirming on Dell Latitude D830 using 8.04.

Adding

modprobe -r acpi_cpufreq
modprobe acpi_cpufreq

to /etc/acpi/resume.d/72-acpi-pain.sh still leaves me with

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

after resuming from suspend to ram.

Revision history for this message
gerb (gerbsen) wrote :

same problem here on a dell xps m1330 with ubuntu hardy

Revision history for this message
gerb (gerbsen) wrote :

everything work fine with ubuntu 7.10

under 8.04 i can't unload modules:

 sudo modprobe -r acpi-cpufreq (28-04-08 17:48)
 FATAL: Module acpi_cpufreq is in use.

Revision history for this message
Anatoly Yushkov (yaa13) wrote :

because
$ cat /boot/config-2.6.24-16-generic | grep MODULE_FORCE_UNLOAD
# CONFIG_MODULE_FORCE_UNLOAD is not set
$
Dell XPS M1330 with Ubuntu Hardy
Rebuild kernel?
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/183033/comments/45

Revision history for this message
Tobias Heinemann (theine) wrote :

It seems to me as if /etc/acpi/resume.d/72-acpi-pain.sh isn't even read anymore upon resume. At least have a statement like

touch /root/acpi-pain

in there doesn't yield a file called /root/acpi-pain on this machine.

However, editing /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux and inserting

rmmod -f acpi_cpufreq
modprobe acpi_cpufreq

immediately before the last statement

exit $RET

works for me. Obviously,

$ grep FORCE_UNLOAD /boot/config-$(uname -r)
CONFIG_MODULE_FORCE_UNLOAD=y

is required for this.

Revision history for this message
achtung (achtun) wrote :

Hi there,

same problem for me! Really annoying bug. Over time my Dell D630 heats up because of this bug. I don't give any logs because they lock exactly like mentioned.
You would love to use the solution mentioned above by @Tobias Heinemann but I'm unable to compile a kernel myself.

I did compile linux kernels years ago but ubuntu drives me nuts. I try to build a vanilla kernel with one extra option CONFIG_MODULE_FORCE_UNLOAD but then when I try to use me newly created kernel/modules the system won't oven go to sleep mode any more. I mean that is a solution too but mhhh. An also the hole folder in /lib/modules/`uname -r`/ubuntu is missing. So no sound *snd_hda_intel) no dvb no nothing. And there is absolutly no information available how to get these modules in your own compilation.

Now I rember why I used Red Hat Distributions for years.... argghh ;-)

Hopefully, someone is able to help me a little. Or just compile a working kernel/modules. I mean "dual core" support really shouldn't be that hard nowadays ...

Thanks,
Mark

P.S. Not a native speaker and a little angry....

Revision history for this message
Zaar Hai (haizaar) wrote :

The problem still exists for me in Ubuntu Hardy. After suspend/resume:
$ grep MHz /proc/cpuinfo
cpu MHz : 800.000
cpu MHz : 1994.491

sudo modprobe -r acpi-cpufreq
 FATAL: Module acpi_cpufreq is in use.

grep FORCE_UNLOAD /boot/config-$(uname -r)
# CONFIG_MODULE_FORCE_UNLOAD is not set

Revision history for this message
Mario Kemper (Romario) (mario-kemper) wrote :

Same problem here. Using hardy.

Dell XPS M1330.
The issue is really annoying and not only cosmetic because of the reduced battery time on my machine.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

I agree. This is extremely annoying. The importance on this bug should moved up a notch from "low".

Could we at least have a kernel update with CONFIG_MODULE_FORCE_UNLOAD enabled, please?

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

By the way, is there any upstream bug report for this?

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Sorry to be spamming this bug report. I thought I'd share this (while we're waiting for a real solution):
http://www.naderehvandi.net/backup/linux-image-2.6.24-17-generic_2.6.24-17.31ubuntu1_amd64.deb
http://www.naderehvandi.net/backup/linux-image-2.6.24-17-generic_2.6.24-17.31ubuntu1_i386.deb

These packages are simple recompiles of the .deb source packages from the hardy-proposed repo. The only change made to them is that I've enabled CONFIG_MODULE_FORCE_UNLOAD.

With this, I am also able to force unload the acpi-cpufreq module and then re-inserting it, causing the cpufreq link of the second core to re-appear.

Revision history for this message
Mario Kemper (Romario) (mario-kemper) wrote :

@Khashayar:
Sorry, but after installing your kernel there is no sound and no wlan activity anymore on may machine.

I cant believe the priority is "low". How many percent of the linux users use a core2duo and use the suspend mode? Only the people taking part on this bugreport?
I think most of them using a core2duo aren't recognizing the bug and are not satisfied with ubuntu because of the less battery time compared to windows...

just because of a small bug!

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

@Romario: Strange, the only setting I've changed compared to the official ubuntu kernel is CONFIG_MODULE_FORCE_UNLOAD. I wish they could just do that themselves. My packages work for me at least...

Now, can someone change the priority of this bug to high? Pretty please?

Revision history for this message
achtung (achtun) wrote :

The above kernel dosn't work for you because all the modifications/modules done by ubuntu aren't included. It took a me a day to rebuild a kernel that works because nobody documents how to do so.
I won't post my kernel because I don't think thats a solution to the problem. But if you want to try to build one for yourselve take these steps:

1. https://help.ubuntu.com/community/Kernel/Compile (use the git method)
2. https://wiki.ubuntu.com/KernelGitGuide
3. http://kernel.ubuntu.com/git
 3.1 ubuntu/ubuntu-hardy-lum.git (all the ubuntu modifications)
 3.2 ubuntu/ubuntu-hardy.git

Revision history for this message
zakimak (zakimak) wrote :

@Romaria -> http://ubuntuforums.org/showthread.php?t=441013 an how-to which explain how to use restricted modules with a custom kernel.

Otherwise, you can download my version http://tomoueb.com/~tom/ubuntu-kernel-module-force-unload/linux-image-2.6.24-16-generic_2.6.24-16.30_i386.deb which has the same version name than the current version, then there is no link problem with restricted modules.

It works fine for me.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Oh yeah, sorry about that. My packages have the same version number as well so you won't need to recompile the extra modules. However, my package is based on the kernel in the -proposed repo, so you need to enable that repo in synaptic or /etc/apt/sources.list.

Well, now there's one package for -proposed users and one for others.

Regards.

Revision history for this message
Mario Kemper (Romario) (mario-kemper) wrote :

Thank you all for your help, folks. I took Khashayars recompiled kernel now and activated the proposed repository.
Everything is working like a charm now ;-)

Next time I'll spend some time on recompiling it myself, just for fun and interest.

Revision history for this message
mabawsa (mabawsa) wrote :

I tried Khashayar's kernel but the usb hid core is now saying
kernel: [ 409.593065] /home/khashayar/Projekt/builds/kernel/linux-2.6.24/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver

Will this cause any problems? If so how can I remedy it?

Revision history for this message
ethanay (ethan-y-us) wrote :

XPS m1330
8.04 w/latest

The ugly fix does not work as modprobe -r acpi_cpufreq is not allowed:
FATAL: Module acpi_cpufreq is in use.

The bug is not cosmetic as my power usage jumps 3-4 watts (from 13 watts to 16-17watts) after resume from suspend.

Resume from hibernate does not reproduce the issue.

Revision history for this message
zakimak (zakimak) wrote :

@Ethanay : try "rmmod -f acpi_cpufreq"

Revision history for this message
ethanay (ethan-y-us) wrote :

thanks for the suggestion.

input: ~$ sudo rmmod -f acpi_cpufreq
output: ERROR: Removing 'acpi_cpufreq': Resource temporarily unavailable

Revision history for this message
ethanay (ethan-y-us) wrote :

As long as this issue exists and no ugly fix works, suspend is unusable and pointless, as using it is self-defeating with the extra heat and power consumption upon resume.

Revision history for this message
achtung (achtun) wrote : Re: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1

On Mon, May 19, 2008 at 10:21 PM, ethanay <email address hidden> wrote:
> As long as this issue exists and no ugly fix works, suspend is unusable
> and pointless, as using it is self-defeating with the extra heat and
> power consumption upon resume.

I totally agree. Btw the new Fedora release has the same problem. It's
a major bug.

> --
> Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1
> https://bugs.launchpad.net/bugs/183033
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Dennis Noordsij (dennis-noordsij) wrote :

I reported it upstream: http://bugzilla.kernel.org/show_bug.cgi?id=10734

The issue also persists in the latest mainstream kernel. A fix should be easy to backport.

Let's see what happens :-)

Revision history for this message
Mario Limonciello (superm1) wrote : RE: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend,CPU Frequency Scaling is gone on CPU1
  • unnamed Edit (3.4 KiB, application/ms-tnef; name="winmail.dat")

Do you have the bug number in Fedora? We can link the two bugs here to track when it gets solved at one or the other.

-----Original Message-----
From: <email address hidden> on behalf of achtung
Sent: Mon 5/19/2008 3:45 PM
To: <email address hidden>
Subject: Re: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend,CPU Frequency Scaling is gone on CPU1

On Mon, May 19, 2008 at 10:21 PM, ethanay <email address hidden> wrote:
> As long as this issue exists and no ugly fix works, suspend is unusable
> and pointless, as using it is self-defeating with the extra heat and
> power consumption upon resume.

I totally agree. Btw the new Fedora release has the same problem. It's
a major bug.

> --
> Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1
> https://bugs.launchpad.net/bugs/183033
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1
https://bugs.launchpad.net/bugs/183033
You received this bug notification because you are a member of The Dell
Team, which is subscribed to Dell Ubuntu Project.

Revision history for this message
Aurimas Fišeras (aurimas-gmail) wrote :

After each resume I manually run this to workaround the problem:
sudo cpufreq-set -g ondemand

Revision history for this message
achtung (achtun) wrote : Re: [Bug 183033] Re: Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1

On Mon, May 19, 2008 at 10:55 PM, Mario Limonciello <email address hidden> wrote:
> Do you have the bug number in Fedora? We can link the two bugs here to
> track when it gets solved at one or the other.

No, I'm sorry I didn't post a extra bug report for fedora. I just
tried the new fedora release and after a suspend/resume cycle the
same problem occurred. So I think the kernel developer bug report, as
mentioned above, should be enough!

Revision history for this message
David Johnston (johnsto) wrote :

E_rulez: unfortunately that 'workaround' doesn't do anything for me and a lot of other people with this issue.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :
Revision history for this message
Aurimas Fišeras (aurimas-gmail) wrote :

David Johnston: My bad.

Investigated more and my problem is a little different: just scaling_governor is set to 'performance' on both cores after resume.

Changed in linux:
status: Unknown → Incomplete
Revision history for this message
fondle-em (mcribbb) wrote :

Dell inspiron 1420n. On waking from suspend, core 1 is locked at 100% while core 0 scales properly... or at least appears to. The increase in power use and heat, and the decrease in battery life, hardly seem "low priority" to me.

Revision history for this message
Dennis Noordsij (dennis-noordsij) wrote :

There is a patch available for the original problem (which is solved on the D630)

http://bugzilla.kernel.org/attachment.cgi?id=16280&action=view

It would be great if others could test if this works for them.

Note that the original problem is ACPI errors are resume, and complaining about a missing _PCT method.

Anyone willing to rebuild the hardy kernel with this patch to make it easier for others to test? :-)

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I would be more than willing to patch a hardy kernel and test... if someone could point me to some instructions.

(BTW: What kernel version is the patch against?)

Revision history for this message
Dennis Noordsij (dennis-noordsij) wrote :

Patch is against latest acpi tree, I have attached a patch which should work against 2.4.24 (which Hardy uses).

Note that it's not that straightforward to rebuild everything so that your restricted modules etc still work, that's why I hope someone subscribed to this bug knows how :-)

Revision history for this message
Mario Limonciello (superm1) wrote :

Hi Dennis:

I can verify that your patch works correctly on my XPS M1330. It doesn't apply cleanly to 2.6.24, so I'm attaching a cleaned up patch that does.

Tim Gardner (timg-tpi)
Changed in linux:
assignee: ubuntu-kernel-team → timg-tpi
status: Confirmed → In Progress
Changed in linux:
status: Incomplete → Confirmed
Revision history for this message
Anatoly Yushkov (yaa13) wrote :

Thanks, Mario.
How about to talk over with dell-team at Dell's PPA for patched deb package 2.6.24-17
http://ppa.launchpad.net/dell-team/ubuntu
May be it interesting for them?

Martin Pitt (pitti)
Changed in linux-source-2.6.22:
status: New → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in linux:
status: New → Fix Committed
Revision history for this message
Mario Limonciello (superm1) wrote :

I just pulled the -19 package from -proposed and tested a suspend on my 1330. It worked correctly and both cores returned to the lower frequency.

Revision history for this message
Tobias Heinemann (theine) wrote :

I can confirm that with the -19 kernel from hardy-proposed it works correctly on my Latitude D830 as well.

Moreover, the kernel does not issue any warnings or error messages whatsoever during a suspend/resume cycle. I believe that with earlier kernels there were usually some cryptic ACPI errors.

Revision history for this message
Mario Kemper (Romario) (mario-kemper) wrote :

I can confirm the fix as well. Great job, thank you.

Steve Langasek (vorlon)
Changed in linux:
assignee: nobody → timg-tpi
importance: Undecided → Low
milestone: none → ubuntu-8.04.1
milestone: ubuntu-8.04.1 → none
Revision history for this message
enigma_0Z (enigma-0za) wrote :

I can also confirm. -19 kernel from proposed works properly on my Dell Vostro 1400. Beautiful!

As far as the errors. Haven't bothered to check the logs, but AFAIK in response to above, ACPI errors were the root cause of the issues.

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

Also working here on Dell Latitude D630. No ACPI errors on suspend/resume.
Thanks Dennis and Mario for the fix!

Revision history for this message
enigma_0Z (enigma-0za) wrote :

Update manager seems to report that there's another update, pulling linux-generic, and the lrm package for this kernel. Looks to me like this has been made official... any word?

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

Now working for me as well.

Tim Gardner (timg-tpi)
Changed in linux:
status: In Progress → Fix Committed
Revision history for this message
ethanay (ethan-y-us) wrote :

Confirming that 2.6.24-19-generic appears to work on a Dell XPS m1330:

after resume from suspend:

~$cat /proc/cpuinfo | grep MHz
cpu MHz : 1000.000
cpu MHz : 1000.000
~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1500000 1000000
~$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies
1500000 1000000

the real confirmation come when I put it on battery power and idle stays at ~13watts after suspend vs jumping up to ~17watts in powertop....! Can anyone confirm power usage yet?

Changed in linux:
status: Confirmed → In Progress
Changed in dell:
status: Confirmed → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

Copied to hardy-updates. The new kernel was tested extensively by many people, who reported back in other bug reports. Due to lack of feedback, this particular bug was not confirmed to be tested, though. Please report back here if the bug still occurs for you with the new kernel packages, then we will reopen this bug.

Changed in linux:
status: Fix Committed → Fix Released
Changed in dell:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.26-4.12

---------------
linux (2.6.26-4.12) intrepid; urgency=low

  [ Ben Collins ]

  * e1000e: Upgraded module to 0.4.1.7 upstream. Placed in ubuntu/,
    in-kernel driver disabled
  * config: Disable e1000e in-kernel, and enable newer driver in ubuntu/
  * rfkill: Update to 1.3 drivers, and move to common location
  * ubuntu: Actually link kconfig/kbuild into rfkill subdir
  * config: Enable loading dsdt from initramfs
    - LP: #246222
  * ubuntu: [compcache] Update to fix crashes in improper BUG()
  * build: Create a retag scripts to recover tags from rebases
  * build: Updates for dbg pkg
  * build: Make sure no empty lines show up in debian/files
  * ubuntu: atl1e: Add new driver from 2.6.27-pre-rc1
    - LP: #243894
  * sys_getcwd: Fix some brokeness introduced by AppArmor __d_path
    changes
    - LP: #251223
  * ubuntu: unionfs: Added v1.4 module from hardy
  * build: Add sub-flavour infrastructure, and virtual subflav

  [ Eric Piel ]

  * ACPI: Allow custom DSDT tables to be loaded from initramfs

  [ Kees Cook ]

  * AppArmor: Smack VFS patches

  [ Mario Limonciello ]

  * Work around ACPI corruption upon suspend on some Dell machines.
    - LP: #183033

  [ Tim Gardner ]

  * Export usbhid_modify_dquirk for LBM module bcm5974
    - LP: #250838
  * VIA - Add VIA DRM Chrome9 3D engine
    - LP: #251862
  * Define TRUE/FALSE for VIA DRM driver.

 -- Ben Collins <email address hidden> Tue, 15 Jul 2008 12:51:39 -0400

Changed in linux:
status: Fix Committed → Fix Released
Changed in linux:
status: In Progress → Fix Released
Changed in linux:
importance: Unknown → Medium
Changed in somerville:
status: New → Fix Released
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305463

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

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