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");
IBM Linux Technology Center
On Wed, 2007-02-07 at 11:48 -0600, Jerone Young wrote:
> OK all is well...no fire here...move along. I figured out what happened.
> I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled
> through .. it is a bit surprising the Xen died though and not during
> loading of Dom0. So ultimately this is a USER error ;-)
> On Tue, 2007-02-06 at 17:58 -0600, Jerone Young wrote:
> > So cloning the Xen tree as of today .. you can no longer bootup Xen :-).
> > Here is the output on a JS21
> > The currently active flashside is: 1 (temporary)
> > Stopping BMC watchdog...
> > Trying to load: sync_console debug || root=/dev/sda3 debug from:
> > net ...
> > Bootloader 1.5
> > Reading MAC address from device: 00:14:5E:9C:1C:C5
> > Requesting IP address via BOOTP: 18.104.22.168
> > Requesting file "leaf4" via TFTP
> > Receiving data: ####A#######A|
> > TFTP: Received leaf4 (65359 KBytes)
> > Successfully loaded
> > ---------------------------------------------------
> > OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version
> > 4.1.0 (SUSE Linux)) Tue Feb 6 17:18:51 CST 2007
> > boot_of_init args: 0x0 0x0 0xe11027c 0xe28bed2 0x2a
> > boot msr: 0x1000000000003000
> > boot_of_init: _start 00000000004000d0 _end 00000000042b0310 0xe28bed2
> > boot_of_alloc_init: pg :0x2000 of our image is different
> > HANG
> > I'll be looking into this in the morning. But just an FYI to everybody.
> > _______________________________________________
> > Xen-ppc-devel mailing list
> > Xenfirstname.lastname@example.org
> > http://lists.xensource.com/xen-ppc-devel
> Xen-ppc-devel mailing list
Xen-ppc-devel mailing list