Re: [XenPPC] noHV status

[Mark F Mergen <mergen@xxxxxxxxxx>]

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 <butrico@xxxxxxxxxxxxx>

07/26/2006 01:27 PM

Please respond to
butrico@xxxxxxxxxxxxxx

To	Mark F Mergen/Watson/IBM@IBMUS
cc	xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel