CPU Frequency Scaling

[Javasnob]

I'm not sure about the kernel version; it may be different.

rob@TheRing ~ $ dmesg | grep -i cpu
...
Brought up 2 CPUs
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Processor [CPU2] (supports 8 throttling states)
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available

I thought this was interesting...ACPI reports that there's 8 throttling states for the CPU but cpufreq-info reports only the two.

I don't have a /var/log/messages.

[antidrugue]

rob@TheRing ~ $ dmesg | grep -i cpu
...
Brought up 2 CPUs
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Processor [CPU2] (supports 8 throttling states)
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available

I thought this was interesting...ACPI reports that there's 8 throttling states for the CPU but cpufreq-info reports only the two.

Indeed, so you have a CPU with Hyper-threading?


Instead of using "p4-clockmod", you could try to use the "acpi_cpufreq" driver, see if you have the same problem.

Also, when using the the "powersave" policy (which should use the lowest cpu frequency) what is the result?

Also, take a look at this, it seems the 2GHz lower limit could be a "feature" of "p4-clockmod" :
http://lkml.org/lkml/2006/3/22/11

Though I don't quite get this, I have p4-clockmod running on my machine right now and here is the output of

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

333325 666650 999975 1333300 1666625 1999950 2333275 2666600

[Javasnob]

Well, I fixed it...turns out the 2.6.16 kernel is what was causing all the trouble. The solution was to downgrade to 2.6.15, which isn't ideal, but it works for me. Thanks for all your help!