Comment 14 for bug 432706

FYI (I'm not sure how relevant this still is) but 4294967295 is as recognisable a number as 10000001 is: it's -1 on a 32bit processor, or 0xFFFFFFFF.

The 10000001 number in the kernel mod I use is assigned by
   policy->cpuinfo.transition_latency = 10000001;

A grep for other modules setting this:
   grep 'policy->cpuinfo.transition_latency' /usr/src/linux/arch/x86/kernel/cpu/cpufreq/*.c
reveals a bunch of modules, for the different CPUs, that set:
   policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;

CPUFREQ_ETERNAL can be found by:
   grep CPUFREQ_ETERNAL /usr/src/linux/include/* -R
       /usr/src/linux/include/linux/cpufreq.h:#define CPUFREQ_ETERNAL (-1)

So that is indeed the figure. To reenable kernel ondemand/conservative support for your proc, simply edit the module source for your cpu, search for transition_latency = CPUFREQ_ETERNAL and replace it with 10000000. Note of course that I have a different cpu, so you should consider such an action as 'experiemental'; if the ondemand/conservative gov switches too quickly and your proc can't handle it, your system might run v.slow or stand still, so boot up with the performance/userspace gov and switch over to test, rather than set ondemand/conservative as the default on-boot governor.

This is of course just an FYI if you have the problem resolved another way; I just found the replies as I just updated my kernel and couldn't remember which file I edited first time round, so came back here to find my own post :-)