Message-ID: <20090428193303.GC6968@plum>
Date:	Tue, 28 Apr 2009 12:33:04 -0700
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Thomas Renninger <trenn@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, cpufreq@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot
	even when ignore_ppc=0

On Thu, Apr 16, 2009 at 11:45:07PM +0100, Matthew Garrett wrote:

> That's not really an option. It works with Windows.

Who verified that?  Does anyone know what strategy Windows uses to avoid this
T60 problem?  

> Please figure out how to make it work on everything rather than us just
> repeatedly toggling between different sets of broken machines or being forced
> to have a static table of machines.

I've thought about this for a while and still don't know how to proceed with
this suggestion.  Right now we have:

1. Linux, which right now does not read _PPC at boot time regardless of the
ignore_ppc setting, leaving the kernel's copy set to 0 regardless of what the
BIOS wants the kernel to do.  The kernel will pick up the correct value of _PPC
if the BIOS sends a "re-evaluate _PPC" event.

Obviously, if ignore_ppc=1 then we should ignore _PPC, but I'm talking about
_PPC not being read when ignore_ppc=0 or ignore_ppc isn't set at all.

2. A whole lot of machines that set _PPC to 0 all the time; this scenario
works because _PPC and the cpufreq max_freq controls just happen to match.

3. A smaller collection of machines that leave _PPC at 0 except for special
circumstances that warrant freq/voltage restrictions (power overage,
thermal/power throttling via p-state, etc.)

This is a problem for the following sequence:

  1. BIOS decides to set _PPC to any non-zero value.
  2. The kernel boots with ignore_ppc=0, doesn't check _PPC, and runs with
     all p-states enabled.

      <here is where we're running with the wrong _PPC and potentially
       using more power/putting out more heat than the firmware wants>

  3. BIOS changes _PPC to something else and sends a Notify event.
  4. Kernel now runs with the correct p-state restrictions.

4. Broken T60s where the EC (which is read in the _PPC method) freaks out and
returns 2 all the time.  If you set ignore_ppc=1 then you get the full range of
speeds even if the BIOS doesn't want to allow it.  Clearly the firmware needs
some sort of fix, which means that we could Lenovo, which may or may not
succeed because T60s were discontinued 18 months ago.

I can think of a few ways to proceed with the kernel:

1. No changes at all.  If ignore_ppc = 0 and _PPC != 0 when the kernel boots,
the kernel ignores the BIOS.  That seems broken to me.

2. Add my revert patch, which leaves the ignore_ppc toggle in place for T60
owners.  This doesn't satisfy the "no toggling" rule, but at least there's
still an override for when the automatic method doesn't work.

3. Add the revert patch and put in a DMI check to turn on ignore_ppc for all
T60s.  This doesn't satisfy the "static table" constraint though at least it
requires less manual intervention.

I'd rather have the kernel work for the vast majority of machines that do not
freak out, and special case the ones that do.  But I'm not clever enough to
figure out a solution that fixes the runs-with-wrong-_PPC problem, avoids
reading _PPC on machines that freak out, and doesn't involve blacklists or a
toggle.  Any suggestions?

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