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

On 14.07.2011 17:45, Tim Gardner wrote:
> 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?
> 
The following changes since commit 51baad9488da20194cd457f5d7e4c07e77b0d988:

  Linux 2.6.32.43 (2011-07-14 06:45:33 -0600)

are available in the git repository at:
  git://kernel.ubuntu.com/smb/ubuntu-lucid.git master-next

Stefano Stabellini (2):
      xen: set max_pfn_mapped to the last pfn mapped
      xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"

 arch/x86/xen/mmu.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

On 07/14/2011 09:58 AM, Stefan Bader wrote:
> git://kernel.ubuntu.com/smb/ubuntu-lucid.git master-next

OK, applied with a bit of order swizzling so that 'Linux 2.6.32.43' is 
the last commit.