Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand

[Jonathan Nieder <jrnieder@gmail.com>]

Thomas Renard wrote:

> ok.txt: 2.6.39-2-686-pae
> fail.txt: 3.0.0-1-686-pae

Thanks.  Looks like the cpufreq driver doesn't get loaded early enough to
be included in these logs.  From the original report:

> p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible.
> ondemand governor failed, too long transition latency of HW, fallback to performance governor
> p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
> cpufreq-nforce2: No nForce2 chipset.
> powernow: This module only works with AMD K7 CPUs
> ondemand governor failed, too long transition latency of HW, fallback to performance governor

Please try blacklisting p4-clockmod or loading acpi-cpufreq first, to
see if that helps.

The "too long transition latency of HW" message comes from
__cpufreq_governor() in drivers/cpufreq/cpufreq.c and indicates
that (policy->cpuinfo.transition_latency >
policy->governor->max_transition_latency) was true.  Which leads to
the same conclusion: based on

	$ git show -s v2.6.30-rc1~678^2
	commit 36e8abf3
	Author: Dave Jones <davej@redhat.com>
	Date:   Thu Mar 5 00:16:26 2009 -0500

	    [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor.
 
	    The latency of p4-clockmod sucks so hard that scaling on a regular
	    basis with ondemand is a really bad idea.

	    Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
	    Signed-off-by: Dave Jones <davej@redhat.com>

I suspect we really want to be using acpi-cpufreq, not p4-clockmod.
So we're closing in.