Bug#618832: cpufreq transition latency set incorrectly for PowerMac G5 CPUs
Package: linux-image-2.6.32-5-powerpc64
Version: 2.6.32-31
Tags: patch fixed-upstream squeeze
The 2.6.32-31 kernel from squeeze-proposed-updates (and 2.6.32-30 from squeeze) sets the frequency transition latency on PowerMac G5s' CPUs to CPUFREQ_ETERNAL:
# uname -a
Linux crash 2.6.32-5-powerpc64 #1 SMP Tue Mar 8 02:01:42 UTC 2011 ppc64 GNU/Linux
# dpkg -l linux-image-\* | grep ^ii
ii linux-image-2.6-powerpc64 2.6.32+29 Linux 2.6 for 64-bit PowerPC (meta-package)
ii linux-image-2.6.32-5-powerpc64 2.6.32-31 Linux 2.6.32 for 64-bit PowerPC
# cat /proc/cpuinfo
processor : 0
cpu : PPC970FX, altivec supported
clock : 2700.000000MHz
revision : 3.1 (pvr 003c 0301)
processor : 1
cpu : PPC970FX, altivec supported
clock : 2700.000000MHz
revision : 3.1 (pvr 003c 0301)
timebase : 33333333
platform : PowerMac
model : PowerMac7,3
machine : PowerMac7,3
motherboard : PowerMac7,3 MacRISC4 Power Macintosh
detected as : 336 (PowerMac G5)
pmac flags : 00000000
L2 cache : 512K unified
pmac-generation : NewWorld
# grep . /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_transition_latency
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency:4294967295
This keeps the ondemand cpufreq governor from working:
# for x in 0 1; do echo ondemand > /sys/devices/system/cpu/cpu$x/cpufreq/scaling_governor; done
# dmesg | tail -n 2
[ 1380.988816] ondemand governor failed, too long transition latency of HW, fallback to performance governor
[ 1380.990366] ondemand governor failed, too long transition latency of HW, fallback to performance governor
This was fixed in the 2.6.32.* tree in March 2009, and the same code is still in use in 2.6.38.
Can Debian's 2.6.32 kernel pick up this patch as well?
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commitdiff_plain;h=16962e7ce1dce29e1e92d231ac7d6844d7385d54
Alternatively, in case the above link gets mangled by wrapping:
http://bit.ly/gYKmiV
Reply to: