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

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

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