[<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
 
