Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
The latest version of cpufrequtils now contain an init.d script to load the needed kernel modules. It can be said to solve this issue. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
On Mon, 15 May 2006, Marco d'Itri wrote: On May 15, Raphael Hertzog [EMAIL PROTECTED] wrote: Marco, is there a way for udev to detect the kind of processors used and to load the right module depending on that? No, udev actually does not detect hardware, the kernel does. Until the kernel will generate for each CPU events with a $MODALIAS variable then probably the modules needed by powernowd should be loaded by that package. Given that I think the current script of Ubuntu is an acceptable compromise until the kernel sends events that would let udev know the CPU type and related information... It's the right thing to look for the good long term solution, that doesn't mean that we can't use intermediary solutions to provide out of the box support for our users. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
On May 15, Raphael Hertzog [EMAIL PROTECTED] wrote: Marco, is there a way for udev to detect the kind of processors used and to load the right module depending on that? No, udev actually does not detect hardware, the kernel does. Until the kernel will generate for each CPU events with a $MODALIAS variable then probably the modules needed by powernowd should be loaded by that package. -- ciao, Marco signature.asc Description: Digital signature
Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
Package: powernowd
Version: 0.97-1
Severity: wishlist
Tags: patch
Hi Bdale,
Ubuntu has some interesting changes to the powernowd package:
http://people.ubuntu.com/~scott/patches/powernowd/powernowd_0.96-2ubuntu2_packaging.patch
They add a script detecting the CPU type and automatically loading the
right cpufreq_ module. This is the kind of changes that make Ubuntu just
work that we should really integrate back. Please consider this.
Cheers,
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages powernowd depends on:
ii libc6 2.3.6-7GNU C Library: Shared libraries
powernowd recommends no packages.
-- no debconf information
diff -pruN powernowd_0.96-1/debian/control
powernowd_0.96-2ubuntu2/debian/control
--- powernowd_0.96-1/debian/control 2005-12-06 13:32:44.0 +
+++ powernowd_0.96-2ubuntu2/debian/control 2006-02-24 14:29:09.0
+
@@ -7,8 +7,7 @@
Package: powernowd
Architecture: any
-Depends: ${shlibs:Depends}
-Conflicts: cpudyn, cpufreqd
+Depends: ${shlibs:Depends}, lsb-base (= 1.3-9ubuntu2), module-init-tools
(=3.1-rel-2ubuntu2), laptop-detect
Description: control cpu speed and voltage using 2.6 kernel interface
This simple client controls CPU speed and voltage using the sysfs interface
to the CPUFreq driver in v2.6 Linux kernels. It does not depend on APM or
diff -pruN powernowd_0.96-1/debian/cpufreq-detect.sh
powernowd_0.96-2ubuntu2/debian/cpufreq-detect.sh
--- powernowd_0.96-1/debian/cpufreq-detect.sh 1970-01-01 01:00:00.0
+0100
+++ powernowd_0.96-2ubuntu2/debian/cpufreq-detect.sh2006-02-24
14:29:09.0 +
@@ -0,0 +1,94 @@
+#! /bin/bash
+
+if /usr/sbin/laptop-detect; then LAPTOP=1; fi
+CPUINFO=/proc/cpuinfo
+IOPORTS=/proc/ioports
+
+if [ ! -f $CPUINFO ] ; then
+echo $CPUINFO not detected... 2
+exit 1
+fi
+
+MODEL_NAME=`grep '^model name' $CPUINFO | head -1 | sed -e 's/^.*: //;'`
+CPU=`grep -E '^cpud[^:]+:' $CPUINFO | head -1 | sed -e 's/^.*: //;'`
+VENDOR_ID=`grep -E '^vendor_id[^:]+:' $CPUINFO | head -1 | sed -e 's/^.*:
//;'`
+CPU_FAMILY=$(sed -e '/^cpu family/ {s/.*: //;p;Q};d' $CPUINFO)
+
+MODULE=none
+MODULE_FALLBACK=acpi-cpufreq
+
+# Two modules for PIII-M depending the chipset.
+# modprobe speedstep-ich$EXT || modprobe speestep-smi$EXT would be another way
+if [ -f $IOPORTS ] grep -q 'Intel .*ICH' $IOPORTS ; then
+ PIII_MODULE=speedstep-ich
+else
+ PIII_MODULE=speedstep-smi
+fi
+
+case $VENDOR_ID in
+GenuineIntel*)
+# If the CPU has the est flag, it supports enhanced speedstep and should
+# use the speedstep-centrino driver
+if [ `grep est $CPUINFO` ]; then
+ MODULE=speedstep-centrino;
+elif [ $CPU_FAMILY = 15 ]; then
+# Right. Check if it's a P4 without est.
+ # Could be speedstep-ich, or could be p4-clockmod.
+ MODULE=speedstep-ich;
+ # Disabled for now - the latency tends to be bad enough to make it
+ # fairly pointless.
+ # echo FREQDRIVER=p4-clockmod /etc/default/powernowd
+ # to override this
+# if [ $LAPTOP = 1 ]; then
+# MODULE_FALLBACK=p4-clockmod;
+# fi
+else
+# So it doesn't have Enhanced Speedstep, and it's not a P4. It could be
+# a Speedstep PIII, or it may be unsupported. There's no terribly good
+# programmatic way of telling.
+ case $MODEL_NAME in
+ Intel\(R\)\ Pentium\(R\)\ III\ Mobile\ CPU*)
+ MODULE=$PIII_MODULE ;;
+
+# JD: says this works with cpufreq_userspace
+ Mobile\ Intel\(R\)\ Pentium\(R\)\ III\ CPU\ -\ M*)
+ MODULE=$PIII_MODULE ;;
+
+# https://bugzilla.ubuntu.com/show_bug.cgi?id=4262
+# UNCONFIRMED
+ Pentium\ III\ \(Coppermine\)*)
+ MODULE=$PIII_MODULE
+ ;;
+ esac
+fi
+;;
+AuthenticAMD*)
+# Hurrah. This is nice and easy.
+case $CPU_FAMILY in
+ 5)
+ # K6
+ MODULE=powernow-k6
+ ;;
+ 6)
+ # K7
+ MODULE=powernow-k7
+ ;;
+ 15)
+ # K8
+ MODULE=powernow-k8
+ ;;
+esac
+;;
+CentaurHauls*)
+# VIA
+if [ $CPU_FAMILY == 6 ]; then
+ MODULE=longhaul;
+fi
+;;
+GenuineTMx86*)
+# Transmeta
+if [ `grep longrun $CPUINFO` ]; then
+ MODULE=longrun
+fi
+;;
+esac
diff -pruN powernowd_0.96-1/debian/dirs powernowd_0.96-2ubuntu2/debian/dirs
--- powernowd_0.96-1/debian/dirs2005-12-06 13:32:44.0 +
+++ powernowd_0.96-2ubuntu2/debian/dirs 2006-02-24 14:29:09.0 +
@@ -1 +1,2 @@
usr/sbin
+usr/share/powernowd
diff -pruN powernowd_0.96-1/debian/init.d powernowd_0.96-2ubuntu2/debian/init.d
--- powernowd_0.96-1/debian/init.d
Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
On Sun, 2006-05-14 at 18:03 -0500, Raphael Hertzog wrote: Ubuntu has some interesting changes to the powernowd package: They add a script detecting the CPU type and automatically loading the right cpufreq_ module. This is the kind of changes that make Ubuntu just work that we should really integrate back. Please consider this. Someone over there contacted me before they implemented this, or soon after. I'm not happy about the idea of just grabbing this patch as-is, despite agreeing that it would be nice for powernowd to just work. That's because I continue to believe that knowledge of processor specifics does not belong in a package that lives entirely above a well-defined kernel interface that is processor agnostic. The fact that some other processor-specific module must also be loaded to make that interface work seems like it should be handled either by the kernel packaging, hotplug/udev, or some other package that every daemon trying to manage through this interface (powernowd isn't the only one, after all!) can depend on, so that this information is captured exactly once and as close to the hardware and kernel as possible. What do you think? Am I just being pedantic, or can we come up with a better way of providing the saem ultimate functionality to Debian users that's a better design for the long term? Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367307: powernowd: Powernowd should automatically load the right kernel modules
On Sun, 14 May 2006, Bdale Garbee wrote: They add a script detecting the CPU type and automatically loading the right cpufreq_ module. This is the kind of changes that make Ubuntu just work that we should really integrate back. Please consider this. Someone over there contacted me before they implemented this, or soon after. I'm not happy about the idea of just grabbing this patch as-is, despite agreeing that it would be nice for powernowd to just work. That's because I continue to believe that knowledge of processor specifics does not belong in a package that lives entirely above a well-defined kernel interface that is processor agnostic. The fact that some other processor-specific module must also be loaded to make that interface work seems like it should be handled either by the kernel packaging, hotplug/udev, or some other package that every daemon trying to manage through this interface (powernowd isn't the only one, after all!) can depend on, so that this information is captured exactly once and as close to the hardware and kernel as possible. What do you think? Am I just being pedantic, or can we come up with a better way of providing the saem ultimate functionality to Debian users that's a better design for the long term? There's always room to do things better but in this case I have not enough knowledge of udev and the like to be able to judge anything. Thus I'm ccing Marco to have his input as udev maintainer. Marco, is there a way for udev to detect the kind of processors used and to load the right module depending on that? Also I don't know if those modules should be always loaded or if they should be loaded only when powernowd is installed... Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
