(-cc: linux-arm-kernel, +cc: linux-kernel, Mattia)
Hi,
Dave Jones wrote:
> in cpufreq.next I moved the x86 drivers over. Someone look it over ?
Some people[1] have been seeing regressions after this change (when
moving from 2.6.39 to 3.0, presumably from commit bb0a56ecc4ba,
"[CPUFREQ] Move x86 drivers to drivers/cpufreq/"). The first symptom
was messages at boot:
| Loading cpufreq kernel modules...FATAL: Error inserting powernow_k7 (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/powernow-k7.ko): No such device
| FATAL: Error inserting speedstep_ich (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/speedstep-ich.ko): No such device
| FATAL: Error inserting acpi_cpufreq (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/acpi-cpufreq.ko): Device or resource busy
[etc]
The second symptom was the wrong cpufreq driver being loaded
(p4-clockmod instead of acpi-cpufreq). The cause seems to be some
code in init scripts that originated in powernowd 0.97-2ubuntu1 (2007)
or some time before that:
| #get list of available modules (governors and helpers)
| LOC="/lib/modules/$(uname -r)/kernel/drivers/cpufreq"
| if [ -d $LOC ]; then
| MODAVAIL=$( ( find $LOC -type f -name "*.o" -printf "basename %f .o\n"; \
| find $LOC -type f -name "*.ko" -printf "basename %f .ko\n" ) | /bin/sh)
| else
| MODAVAIL=""
| fi
|
| #echo "Loading cpufreq modules:"
| for mod in $MODAVAIL; do
| # echo " $mod"
| echo $LIST| grep -q -w "$mod" || modprobe $mod >/dev/null || /bin/true
| done
This takes all kernel modules in drivers/cpufreq, blindly assumes
they must be governors or helpers, and loads them. Nowadays it is
in the loadcpufreq script in cpufrequtils; so in cpufrequtils 007-2
(03 Aug 2011), the pattern changed to drivers/cpufreq/cpufreq_*.ko
which just matches the governors and helpers and everybody's happy.
Except:
(1) This is still incredibly fragile. What *should* cpufrequtils
be doing to get the drivers it needs?
(2) Using the 3.0 or later kernel with old userspace gives bad
results (e.g., 30% increase in power consumption for one
reporter). That's a regression. Bad kernel, no biscuit.
Ideas?
[1] http://bugs.debian.org/635348
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
