FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 01-23-2010, 05:35 AM
Alex Chiang
 
Default ACPI: processor / EC enablement for core i7 platforms

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

If I totally botched this submission, I can reworkk them. Just let me
know what needs to happen.

Thanks,
/ac


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-26-2010, 08:19 AM
Stefan Bader
 
Default ACPI: processor / EC enablement for core i7 platforms

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


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-26-2010, 10:07 AM
Andy Whitcroft
 
Default ACPI: processor / EC enablement for core i7 platforms

On Fri, Jan 22, 2010 at 10:35:21PM -0800, Alex Chiang wrote:

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

As we are getting more than regular (!) stable updates for .32 if its
going that route we will get it shortly I am sure. But yes it looks
like the sort of thing we want.

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

If this is enabling broken platforms it would be nice to be able to get
this one via -stable too, to get it supported widly and it easier to
handle the longer-term stable tracking. If not we are in more of a
position to take this one in Lucid as we are still in Alpha.

If you could let us know if the second patch is likely to be going to
-stable, and if a more minimal fix is likely. Overall both enable pretty
common platforms and therefore interesting.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-26-2010, 07:12 PM
Alex Chiang
 
Default ACPI: processor / EC enablement for core i7 platforms

* Stefan Bader <stefan.bader@canonical.com>:
> Alex Chiang wrote:
> >
> > 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.

I poked lenb today to remind him to send the patch onto stable, so it
should appear 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.

Ok, I can do that. Anything special I should mark in Launchpad? Or just
reply here with the id after filing the bug?

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

I agree that the patch is hard to read unless you're intimately familiar
with it. Sorry about that; like I said, I really wasn't thinking
backport at the time, so what I sent you was the best I could do. :-/

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

Fair enough. I'm less concerned about Karmic for this patch than I am
with Lucid.

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

After talking with lenb today, we decided to mark the early _PDC patches
for stable too, on the justification that:

a) it enables real machines
b) the opt-in mechanism limits the amount of potential regressions

So lenb will send these patches for -stable rather soon. I can open
another bug for the _PDC patches.

Anything else I should do?

Thanks,
/ac

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-26-2010, 07:15 PM
Alex Chiang
 
Default ACPI: processor / EC enablement for core i7 platforms

* Andy Whitcroft <apw@canonical.com>:
> On Fri, Jan 22, 2010 at 10:35:21PM -0800, Alex Chiang wrote:
>
> > 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.
>
> If you could let us know if the second patch is likely to be going to
> -stable, and if a more minimal fix is likely. Overall both enable
> pretty common platforms and therefore interesting.

Like I responded to Stefan, the second patch will be in -stable (well,
technically it should be 3 or 4 separate patches).

I will open launchpad bugs for both patches.

When they do land in stable, does that make them likely to get picked up
for Karmic? Or are we just talking Lucid here? Not trying to be
insistent; just trying to understand the process.

Is there anything else I should do?

Thanks!
/ac


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 10:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org