Re: SpeedStep frequency scaling support on Dothan-core Pentium-M CPUs, and cx88xx woes
Hi,
about the speedstep patch i searched a lot before finding it.... as
you've realized reading that file, it is patching, normally, a 2.6.8
version kernel =-O . It seems however that not everybody that owns a
dothan CPU has the same problem... this is weird for me and not
understandable....
Regards,
MC
Jo Shields wrote:
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: