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
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= ip= 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)
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) 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

Reply via email to