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 200 (32MB). Try this patch:
diff -r 20e5f508accc xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Feb 06 13:42:19 2007 -0600
+++ b/xen/arch/powerpc/boot_of.cWed 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 (3220))
panic(dom0 is too big);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
