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 <da...@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 <mj...@srcf.ucam.org>
Signed-off-by: Dave Jones <da...@redhat.com>
I suspect we really want to be using acpi-cpufreq, not p4-clockmod.
So we're closing in.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
