SpeedStep frequency scaling support on Dothan-core Pentium-M CPUs, and cx88xx woes
I was installing sarge onto my home theatre machine recently (Pentium-M
1.7Ghz, AOpen i855 motherboard), and was a little dismayed to find that
there was no support for CPU frequency/voltage scaling
(SpeedStep(tm)(r)(c)). A "modprobe speedstep-centrino" informed me that
there was no frequency table data for my CPU, and nothing improved by
going to a 2.6.11 kernel from Sid.
A brief google on the issue showed some information on the topic, at
http://ubuntuforums.org/showthread.php?t=19686&page=1&pp=20 - including
a patch for speedstep-centrino.c. I have tried the patch on my own
kernel-source-2.6.11, and the system now happily jumps between 600Mhz
and 1700Mhz when powernowd tells it to.
It's an entirely trivial patch, and even with my limited C and
non-existant kernel hacking skills, I can get a good idea of what's
going on.
Can I suggest the patch at least be used in the latest sid kernels, if
not shunted into sarge?
For what it's worth, p4-clockmod DOES work with Dothan, but gives a big
warning about its use on Pentium-M (p4-clockmod does not do voltage
scaling, only frequency, which can cause hardware problems)
-----
On an unrelated note, I have been having a rough time of the Conexant
CX88 V4L support in the kernel. 2.6.8 kernel-images support it, 2.6.9
only does on amd64, 2.6.10 supports it again, 2.6.11 doesn't work at all
(and won't compile with it). It seems from the Debian changelog that
some V4L patches from bytesex.org are already being applied to other
portions of the drivers/media/ tree (and mention is made that the
patches are not self contained). It appears that they're
not-self-contained enough that bytesex's patches for cx88 and associated
DVB frontends (e.g. drivers/media/dvb/frontends/mt352.c) will not patch
correctly against kernel-source-2.6.11.
After an extended period of annoyance and woe, i ripped the entire
media/ folder from my /usr/src/kernel-source-2.6.11/drivers/, extracted
a replacement from upstream kernel.org source, and applied the
bytesex.org patches without any trouble.
If $foo_v4l is going to be patched, is there any reason not to patch
$bar_v4l at the same time? It seems more than a little odd to drop one
module for odd-numbered kernels, yet to happily patch a similar module
from the same developer.
--Jo Shields
Reply to: