Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
On Fri, Aug 12, 2011 at 06:11:23PM +0200, Thomas Renard wrote:
> Am 11.08.2011 23:27, schrieb Jonathan Nieder:
> > 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.
>
> Blacklisting works.
>
> I put it into /etc/modprobe.d/eeepc.conf, which belongs to
> eeepc-acpi-scripts (see patch). Now the question is: is it an EEE-PC
> only problem or does this happen to other systems too?
[...]
It is not EeePC-specific.
cpufreq modules are loaded by the cpufrequtils package, and it is
now loading the wrong modules due to a change in the installation
location of the modules. This is bug #636141, fixed in version
007-2.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Reply to: