| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Mark F Mergen wrote:
The problem state Linux on Xen-PPC has been mostly running for about a
week, but with some instability due to loose ends in pte flush. This
area of Linux has changed significantly since the version used for the
prototype based on Rhype, so it's taken a few days to find the right
place in Linux to modify. I've generalized the noHV pte insert code
in Xen as part of this.
As I predicted in my last note to this list, we've reached the end of
progress on simulator. Everything I know how to run on the simple
ramdisk system runs and seems stable. Further progress requires
integration with Maria's bringup base on Apple G5 hardware, which was
set aside for other priorities.
As usual, patches for Xen and Linux are available for interested
parties. For those with access to my source tree
/a/kix/homes/kix/mergen/xen, the Xen patch is in xen-nohv/xen-nohv and
the Linux patch is in linux/linux-2.6.prlp/linux-prlp. You also need
the two new Xen files arch/powerpc/powerpc64/nohv.c and
include/asm-powerpc/nohv.h. These mods work against Xen and Linux
trees from xensource at the time of this note.
Mark Mergen
------------------------------------------------------------------------
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
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
|
|
|
| |
|
Home