[PATCH 0/2] ACPI: processor / EC enablement for core i7 platforms

Stefan Bader stefan.bader at canonical.com
Tue Jan 26 09:19:40 UTC 2010


Alex Chiang wrote:
> Hi,
> 
> I'm probably bungling this up quite a bit, as it's my first
> Ubuntu-specific patch submission, so I'm sure I missed a few of the
> conventions.
> 
> Anyhow, I'd like to propose these two patches for Karmic, but if not
> Karmic, then at least for Lucid (and I can redo the backport).
> 
> The first one is important: it will enable many new laptops with Intel
> Core i7 processors to idle much cooler and turns on TurboBoost. We
> discovered a common BIOS bug; lots of BIOS writers are specifying a C2
> latency greater than what Linux accepts (100us). As a result, Linux
> doesn't take advantage of the available C-states, idles much hotter, and
> rarely engages TurboBoost. Removing the check enables all that good
> stuff.
> 
> Len told me on irc that he plans on marking it for -stable, but hasn't
> gotten around to it yet.

The first one I think is ok to have in Karmic. Depending on the upstream stable
submission it might land in Lucid without further effort (Greg is queuing up for
2.6.32.7 but I had no time to look into those), so maybe its there or not. But
given the current speed it would work if This is forwarded to stable soon.
To include it into Karmic, we have to open a Launchpad bug about it, so we can
link the SRU request and patch to it.

> The second one is a little uglier. I discovered that some platforms need
> to evaluate the _PDC method before initializing the EC. This early
> evaluation loads some dynamic SSDTs and allows EC init to succeed.
> 
> So I wrote the patches for upstream without really thinking of
> backporting issues... and did a whole lot of code movement and cleanup
> as well. I also discovered after the fact that there are other BIOSes
> out there with landmines if you try and do early _PDC (I can explain
> more if necessary). Anyway, Len asked me to make it an opt-in feature
> given that upstream is currently in .33-rc4, which made sense.
> 
> The patch prevents ACPI initialization errors on many new HP Core i7
> laptops, and allows other users to also try to opt-in for early _PDC as
> well, if they are getting ACPI namespace undef errors.
> 
> To make a long story short(er), I cherry-picked the 3 patches (out of
> the 14 upstream ones) that actually enable the platforms, and left out
> all the code cleanup stuff.
> 
> Hopefully that makes sense. Like I said, I'd like to see these patches
> in Karmic, as there are lots of users out there that would be helped
> today, and I'd want to seem them carried for Lucid too, since that's .32
> based and my patches went into .33-rcx.

I only glanced over the patch and so this is not the last word. But generally
its size and the fact that it moves around code at the same time make me a bit
reluctant to pick it for Karmic. Even tough it allows running Karmic on
additional hardware. With the other changes it is harder to tell whether the
code does the same without opting in.
So for Karmic at least I would rather see a patch that is minimalistic in
change. OTOH I am not sure this is worth effort on Karmic as the window for
non-critical and non-security fixes is closing mid-Feb. But probably Andy thinks
the same for Lucid and we should try to get a minimal patch suitable for stable
out of this.
[Again this should get its own bug report to track things]

-Stefan
> If I totally botched this submission, I can reworkk them. Just let me
> know what needs to happen.
> 
> Thanks,
> /ac
> 
> 





More information about the kernel-team mailing list