[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.