APPLIED: [Maverick][SRU] More fallout from 2.6.35.14 update

Tim Gardner tim.gardner at canonical.com
Mon Dec 5 14:08:32 UTC 2011


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 at canonical.com




More information about the kernel-team mailing list