linux-next: manual merge of the xen tree with the tip tree

linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/include/asm/spinlock.h between a series of commits  from the tip
tree and a smaller series of similar commits from the xen tree.

I see that Linus is commenting on these patches at the moment, and its
not easy to resolve the conflicts, so I will just use the xen tree from
next-20110824 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> tree and a smaller series of similar commits from the xen tree.
>
> I see that Linus is commenting on these patches at the moment, and its
> not easy to resolve the conflicts, so I will just use the xen tree from
> next-20110824 for today.
>

Thanks Stephen; the xen tree ones are more current, and I want to make
sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[H. Peter Anvin]

On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/include/asm/spinlock.h between a series of commits from the tip
>> tree and a smaller series of similar commits from the xen tree.
>>
>> I see that Linus is commenting on these patches at the moment, and its
>> not easy to resolve the conflicts, so I will just use the xen tree from
>> next-20110824 for today.
>>
> 
> Thanks Stephen; the xen tree ones are more current, and I want to make
> sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> 

Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
should be dropped.

	-hpa

Kernel Warning

[Carsten Schiers]

Is that a Xen thing that anybody's interested in?

BR,
Carsten.

[    0.011657] ------------[ cut here ]------------
[    0.011734] WARNING: at arch/x86/xen/enlighten.c:729 
init_hw_perf_events+0x337/0x3d7()
[    0.011834] Hardware name: M56S-S3
[    0.011908] Modules linked in:
[    0.012000] Pid: 0, comm: swapper Not tainted 2.6.32.44-xen-amd64 #6
[    0.012000] Call Trace:
[    0.012000]  [<ffffffff8104d70f>] ? warn_slowpath_common+0x76/0x8c
[    0.012000]  [<ffffffff814e216e>] ? init_hw_perf_events+0x337/0x3d7
[    0.012000]  [<ffffffff814e1c7b>] ? identify_boot_cpu+0x15/0x3d
[    0.012000]  [<ffffffff814e1e12>] ? check_bugs+0x9/0x2e
[    0.012000]  [<ffffffff814dace3>] ? start_kernel+0x3cb/0x3e5
[    0.012000]  [<ffffffff814dcba9>] ? xen_start_kernel+0x5e1/0x5e7
[    0.012000] ---[ end trace a7919e7f17c0a725 ]---

Re: Kernel Warning

[Ian Campbell]

On Thu, 2011-08-25 at 20:31 +0100, Carsten Schiers wrote:
> Is that a Xen thing that anybody's interested in?

It's a harmless warning but it gets reported a lot and it taints the
kernel which causes some confusion is there is subsequently another
error. I proposed toning it down a bit a couple of days ago:
http://marc.info/?l=xen-devel&m=131400621622691

Ian.

> 
> BR,
> Carsten.
> 
> [    0.011657] ------------[ cut here ]------------
> [    0.011734] WARNING: at arch/x86/xen/enlighten.c:729 
> init_hw_perf_events+0x337/0x3d7()
> [    0.011834] Hardware name: M56S-S3
> [    0.011908] Modules linked in:
> [    0.012000] Pid: 0, comm: swapper Not tainted 2.6.32.44-xen-amd64 #6
> [    0.012000] Call Trace:
> [    0.012000]  [<ffffffff8104d70f>] ? warn_slowpath_common+0x76/0x8c
> [    0.012000]  [<ffffffff814e216e>] ? init_hw_perf_events+0x337/0x3d7
> [    0.012000]  [<ffffffff814e1c7b>] ? identify_boot_cpu+0x15/0x3d
> [    0.012000]  [<ffffffff814e1e12>] ? check_bugs+0x9/0x2e
> [    0.012000]  [<ffffffff814dace3>] ? start_kernel+0x3cb/0x3e5
> [    0.012000]  [<ffffffff814dcba9>] ? xen_start_kernel+0x5e1/0x5e7
> [    0.012000] ---[ end trace a7919e7f17c0a725 ]---
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Kernel Warning

[Jeremy Fitzhardinge]

On 08/25/2011 12:39 PM, Ian Campbell wrote:
> On Thu, 2011-08-25 at 20:31 +0100, Carsten Schiers wrote:
>> Is that a Xen thing that anybody's interested in?
> It's a harmless warning but it gets reported a lot and it taints the
> kernel which causes some confusion is there is subsequently another
> error. I proposed toning it down a bit a couple of days ago:
> http://marc.info/?l=xen-devel&m=131400621622691

