cpufreq scaling_grovernor only saved for CPU0 on SMP following suspend/resume.

This cannot be caused by quidance-power-management as all the cpufreq stuff is done by kernel (ondemand) and powernowd (if ondemand is not supported). It may be that hibernate/suspend preparation does something wrong.

Can you attach:
 - output of "dmesg"
 - output of "cat /sys/devices/system/cpu/*/cpufreq/*"

Thanks for your fast reply
In the attachment I did put the files...
please let me know.
Kindest regards
Igor

Am Mittwoch, 25. Oktober 2006 17:10 schrieb Luka Renko:
> This cannot be caused by quidance-power-management as all the cpufreq
> stuff is done by kernel (ondemand) and powernowd (if ondemand is not
> supported). It may be that hibernate/suspend preparation does something
> wrong.
>
> Can you attach:
> - output of "dmesg"
> - output of "cat /sys/devices/system/cpu/*/cpufreq/*"
>
> ** Changed in: kde-systemsettings (Ubuntu)
> Sourcepackagename: kde-systemsettings => acpi-support
> Status: Unconfirmed => Needs Info

--
MTN MiniTechNet
where the future goes mini

http://www.minitechnet.de
http://www.minitechnet.com

igor@MTN-Notebook-Nexoc:~$ cat /sys/devices/system/cpu/*/cpufreq/*
0
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
1826000
996000
cat: /sys/devices/system/cpu/cpu0/cpufreq/ondemand: Is a directory
1826000 1826000 1826000 1826000 1826000 1826000 1826000 1826000 1328000 996000
userspace powersave ondemand conservative performance
996000
centrino
ondemand
1826000
996000
cat: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory
1
cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: Permission denied
1826000
996000
1826000 1826000 1826000 1826000 1826000 1826000 1826000 1826000 1328000 996000
userspace powersave ondemand conservative performance
1826000
centrino
performance
1826000
996000
cat: /sys/devices/system/cpu/cpu1/cpufreq/stats: Is a directory

[17179569.184000] Linux version 2.6.17-10-generic (root@vernadsky) (gcc version
4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 SMP Fri Oct 13 18:45:35
 UTC 2006 (Ubuntu 2.6.17-10.33-generic)
[17179569.184000] BIOS-provided physical RAM map:
[17179569.184000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[17179569.184000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[17179569.184000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[17179569.184000] BIOS-e820: 0000000000100000 - 000000003f7d0000 (usable)
[17179569.184000] BIOS-e820: 000000003f7d0000 - 000000003f7de000 (ACPI data)
[17179569.184000] BIOS-e820: 000000003f7de000 - 000000003f800000 (ACPI NVS)
[17179569.184000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[17179569.184000] BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
[17179569.184000] 119MB HIGHMEM available.
[17179569.184000] 896MB LOWMEM available.
[17179569.184000] found SMP MP-table at 000ff780
[17179569.184000] On node 0 totalpages: 260048
[17179569.184000] DMA zone: 4096 pages, LIFO batch:0
[17179569.184000] Normal zone: 225280 pages, LIFO batch:31
[17179569.184000] HighMem zone: 30672 pages, LIFO batch:7
[17179569.184000] DMI present.
[17179569.184000] ACPI: RSDP (v000 ACPIAM ) @ 0x0
00f9120
[17179569.184000] ACPI: RSDT (v001 A M I OEMRSDT 0x03000615 MSFT 0x00000097) @
 0x3f7d0000
[17179569.184000] ACPI: FADT (v002 A M I OEMFACP 0x03000615 MSFT 0x00000097) @
 0x3f7d0200
[17179569.184000] ACPI: MADT (v001 A M I OEMAPIC 0x03000615 MSFT 0x00000097) @
 0x3f7d0390
[17179569.184000] ACPI: MCFG (...

Same bug at me.

https://launchpad.net/distros/ubuntu/+source/kde-guidance/+bug/72108

After suspending and resuming a laptop (Core Duo T2500, IBM T60), the clock speed of one CPU core goes up to maximum (2.0 GHz at me). The another core remains at low speed (certainly, no process consumes the CPU except minimal CPU usage of the usual ones like Xorg, etc.).

If I run

sudo powernowd

the clock speeds fall back to normal state (until next suspend/resume).

Release: Kubuntu 6.10, nothing special.

It seems that one core goes into "performance" state instead of ondemand.

cat /sys/devices/system/cpu/*/cpufreq/*cat /sys/devices/system/cpu/*/cpufreq/*

0
2000000
2000000
1000000
2000000 1667000 1333000 1000000
userspace powersave ondemand conservative performance
1000000
centrino
userspace
2000000
1000000
1000000
cat: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory
1
2000000
2000000
1000000
2000000 1667000 1333000 1000000
userspace powersave ondemand conservative performance
2000000
centrino
performance
2000000
1000000

Marking as confirmed due to many duplicates.
Not sure if the package is appropriate, I would think kernel is more likely responsible for this.

On Sat, Jan 06, 2007 at 02:24:12PM -0000, Luka Renko wrote:
> Marking as confirmed due to many duplicates.
> Not sure if the package is appropriate, I would think kernel is more
> likely responsible for this.

 The kernel could preserve that state across suspend, but it doesn't have to
be the kernel's job. user-space should apply the configured policy for CPU
hotplug events. This would ensure correct behaviour in all CPU hotplug
cases, not just suspend-resume where the kernel hot-unplugs all but one CPU
before suspend. (This is maybe only likely to happen with virtual machines,
because most desktop hardware isn't physically hotplug safe. And AFAIK Xen
prevents cpufreq from working.)

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

We did some investigation into this (see bug #78512). Turns out that the kernel hotunplugs the CPUs during a suspend/resume, so the CPUs actually /disappear/ and therefore can't retain their state.

Ideally this is fixed in 'udev' in the long run with hotplug CPU support; in the medium term we'll do it in 'acpi-support' before/after suspend/resume.

acpi-support (0.94) feisty; urgency=low

  * Save and restore values that the kernel does not preserve across
    suspend/resume and hibernate/resume:
    - /sys/class/net/eth*/device/rf_kill
    (Closes: LP #37010)
    - /proc/acpi/ibm/bluetooth
    (Closes: LP #37175)
    - /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    (Closes: LP #68191)
  * White list Lenovo ThinkPad Z60m as working suspend.
    (Closes: LP #57144)

 -- Paul Sladen <email address hidden> Thu, 22 Mar 2007 03:57:36 +0000

It still does not work on a Lenovo T60.

An addition: the governor on CPU1 is now 'userspace' after suspend. However, it still stays at top speed without any usage.

Problem still exists for me: No /sys/devices/system/cpu/cpu1/cpufreq on resume. I am using acpi-support scripts to suspend my system instead of powersaved, however, because powersaved does not resume my nVidia graphics card properly.

I'm on Gutsy (7.10) right now, is there a fix available yet?

Does anyone else think this might be a duplicate of #124797 or #183033 (or both?)

It's hard to tell, but they definitely seem related to me.

I have seen this bug report and the dups. Not sure which one to choose. This seems to be the best. I have attached the output of $cpufreq-info. I always have this problem since upgrade to 7.10. Does not require a suspend. Alway the same. The output

current policy: frequency should be within 1000 MHz and 1000 MHz

cannot scale. Always set to 1000 MHZ.

David

I think I have the same problem. on the early Gutsy final versions, CPU1 got stuck on 2 GHz (full speed) most of the time after a suspend-to-ram. But now CPU1 always gets stuck at 800 MHz (lowest speed) after a suspend. Performance scaling with CPU0 works fine.

I have added a more detailed comment and logs to Bug #183033
https://bugs.launchpad.net/ubuntu/+bug/183033/comments/23

I think these both bugs are the same, and the behaviour simply changed with some Kernel update, but as the other bug is describing the problem I currently have, I'm participating there in more detail.

Setting status back to confirmed since previous fix apparently doesn't work as expected.

Tested this with the new Hardy Alpha 5 LiveCD.

CPU1 gets stuck at 2 GHz (full speed) again now after resuming from a suspend.

I have the a similar problem with Hardy.
After resume, both cpu cores are set to performance governor
and full speed.

I am also experiencing this on Dell Latitude D830, running 64_x86 8.04 beta + updates. I logged output from "dmesg", "cat /sys/devices/system/cpu/*/cpufreq/*" (and "cat /proc/cpuinfo" for the heck of it) both before a suspend (both cores in ondemand mode) and after coming back from suspend (core#1 stuck in performance mode) - see attachment.

Dell XPS m1330
Intel Core 2 Duo 1.5ghz
Hardy 8.04 w/latest

I am NOT running powernowd -- I am using ondemand directly via and made permanent via sysfs.conf

I can confirm after resume from suspend, CPU1 is locked at its maximum. This is not a cosmetic bug, as powertop reports ~3-4 watts greater usage on idle (from ~13watts to 16-17watts).

resume from hibernate does not reproduce the bug -- only suspend S3 in my case.

is bug 124797 depicting different symptoms of this same problem? in other words, is it a separate cosmetic bug or will it go away after the scaling issue is fixed?

sudo modprobe -r acpi_cpufreq is not allowed, requiring full reboot to fix cpu scaling

"FATAL: Module acpi_cpufreq is in use."

Hi!

I'm not using Ubuntu right now. Running Gentoo with kernel 2.6.25 with processor ACPI compiled in the kernel as well as cpu frequency scaling and governors and the problem do exists on my setup. Maybe this confirm it's a kernel issue. Any information i can provide, just ask.

Running on Dell Vostro 1400.
Intel Core 2 Duo 2.0GHz.

I'm not sure if this is being tracked elsewhere, but I'm certainly finding that /sys/devices/system/cpu/cpufreq/ondemand/up_threshold (for example) gets reset after resume from sleep.

I'm using sysfsutils and my workaround is to drop a script in /etc/pm/sleep.d/90_sysfsutils:

#!/bin/sh

# Tell grub that resume was successful

case "$1" in
        resume)
        /etc/init.d/sysfsutils restart
                ;;
esac

I'm not sure if that's ideal, but it seems to get the job done.