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-ppc-devel

Re: [XenPPC] boot failure with large dom0

To: jyoung5@xxxxxxxxxx
Subject: Re: [XenPPC] boot failure with large dom0
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Wed, 07 Feb 2007 16:38:36 -0600
Cc: xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 07 Feb 2007 14:38:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1170886818.3172.23.camel@thinkpad>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <1170806294.12947.1.camel@thinkpad> <1170870524.3172.7.camel@thinkpad> <1170871159.28013.4.camel@basalt> <1170886818.3172.23.camel@thinkpad>
Reply-to: Hollis Blanchard <hollisb@xxxxxxxxxx>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message happens
way before that point.

The early boot code only tracks the first 32M of memory, and I believe
that is the problem here: we're overflowing the bitmap we're using to
track memory. Page 2000 is address 2000000 (32MB). Try this patch:

diff -r 20e5f508accc xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.c        Tue Feb 06 13:42:19 2007 -0600
+++ b/xen/arch/powerpc/boot_of.c        Wed Feb 07 16:38:24 2007 -0600
@@ -394,6 +394,9 @@ static void boot_of_alloc_init(int m, ui
     u64 start;
     u64 size;
 
+    if (((ulong)_end >> PAGE_SHIFT) >= MEM_AVAILABLE_PAGES)
+        of_panic("image is too big");
+
     rc = of_getprop(m, "available", a, sizeof (a));
     if (rc > 0) {
         int l =  rc / sizeof(a[0]);

-- 
Hollis Blanchard
IBM Linux Technology Center

On Wed, 2007-02-07 at 16:20 -0600, Jerone Young wrote:
> So it looks like the problem has to do with tftp which apears to have a
> 64MB send limit. The file is over this and so everything does not make
> it. Adding a check for dom0 image size does not good since the image
> itself is not fully transfered. Which make since why you get the error:
> boot_of_alloc_init: pg :0x2000 of our image is different
> at bootup.
> 
> On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote:
> > I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with
> > full debug symbols is 55MB here, which probably explains this problem.
> > 
> > Could you see how easy it would be to catch this problem at runtime and
> > have a nice panic? Checking dom0_len in __start_xen() would probably do
> > the trick, maybe something like:
> >         if (dom0_start + dom0_len > (32<<20))
> >                 panic("dom0 is too big");
> > 
> 
> 
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ppc-devel


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