I'd tend towards just silently eating APIC writes, unless we want to go
through and try to silence each one at the source.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Hi,

On Thu, 25 Aug 2011 11:26:37 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> > On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> >>
> >> Today's linux-next merge of the xen tree got a conflict in
> >> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> >> tree and a smaller series of similar commits from the xen tree.
> >>
> >> I see that Linus is commenting on these patches at the moment, and its
> >> not easy to resolve the conflicts, so I will just use the xen tree from
> >> next-20110824 for today.
> >>
> > 
> > Thanks Stephen; the xen tree ones are more current, and I want to make
> > sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> > 
> 
> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> should be dropped.

That's a bit tricky as I get a rolled up tip tree.  The best I could do
is revert the commit that merges the x86/spinlocks branch into
auto-latest ...  I'll do that for today (unless something happens to the
tip tree in the next hour).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[H. Peter Anvin]

On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>
>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>> should be dropped.
> 
> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> is revert the commit that merges the x86/spinlocks branch into
> auto-latest ...  I'll do that for today (unless something happens to the
> tip tree in the next hour).
> 

OK, let me bother Ingo about it.

	-hpa

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>
> >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >> should be dropped.
> > 
> > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > is revert the commit that merges the x86/spinlocks branch into
> > auto-latest ...  I'll do that for today (unless something happens to the
> > tip tree in the next hour).
> > 
> 
> OK, let me bother Ingo about it.

For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Hi,

On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > >>
> > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > >> should be dropped.
> > > 
> > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > is revert the commit that merges the x86/spinlocks branch into
> > > auto-latest ...  I'll do that for today (unless something happens to the
> > > tip tree in the next hour).
> > > 
> > 
> > OK, let me bother Ingo about it.
> 
> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> tip tree.

I am still doing this in each linux-next, and it doesn't appear to have
been fixed up the the tree on tesla.tglx.de, yet, I think.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Thomas Gleixner]

On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> Hi,
> 
> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> > >
> > > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > > >>
> > > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > > >> should be dropped.
> > > > 
> > > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > > is revert the commit that merges the x86/spinlocks branch into
> > > > auto-latest ...  I'll do that for today (unless something happens to the
> > > > tip tree in the next hour).
> > > > 
> > > 
> > > OK, let me bother Ingo about it.
> > 
> > For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> > tip tree.
> 
> I am still doing this in each linux-next, and it doesn't appear to have
> been fixed up the the tree on tesla.tglx.de, yet, I think.

We'll take it out. Thanks,

      tglx

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>> Hi,
>>
>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>> should be dropped.
>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>> tip tree in the next hour).
>>>>>
>>>> OK, let me bother Ingo about it.
>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>> tip tree.
>> I am still doing this in each linux-next, and it doesn't appear to have
>> been fixed up the the tree on tesla.tglx.de, yet, I think.
> We'll take it out. 

Actually, the tip x86/spinlocks was the most up-to-date version of those
patches (since hpa had rebased them to a more recent version of mainline).

But never mind.  Stephen, could you use

    git://github.com/jsgf/linux-xen.git upstream/xen

for linux-next instead of the kernel.org xen.git, and I've re-added the
up-to-date spinlock changes there.

Thanks,
    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Thomas Gleixner]

On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:

> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >> Hi,
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).

Mooo. You tell that after we did a nasty rebase from hell :(
 
Thanks,

	tglx

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 01:56 PM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:
>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>> Hi,
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out. 
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
> Mooo. You tell that after we did a nasty rebase from hell :(

I'd been meaning to take it out of my tree to solve Stephen's problem,
but, well, kernel.org.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

Hi Jeremy,

On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).
> 
> But never mind.  Stephen, could you use
> 
>     git://github.com/jsgf/linux-xen.git upstream/xen
> 
> for linux-next instead of the kernel.org xen.git, and I've re-added the
> up-to-date spinlock changes there.

OK, I have switched to this from today.

My understanding is this:  I do *not* need to revert the spinlock changes
from tip anymore, correct?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 05:32 PM, Stephen Rothwell wrote:
> Hi Jeremy,
>
> On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge
<jeremy@goop.org> wrote:
>>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com>
wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree. The best I
could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ... I'll do that for today (unless something happens
to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out.
>>
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
>>
>> But never mind. Stephen, could you use
>>
>> git://github.com/jsgf/linux-xen.git upstream/xen
>>
>> for linux-next instead of the kernel.org xen.git, and I've re-added the
>> up-to-date spinlock changes there.
>
> OK, I have switched to this from today.
>
> My understanding is this: I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right.  tglx has removed these changes from tip.git (even though they
were OK), and I've reinstated the proper versions in my tree.  The
xen.git on git.kernel.org still has old versions, but I'll sort that out
once it's back online.  I expect it will ultimately go upstream via
tip.git, but we can work that out later too.

Thanks,
    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Hi all,

On Wed, 14 Sep 2011 10:32:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> My understanding is this:  I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right, having looked at the tip tree, they are not in there any more.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/mm/init_32.c between commit
1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
add_highpages honor early reserved ranges") from the tip tree and commit
07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
high memory") from the xen tree.

I have no idea how to fix this up, sorry, so I have used the xen tree
from next-20101021 for today.

There were also conflicts in:
	arch/x86/xen/mmu.c
	include/linux/early_res.h
	kernel/early_res.c

These last two were deleted in the tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

Hi Jeremy,

On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.
> 
> I have no idea how to fix this up, sorry, so I have used the xen tree
> from next-20101021 for today.

It occurred to me that the conflicts might be useful to you, so here they
are:

diff --cc arch/x86/mm/init_32.c
index 5d0a671,573bc7f..0000000
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@@ -423,28 -422,71 +423,78 @@@ static void __init add_one_highpage_ini
  	totalhigh_pages++;
  }
  
 -struct add_highpages_data {
 -	unsigned long start_pfn;
 -	unsigned long end_pfn;
 -};
 -
 -static int __init add_highpages_work_fn(unsigned long start_pfn,
 -					 unsigned long end_pfn, void *datax)
 +void __init add_highpages_with_active_regions(int nid,
 +			 unsigned long start_pfn, unsigned long end_pfn)
  {
++<<<<<<< HEAD
 +	struct range *range;
 +	int nr_range;
 +	int i;
 +
 +	nr_range = __get_free_all_memory_range(&range, nid, start_pfn, end_pfn);
++=======
+ 	int node_pfn;
+ 	struct page *page;
+ 	phys_addr_t chunk_end, chunk_max;
+ 	unsigned long final_start_pfn, final_end_pfn;
+ 	struct add_highpages_data *data = (struct add_highpages_data *)datax;
++>>>>>>> xen
  
 -	final_start_pfn = max(start_pfn, data->start_pfn);
 -	final_end_pfn = min(end_pfn, data->end_pfn);
 -	if (final_start_pfn >= final_end_pfn)
 -		return 0;
 +	for (i = 0; i < nr_range; i++) {
 +		struct page *page;
 +		int node_pfn;
  
++<<<<<<< HEAD
 +		for (node_pfn = range[i].start; node_pfn < range[i].end;
 +		     node_pfn++) {
++=======
+ 	chunk_end = PFN_PHYS(final_start_pfn);
+ 	chunk_max = PFN_PHYS(final_end_pfn);
+ 
+ 	/*
+ 	 * Check for reserved areas.
+ 	 */
+ 	for (;;) {
+ 		phys_addr_t chunk_start;
+ 		chunk_start = early_res_next_free(chunk_end);
+ 		
+ 		/*
+ 		 * Reserved area. Just count high mem pages.
+ 		 */
+ 		for (node_pfn = PFN_DOWN(chunk_end);
+ 		     node_pfn < PFN_DOWN(chunk_start); node_pfn++) {
+ 			if (pfn_valid(node_pfn))
+ 				totalhigh_pages++;
+ 		}
+ 
+ 		if (chunk_start >= chunk_max)
+ 			break;
+ 
+ 		chunk_end = early_res_next_reserved(chunk_start, chunk_max);
+ 		for (node_pfn = PFN_DOWN(chunk_start);
+ 		     node_pfn < PFN_DOWN(chunk_end); node_pfn++) {
++>>>>>>> xen
  			if (!pfn_valid(node_pfn))
  				continue;
  			page = pfn_to_page(node_pfn);
  			add_one_highpage_init(page);
  		}
  	}
 -
 -	return 0;
 -
  }
++<<<<<<< HEAD
++=======
+ 
+ void __init add_highpages_with_active_regions(int nid, unsigned long start_pfn,
+ 					      unsigned long end_pfn)
+ {
+ 	struct add_highpages_data data;
+ 
+ 	data.start_pfn = start_pfn;
+ 	data.end_pfn = end_pfn;
+ 	work_with_active_regions(nid, add_highpages_work_fn, &data);
+ }
+ 
++>>>>>>> xen
  #else
  static inline void permanent_kmaps_init(pgd_t *pgd_base)
  {
diff --cc arch/x86/xen/mmu.c
index f72d18c,930986d..0000000
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@@ -56,7 -55,7 +56,11 @@@
  #include <asm/e820.h>
  #include <asm/linkage.h>
  #include <asm/page.h>
++<<<<<<< HEAD
 +#include <asm/init.h>
++=======
+ #include <asm/pat.h>
++>>>>>>> xen
  
  #include <asm/xen/hypercall.h>
  #include <asm/xen/hypervisor.h>
* Unmerged path include/linux/early_res.h
* Unmerged path kernel/early_res.c

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: manual merge of the xen tree with the tip tree

[Yinghai Lu]

On 10/21/2010 08:36 PM, Stephen Rothwell wrote:
> Hi Jeremy,
> 
> On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
>>
>> I have no idea how to fix this up, sorry, so I have used the xen tree
>> from next-20101021 for today.
> 

x86-32, memblock: Make add_highpages honor early reserved ranges

is updated version with memblock for

x86/32: honor reservations of high memory

Assume Jeremy would update the xen tree.

Thanks

	Yinghai

Re: linux-next: manual merge of the xen tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.

Jeremy,

Commit 07147a06ac is all over the x86 tree:

  arch/x86/mm/init_32.c     |   42 ++++++++++++++++++++++++++++++++----------
  include/linux/early_res.h |    3 +++
  kernel/early_res.c        |   30 ++++++++++++++++++++++++++++++
  3 files changed, 65 insertions(+), 10 deletions(-)

... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It 
was not even posted to lkml! Nor does the commit title suggest that it affects core 
kernel code as well.

Also, the AuthorDate field is a total lie:

  commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
  Author:     Gianluca Guida <gianluca.guida@citrix.com>
  AuthorDate: Sun Aug 2 01:25:48 2009 +0100
  Commit:     Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
  CommitDate: Mon Oct 4 14:22:11 2010 -0700

    x86/32: honor reservations of high memory

This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified 
by half of this commit, was _CREATED_ in February 2010 ...

I realize that some original patch, much different from this one, was probably 
written in 2009, and that via a series of undocumented rebases and modifications to 
the patch you achieved this state.

Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you 
do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from 
linux-next and be done via the x86 tree again.

	Ingo

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

 On 10/22/2010 01:01 AM, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
> Jeremy,
>
> Commit 07147a06ac is all over the x86 tree:
>
>   arch/x86/mm/init_32.c     |   42 ++++++++++++++++++++++++++++++++----------
>   include/linux/early_res.h |    3 +++
>   kernel/early_res.c        |   30 ++++++++++++++++++++++++++++++
>   3 files changed, 65 insertions(+), 10 deletions(-)
>
> ... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It 
> was not even posted to lkml! Nor does the commit title suggest that it affects core 
> kernel code as well.
>
> Also, the AuthorDate field is a total lie:
>
>   commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
>   Author:     Gianluca Guida <gianluca.guida@citrix.com>
>   AuthorDate: Sun Aug 2 01:25:48 2009 +0100
>   Commit:     Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>   CommitDate: Mon Oct 4 14:22:11 2010 -0700
>
>     x86/32: honor reservations of high memory
>
> This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified 
> by half of this commit, was _CREATED_ in February 2010 ...

Most of the code in early_res.c was simply moved from
arch/x86/.../e820.c, so the patch chunks were applied to the new file
when the code was moved.

> I realize that some original patch, much different from this one, was probably 
> written in 2009, and that via a series of undocumented rebases and modifications to 
> the patch you achieved this state.

The modified code was almost entirely unchanged over that period, so the
datestamp and original authorship of the patch was basically correct.

However...

> Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you 
> do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from 
> linux-next and be done via the x86 tree again.

Hey, hey, hold your horses.  This is a wildly obsolete patch that we
were discussing a few weeks ago, but Yinghai did a proper alternative
for the memblock universe.

It was never in linux-next, and never intended to be.  I'm not sure why
it has appeared in linux-next now; it isn't in my branch.  I wonder if
it appeared in another Xen-related branch.  Let me investigate.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

 On 10/21/2010 08:03 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.

Hm, that change has been completely obsoleted by the memblock stuff from
tip.  Oh, I see.  Another change which ended up reverting that patch via
a merge got dropped, so it got left lying around.  I'll pull it out.

(Not sure why it merges cleanly for me however; I guess because you've
already got the older xen branch in there which contains the merge.)

Anyway, update pushed.

    J