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 07-14-2011, 12:51 PM
Tim Gardner
 
Default APPLIED: Linux 2.6.32.43+drm33.19

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810425
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:07 PM
Stefan Bader
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:11 PM
Tim Gardner
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:24 PM
Stefan Bader
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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...


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:35 PM
Stefan Bader
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:45 PM
Tim Gardner
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 03:58 PM
Stefan Bader
 
Default APPLIED: 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(-)


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 07-14-2011, 04:13 PM
Tim Gardner
 
Default APPLIED: Linux 2.6.32.43+drm33.19

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.


--
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 12:33 AM.

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