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-05-2011, 01:08 PM
Tim Gardner
 
Default APPLIED: More fallout from 2.6.35.14 update

On 12/02/2011 05:55 PM, 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.

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?




--
Tim Gardner tim.gardner@canonical.com

--
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 07:28 PM.

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