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 12-02-2011, 11:55 PM
"Herton R. Krzesinski"
 
Default More fallout from 2.6.35.14 update

After one report and some automated digging I did, I came up detecting
more problems in 2.6.35.14 update. This is an attempt to avoid
regressions after applying it, before we hit bug reports.

This series contains patches which fixes referenced problems in some of
the commits present in 2.6.35.14

With the exception of the two reverts, all of them are already upstream
patches sent to stable at some point, even those without Cc: stable in
its original changelog:

* (pre-stable) x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
has Cc: stable (with a typo), reported by Julian Wiedmann on the
2.6.35.14 tracking bug, fixes a bug introduced by "x86, intel, power:
Initialize MSR_IA32_ENERGY_PERF_BIAS" in the stable update

* (pre-stable) mm: Fix fixup_user_fault() for MMU=n
As far as I know we don't have any kernel which have CONFIG_MMU=n set,
this fixes a regression with CONFIG_MMU=n
So it's optional to take this one. Doesn't have Cc: stable, but stable
grabbed it and applied on 3.0.2 for example.

* (pre-stable) USB: serial: pl2303: rm duplicate id
This fixes a regression, Cc: stable

I Added pre-stable to these patches, but I don't know if they will come
through another 2.6.35 update, or if we will have another 2.6.35 update.
I guess these, if applied, will not require verification, since they are
stable material?

Besides them, I added two reverts related to a single regression,
instead of backporting a fix upstream:
Revert "xen: Use IRQF_FORCE_RESUME"
Revert "genirq: Add IRQF_FORCE_RESUME"
For the reverted patches, which introduces a regression
(http://bugs.launchpad.net/bugs/898139), I did not apply the upstream
fix "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier".
I chose to revert them, because the upstream fix didn't apply cleanly,
it seems to require a similar backport as already applied on 2.6.32
stable series, but I didn't want to take a risky approach (the backport
isn't straightforward it seems), so I reverted them. May be Stefan wants
to take a look at this one.

Also since these are just related to the 2.6.35.14 update, not an SRU
per se, the BugLinks on them point to the 2.6.35.14 tracking bug. Should
a new bug be opened with an SRU Justification, or is this ok?

--
[]'s
Herton

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-05-2011, 09:18 AM
Stefan Bader
 
Default More fallout from 2.6.35.14 update

On 03.12.2011 01:55, Herton R. Krzesinski wrote:
> After one report and some automated digging I did, I came up detecting
> more problems in 2.6.35.14 update. This is an attempt to avoid
> regressions after applying it, before we hit bug reports.
>
> This series contains patches which fixes referenced problems in some of
> the commits present in 2.6.35.14
>
> With the exception of the two reverts, all of them are already upstream
> patches sent to stable at some point, even those without Cc: stable in
> its original changelog:
>
> * (pre-stable) x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
> has Cc: stable (with a typo), reported by Julian Wiedmann on the
> 2.6.35.14 tracking bug, fixes a bug introduced by "x86, intel, power:
> Initialize MSR_IA32_ENERGY_PERF_BIAS" in the stable update
>
> * (pre-stable) mm: Fix fixup_user_fault() for MMU=n
> As far as I know we don't have any kernel which have CONFIG_MMU=n set,
> this fixes a regression with CONFIG_MMU=n
> So it's optional to take this one. Doesn't have Cc: stable, but stable
> grabbed it and applied on 3.0.2 for example.
>
> * (pre-stable) USB: serial: pl2303: rm duplicate id
> This fixes a regression, Cc: stable
>
> I Added pre-stable to these patches, but I don't know if they will come
> through another 2.6.35 update, or if we will have another 2.6.35 update.
> I guess these, if applied, will not require verification, since they are
> stable material?
>
> Besides them, I added two reverts related to a single regression,
> instead of backporting a fix upstream:
> Revert "xen: Use IRQF_FORCE_RESUME"
> Revert "genirq: Add IRQF_FORCE_RESUME"
> For the reverted patches, which introduces a regression
> (http://bugs.launchpad.net/bugs/898139), I did not apply the upstream
> fix "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier".

> I chose to revert them, because the upstream fix didn't apply cleanly,
> it seems to require a similar backport as already applied on 2.6.32
> stable series, but I didn't want to take a risky approach (the backport
> isn't straightforward it seems), so I reverted them. May be Stefan wants
> to take a look at this one.

IIRC, the story here was that the actual fix was another patch before (I check
to make sure that is in Maverick). But the Xen folks felt the approach to have
flags in generic IRQ code was cleaner. Unfortunately this did not work as
expected. The upstream fix needs some PM code rework (which I am not sure
Maverick has or not).
Long story short, if the real fix is in there, I would rather leave those two
reverted patches out. Even more as there does not seem to be much longterm work
going on, so the chance that we need them because other things build on top is less.

-Stefan
>
> Also since these are just related to the 2.6.35.14 update, not an SRU
> per se, the BugLinks on them point to the 2.6.35.14 tracking bug. Should
> a new bug be opened with an SRU Justification, or is this ok?
>


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-05-2011, 12:54 PM
Tim Gardner
 
Default More fallout from 2.6.35.14 update

On 12/05/2011 03:18 AM, Stefan Bader wrote:


Long story short, if the real fix is in there, I would rather leave those two
reverted patches out. Even more as there does not seem to be much longterm work
going on, so the chance that we need them because other things build on top is less.



I read this as 'the 5 patches are fine as proposed', correct ?

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-05-2011, 01:06 PM
Herton Ronaldo Krzesinski
 
Default More fallout from 2.6.35.14 update

On Mon, Dec 05, 2011 at 11:18:56AM +0100, Stefan Bader wrote:
> On 03.12.2011 01:55, Herton R. Krzesinski wrote:
> > Besides them, I added two reverts related to a single regression,
> > instead of backporting a fix upstream:
> > Revert "xen: Use IRQF_FORCE_RESUME"
> > Revert "genirq: Add IRQF_FORCE_RESUME"
> > For the reverted patches, which introduces a regression
> > (http://bugs.launchpad.net/bugs/898139), I did not apply the upstream

Sorry, this was the wrong bug, this is the regression (the right URL):
bugs.launchpad.net/bugs/881542

> > fix "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier".
>
> > I chose to revert them, because the upstream fix didn't apply cleanly,
> > it seems to require a similar backport as already applied on 2.6.32
> > stable series, but I didn't want to take a risky approach (the backport
> > isn't straightforward it seems), so I reverted them. May be Stefan wants
> > to take a look at this one.
>
> IIRC, the story here was that the actual fix was another patch before (I check
> to make sure that is in Maverick). But the Xen folks felt the approach to have
> flags in generic IRQ code was cleaner. Unfortunately this did not work as
> expected. The upstream fix needs some PM code rework (which I am not sure
> Maverick has or not).
> Long story short, if the real fix is in there, I would rather leave those two
> reverted patches out. Even more as there does not seem to be much longterm work
> going on, so the chance that we need them because other things build on top is less.

What is the fix you mention? Problem here is that "genirq: Add
IRQF_RESUME_EARLY and resume such IRQs earlier" doesn't apply cleanly on
maverick, and we should decide either to backport it, or apply the
reverts. I didn't understand if you ack the reverts or not, can you take
a look at backporting/checking this if we end up not applying the
reverts?

>
> -Stefan

--
[]'s
Herton

--
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 04:05 AM.

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