I agree that you are a long way from getting to the dom0 code.  The last messages you got are about building the OF info to pass to the dom0 code.  I don't think enabling DEBUG in prom_init will help, because that's in Linux and you are stiill in Xen, light-years from getting to prom_init.  I would find where the last message you got is produced and where the next message you anticipate (in my runs on Mambo it is: (XEN) loading OFH: 0x6000000, RMA: 0x2000000, but you can verify from your run without the nohv parameter) is produced, then put in prints or set breakpoints on the path between these two to narrow down where/what is failing.




Maria Butrico <[EMAIL PROTECTED]>

07/26/2006 01:27 PM

Please respond to
[EMAIL PROTECTED]

To
Mark F Mergen/Watson/[EMAIL PROTECTED]
cc
xen-ppc-devel@lists.xensource.com
Subject
Re: [XenPPC] noHV status






I am testing Mark's changes on hardware, switching between a js20 and a
js21, depending on availability.

On the js20, after changing the xen link address, that Mark needed for
mambo, I was able to boot with a remote filesystem (I should point out
that I have never tried to boot with the local file system yet).   These
were my dom0 boot arguments:

command line: console=ttyS1,19200 ro root=/dev/nfs
nfsroot=9.2.208.86:/home/kitchawa/linux.img/ppc64nfs-2005-06-18
ip=9.2.129.5::9.2.129.2:255.255.255.0:kpblade4:eth1:off
init=/sbin/quickinit noshell

The most annoying thing was the printk on h_enter (about PTEG being full).

Mark you said that you are not using this logic, and this is why I left
the printk in the code (this printk is Most Annoying when starting dom0
linux.).  This was a boot without the 'nohv' boot parameter, so maybe
you want to change that statement to say that only when xen is operating
in the nohv mode this code in h_enter is not used. Otherwise this is a
bug.

After mounting the file system and printing about PTEG (what seemed like
a million times), these were the last console messages

Starting automounter: loading autofs4 kernel module,modprobe: Can't open
dependencies file /lib/modules/2.6.17-Xen/modules.dep (No such file or
directory)
done.
Starting OpenBSD Secure Shell server: sshd.

Then the machine reverted to hil.   Thank you, Amos, for the automated
reflasher.  I have already used it at least 2 times.    This does not
per se mean much since the machine reverts to hil on its own without
much cause.

I do not think it came up quite all the way, but we know from previous
experiments that in this machine and with this root file system we are
on the border of having dom0 running out of memory.  I would expect the
dom0 kernel to give quite a few error messages about the out of memory
condition.  The hil reversion might indicate a more serious problem.   I
would like to redo this on a js21.

With the nohv boot parameter, I did not get very far.  These were the
last lines from the console

(XEN) Scrubbing Free RAM: ...........done.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) xen_start_info: 0000000007ffe000
(XEN) shared_info: 0x3fff000,00000

So in fact I do not think we get to dom0 at all.  Suggestions about
which debug bells to enable?  DEBUG in prom_init?  others?



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

Reply via email to