[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: