WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Fri, 11 Feb 2011 14:10:23 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Fri, 11 Feb 2011 14:12:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1102111449530.2826@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <987664A83D2D224EAE907B061CE93D530194305BEA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110125201008.GA18756@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D53019434A43C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110126161400.GA3515@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D53019434A8F7@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110126212850.GB3578@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D53019438ECB3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101271156310.7277@kaball-desktop> <987664A83D2D224EAE907B061CE93D53019438F211@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110128152843.GB29440@xxxxxxxxxxxx> <20110128154754.GA24075@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D53019D2308A0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D54A547.9060201@xxxxxxxx> <alpine.DEB.2.00.1102111449530.2826@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvJ+yj1rcHhn0C6R426Ue5zL5xcZgAPILmA
Thread-topic: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure
I switched to next-2.6.37 branch in Jeremy's tree which has 
memblock_x86_reserve_range() function.

The boot failure still occurs.  RIP points to the BUG() call in 
arch/x86/xen/mm.c/pin_pagetable_pfn().

Any suggestions?

Allen

-----Original Message-----
From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx] 
Sent: Friday, February 11, 2011 6:51 AM
To: Jeremy Fitzhardinge
Cc: Kay, Allen M; Konrad Rzeszutek Wilk; Stefano Stabellini; xen-devel; Keir 
Fraser
Subject: Re: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure

On Fri, 11 Feb 2011, Jeremy Fitzhardinge wrote:
> On 02/10/2011 05:03 PM, Kay, Allen M wrote:
> > Konrad/Stefano,
> >
> > Getting back to the xen/dom0 boot failure on my Sandybridge SDP I reported 
> > a few weeks ago.
> >
> > I finally got around to narrow down the problem the call to 
> > xen_add_extra_mem() in arch/x86/xen/setup.c/xen_memory_setup().  This call 
> > increase the top of E820 memory in dom0 beyond what is actually available.
> >
> > Before xen_add_extra_mem() is called, the last entry of dom0 e820 table is:
> >
> >     0000000100000000 - 000000016b45a000 (usable)
> >
> > After xen_add_extra_mem() is called, the last entry of dom0 e820 table 
> > becomes:
> >
> >     0000000100000000 - 000000023a6f4000 (usable)
> >
> > This pushes the top of RAM beyond what was reported by Xen's e820 table, 
> > which is:
> >
> > (XEN)  0000000100000000 - 00000001de600000 (usable)
> >
> > AFAICT, the failure is caused by dom0 accessing non-existent physical 
> > memory.  The failure went away after I removed the call to 
> > xen_add_extra_mem().
> 
> That "extra memory" stuff is reserving some physical address space for
> ballooning.  It should be completely unused (and unbacked by any pages)
> until the balloon driver populates it; it is reserved memory in the
> meantime.
> 
> How is that memory getting referenced in your case?
> 

In particular it would be very interesting to know what the RIP of the
crash resolves to.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel