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

Bug #183033 reported by enigma_0Z on 2008-01-15
72
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
Ubuntu
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
linux (Ubuntu)
Low
Tim Gardner
Hardy
Low
Tim Gardner
Intrepid
Low
Tim Gardner
linux-source-2.6.22 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
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.

enigma_0Z (enigma-0za) wrote :

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

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.

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...

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).

David Tomaschik (matir) wrote :

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

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?

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

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/*?

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.

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.

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?)

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).

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)

enigma_0Z (enigma-0za) wrote :

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

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.

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.

Chris Irwin (chrisirwin) wrote :

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

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...

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.

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?

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.

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.

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

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)

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.

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.

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.

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.

LEVIS Cyril (atlas95) wrote :

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

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

zakimak (zakimak) wrote :

Arf, no changes after this upgrade ...

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.

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

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
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 :(

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.

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

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>

Changed in linux:
status: Fix Released → Confirmed
Changed in dell:
status: Fix Released → Confirmed
Changed in linux-source-2.6.22:
status: Confirmed → Won't Fix
Tim Gardner (timg-tpi) on 2008-04-17
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Low
milestone: none → ubuntu-8.04.1
27 comments hidden view all 107 comments

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?

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

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.

@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!

@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?

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

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.

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.

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.

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?

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.

zakimak (zakimak) wrote :

@Ethanay : try "rmmod -f acpi_cpufreq"

ethanay (ethan-y-us) wrote :

thanks for the suggestion.

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

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.

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.
>

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 :-)

  • 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.

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

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!

David Johnston (johnsto) wrote :

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

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
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.

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? :-)

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?)

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 :-)

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) on 2008-05-27
Changed in linux:
assignee: ubuntu-kernel-team → timg-tpi
status: Confirmed → In Progress
Changed in linux:
status: Incomplete → Confirmed
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) on 2008-06-04
Changed in linux-source-2.6.22:
status: New → Won't Fix
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in linux:
status: New → Fix Committed
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.

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.

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

Steve Langasek (vorlon) on 2008-06-07
Changed in linux:
assignee: nobody → timg-tpi
importance: Undecided → Low
milestone: none → ubuntu-8.04.1
milestone: ubuntu-8.04.1 → none
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.

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

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?

Mathieu Marquer (slasher-fun) wrote :

Now working for me as well.

Tim Gardner (timg-tpi) on 2008-06-09
Changed in linux:
status: In Progress → Fix Committed
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
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
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

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
Displaying first 40 and last 40 comments. View all 107 comments or add a comment.
This report contains Public information  Edit
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.