APPLIED: [2.6.32+drm33-longterm] Linux 2.6.32.43+drm33.19

[Tim Gardner]

On 07/14/2011 09:35 AM, Stefan Bader wrote:
> On 14.07.2011 17:24, Stefan Bader wrote:
>> On 14.07.2011 17:11, Tim Gardner wrote:
>>> On 07/14/2011 09:07 AM, Stefan Bader wrote:
>>>> On 14.07.2011 14:51, Tim Gardner wrote:
>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810425
>>>>
>>>>
>>>> Seems, Tim, you just dropped the new xen patch. OK, I don't know
>>>> exactly what the preference for stable is, but we may want to get
>>>> back to be same as upstream...
>>>>
>>>> -Stefan
>>>>
>>>
>>> Indeed I did as I saw no reason to revert the revert only to apply the revert
>>> yet again.
>>>
>>> I'm not sure I see the value in being the same as upstream stable. In fact,
>>> we're not identical as soon as we revert _any_ patch that has arrived via stable.
>>>
>>> rtg
>>
>> Though reverting the revert (which was reverting an upstream stable patch) would
>> make the kernel be the same as upstream. And then adding the additional (partial
>> revert) fixes the breakage. I agree it sounds confusing...
>>
>>
> Ok, I don't think that helped much...
>
> So the initial patch from upstream changed things affecting 32 and 64 bit in
> order to fix a breakage caused by another patch (however that one was reverted
> from upstream stable because it caused some other regression and has not been
> re-applied yet (with the fix that fixed that regression).
>
> The new xen patch is a partial revert in the sense that it changes the 32bit
> code back to how it was before and preserves the change on the 64bit code path.
>
> So as long as upstream does not decide that they want the patch that caused all
> those fallout (x86: Cleanup highmap after brk is concluded), then we are ok with
> the complete revert of the xen patch. But if they did, then the 64bit kernel
> would fail under Xen. If we re-apply the patch we reverted and add the partial
> revert, we would be ok in all cases.
>
> -Stefan
>

Egads! How about a pull request on top of master-next 
51baad9488da20194cd457f5d7e4c07e77b0d988 that show the changes you think 
are correct?

-- 
Tim Gardner tim.gardner at canonical.com