[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060730190133.GD18757@redhat.com>
Date: Sun, 30 Jul 2006 15:01:33 -0400
From: Dave Jones <davej@...hat.com>
To: bert hubert <bert.hubert@...herlabs.nl>,
Alexey Starikovskiy <alexey_y_starikovskiy@...ux.intel.com>,
linux-kernel@...r.kernel.org, zwane@....linux.org.uk,
venkatesh.pallipadi@...el.com, tony@...mide.com, akpm@...l.org,
cpufreq@...ts.linux.org.uk, len.brown@...el.com
Subject: Re: 2.6.17 -> 2.6.18 regression: cpufreq broken since 2.6.18-rc1 on pentium4
On Sun, Jul 30, 2006 at 08:44:43PM +0200, bert hubert wrote:
> > Do you have any info in /sys/devices/system/cpu/cpu0/cpufreq ?
>
> No, not with just acpi-cpufreq loaded. With the help of Zwane, I've
> discovered that if I unload acpi-cpufreq, I *can* load p4-clockmod, and then
> the directory you mention appears, and I can configure governors, and life
> is good. This all on 2.6.18-rc3.
Right, cpufreq drivers aren't 'stackable'.
> Do I understand correctly that acpi-cpufreq is supposed to offer comparable
> features?
If the BIOS supports the relevant ACPI tables.
> Perhaps acpi-cpufreq *has* loaded, but did not find the proper hooks, but
> has now registered itself, thus blocking p4-clockmod? When everything is
> in-kernel, acpi-cpufreq might register itself first, which would lead to the
> same thing.
Normally, if the necessary BIOS bits aren't there, then acpi-cpufreq will
fail to register. For some reason it sounds like it believes that everything
went ok. I wonder if something changed in acpi recently that caused this
change in behaviour ? Len ?
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists