[XenPPC] [PATCH] fix prose builder

2007-01-16 Thread Maria Butrico 
Summary:  fix for the prose builder.

Minor fixed for the prose builder.

Signed-off-by: Maria Butrico <[EMAIL PROTECTED]>


diff -r 5568efb41da4 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Mon Jan 15 13:27:20 2007 -0500
+++ b/tools/python/xen/lowlevel/xc/xc.c Tue Jan 16 18:41:02 2007 -0500
@@ -953,7 +953,7 @@ static PyObject *pyxc_prose_build(XcObje
 void *arch_args = NULL;
 int unused;
 
-static char *kwd_list[] = { "dom", "store_evtchn",
+static char *kwd_list[] = { "dom", "store_evtchn", "memsize",
 "console_evtchn", "image",
 /* optional */
 "ramdisk", "cmdline", "flags",
diff -r 5568efb41da4 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pyMon Jan 15 13:27:20 2007 -0500
+++ b/tools/python/xen/xend/image.pyTue Jan 16 18:01:19 2007 -0500
@@ -260,13 +260,9 @@ class PPC_LinuxImageHandler(LinuxImageHa
 return max(maxmem_kb / 64, shadow_mem_kb)
 
 
-class PPC_ProseImageHandler(LinuxImageHandler):
+class PPC_ProseImageHandler(PPC_LinuxImageHandler):
 
 ostype = "prose"
-
-def configure(self, imageConfig, deviceConfig):
-LinuxImageHandler.configure(self, imageConfig, deviceConfig)
-self.imageConfig = imageConfig
 
 def buildDomain(self):
 store_evtchn = self.vm.getStorePort()

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

Re: [XenPPC] Re: shutdown/destroy domU problem

2006-12-12 Thread Maria Butrico 
I just remembered a fact perhaps relevant to this.   At some point in 
the past I applied a patch to the linux tree we ('we' is the community 
that is reporting this problem) use on xen which was forwarded to me by 
Jimi.  The patch  subject is:   "[RFC/PATCH] Maple: Use RTAS power off 
methods if available".I applied this patch to make reboot possible.  
At the time, Nov 7th, I tested this change and (I am going by memory 
now) and I recall that it worked. 

When I regenerated the linux tree, after all the changes made to the 
base, I also tested, but I have _not_ been able to reboot.  This seemed 
not too important at the time so I did not chase it.   So I believe that 
the issue with xm shutdown reduces to why are we not able to reboot.
Once more, if you let a bug go by, it becomes a monster.


On the subject of xm destroy, the domU libos is destroyed often, without 
any trouble.  I will try to verify that we can do this more than once 
with domU linux.   Sorry that this is taking so long, but with all the 
machine shuffles I lost agility in rebooting  a particular image. 


Doron Shiloach wrote:


Hi Jimi,

>> Please try executing "/sbin/poweroff" manually on the DomU and see 
if that works.


(none):/ # /sbin/poweroff
WARNING: could not determine runlevel - doing soft poweroff
  (it's better to use shutdown instead of poweroff from the command line)
shutdown: /dev/initctl: No such file or directory
init: /dev/initctl: No such file or directory

I am using a custom init script with this domU, which from what you 
wrote previously, seems to not be creating a "real" init process, 
preventing the xm shutdown from working.
What do you mean by a "real" init process?  Is it possible for me to 
define init and still be able to use the shutdown command?  

As for the xm destroy, I mean that I can use the command once 
(usually) , and it works, removing that domU.
However, when I try to use it on a second domU, the machine freezes. 
 From what I understand, it is preferable to use the "shutdown" 
command, so this is a secondary issue, for me at least..  
Thanks,



Doron Shiloach
Tieline: 862-3110
Phone: (914) 945-3110


*Jimi Xenidis/Watson/IBM*

12/07/2006 04:18 PM


To
Doron Shiloach/Watson/[EMAIL PROTECTED]
cc
	David M Daly/Watson/[EMAIL PROTECTED], Dilma M Da silva/Watson/[EMAIL PROTECTED], 
Maged Michael/Watson/[EMAIL PROTECTED]

Subject
	Re: shutdown/destroy domU problemLink 
 










Doron,
First, these are awesome questions for the mailing list  and I wish 
you would use it, I've asked for this time and time again.
Second, when you say "xm shutdown" this sends a message to the DomU to 
execute the program "/sbin/poweroff", if this command does not work 
then you will never shut down.  Please try executing "/sbin/poweroff" 
manually on the DomU and see if that works.  For example, if I try on 
one of our NFSROOT images with "init=/bin/sh" the following happens:

9:/# /sbin/poweroff
Broadcast message from root (console) (Wed Dec 31 19:02:07 1969):
The system is going down for system halt NOW!
shutdown: timeout opening/writing control channel /dev/initctl
init: timeout opening/writing control channel /dev/initctl
9:/#
and the DomU does not shut down because there is no "real" init 
process to create the /dev/intctl pipe, this is why I cannot "xm 
shutdown" this domain.
If I boot the same thing but this time I do not define "init" but add 
" S " to the kernel parameters, init runs (but places be in single 
user mode) and now /sbin/poweroff runs if I run it manually or if I 
run it from XM.


Third, I have _never_ had a problem with "xm destroy" and it works 
instantly for me and I _hate_ saying "for me".

What do you mean "but using it a second time"?
The system freezing usually indicates that a DomU has panic()ed, this 
is currently an ourstanding bug in XenPPC but is usually only seen on 
UP versions.  It would be news to me to see this on an SMP system.



thank you
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel

-JX
 



*Doron Shiloach/Watson/IBM*

12/07/06 11:55 AM


To
Jimi Xenidis/Watson/[EMAIL PROTECTED]
cc
	Dilma M Da silva/Watson/[EMAIL PROTECTED], David M Daly/Watson/[EMAIL PROTECTED], 
Maged Michael/Watson/[EMAIL PROTECTED]

Subject
shutdown/destroy domU problem








Hi Jimi,

I'm having problems with the shutdown/destroy domU functionality with 
the latest version of Xen that David released.

Here are the versions for Xen (top) and Linux (bottom) that we are using.

cso85:~/xen-maria-12-4/xen-ppc # hg tip
changeset: 13183:0e85b389980a
tag: tip
user: Jimi Xenidis <[EMAIL PROTECTED]>
date: Fri Dec 01 19:11:02 2006 -0500
summary: [XEN][POWERPC] should comment the Power Managment workaround 
in the code as well


so85:~/xen-maria-12-4/linux/linux-xen-ppc # hg tip
changeset: 33309:f0981398b745
tag: tip
user: [EMAIL PROTECTED]
date: Mon Nov 27 13:10:34 2006 -0500
summary: Applied LTT patch

In short, the shutdo

[XenPPC] xend and routes

2006-12-06 Thread Maria Butrico 
We have several JS21, all with two ethernet interfaces, both interfaces 
in use.For example this is what things look like when we boot one 
such blade with the latest xen and linux for xen and before starting xend.


cso89:~ # ifconfig
ifconfig
eth0  Link encap:Ethernet  HWaddr 00:11:25:C9:4D:5A 
 inet addr:192.168.4.9  Bcast:192.168.255.255  Mask:255.255.0.0

 UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:15436 errors:0 dropped:0 overruns:0 frame:0
 TX packets:679 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1084295 (1.0 Mb)  TX bytes:62108 (60.6 Kb)
 Interrupt:17

eth1  Link encap:Ethernet  HWaddr 00:11:25:C9:4D:5B 
 inet addr:9.2.78.89  Bcast:9.2.78.255  Mask:255.255.255.0

 UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:14899 errors:0 dropped:0 overruns:0 frame:0
 TX packets:1514 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1076900 (1.0 Mb)  TX bytes:171946 (167.9 Kb)
 Interrupt:18

loLink encap:Local Loopback 
 inet addr:127.0.0.1  Mask:255.0.0.0

 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:22 errors:0 dropped:0 overruns:0 frame:0
 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:1480 (1.4 Kb)  TX bytes:1480 (1.4 Kb)



This is what the routing tables look like.

cso89:~ # netstat -rn
netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt 
Iface
9.2.78.00.0.0.0 255.255.255.0   U 0 0  0 
eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0  0 
eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0  0 
eth0

127.0.0.0   0.0.0.0 255.0.0.0   U 0 0  0 lo
0.0.0.0 9.2.78.10.0.0.0 UG0 0  0 
eth1



Notice that the machine name, cso89 corresponds to ip address 9.2.78.89 
and is on eth1.   Notice also that there is a default route from the 
machine, the last one, in the table above.  After we start xend this is 
the network interface table.


cso89:~ # ifconfig
ifconfig
eth0  Link encap:Ethernet  HWaddr 00:11:25:C9:4D:5A 
 inet addr:192.168.4.9  Bcast:192.168.255.255  Mask:255.255.0.0

 UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:18 errors:0 dropped:0 overruns:0 frame:0
 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:1333 (1.3 Kb)  TX bytes:650 (650.0 b)

eth1  Link encap:Ethernet  HWaddr 00:11:25:C9:4D:5B 
 inet addr:9.2.78.89  Bcast:9.2.78.255  Mask:255.255.255.0

 UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:15102 errors:0 dropped:0 overruns:0 frame:0
 TX packets:1605 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1090820 (1.0 Mb)  TX bytes:190036 (185.5 Kb)
 Interrupt:18

loLink encap:Local Loopback 
 inet addr:127.0.0.1  Mask:255.0.0.0

 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:22 errors:0 dropped:0 overruns:0 frame:0
 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:1480 (1.4 Kb)  TX bytes:1480 (1.4 Kb)

peth0 Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF 
 UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1

 RX packets:19 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1541 (1.5 Kb)  TX bytes:748 (748.0 b)
 Interrupt:17

vif0.1Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF 
 UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1

 RX packets:2 errors:0 dropped:0 overruns:0 frame:0
 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:650 (650.0 b)  TX bytes:1333 (1.3 Kb)

xenbr1Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF 
 UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1

 RX packets:19 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:1348 (1.3 Kb)  TX bytes:0 (0.0 b)

This is as expected.  However notice what happened to our routing tables.

cso89:~ # netstat -rn
netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt 
Iface
9.2.78.10.0.0.0 255.255.255.255 UH0 0  0 
eth0
9.2.78.00.0.0.0 255.255.255.0   U 0 0  0 
eth1
169.254.0.0 0.0.0.0 255.255.0.0 U

Re: [XenPPC] Crash on js12

2006-11-27 Thread Maria Butrico 
This problem is solved on the latest version of Xen.  I would encourage 
Tony, who is running tests, to test all forms of xen, debug and not (I 
am assuming that he uses an automated procedure, so is just a matter of 
setting it up to go twice). 


Maria Butrico wrote:
I seem to be the only person with this problem.  On a js21 with 8G of 
memory, tip as of about 1 hour ago.  (The machine can run xen of a 
couple of weeks ago).I have not tried on any other machine.
OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 
4.1.1 ()) Mon Nov 20 15:44:04 EST 2006

boot_of_init args: 0x0 0x0 0x111027c 0x1275532 0x0
boot msr: 0x10003000
boot_of_init: _start 0040 _end 00493c78 0x1275532
boot_of_probemem: memory 0x[0x8000]
boot_of_probemem: memory 0x0001[0x18000]
bootargs = xen dom0_mem=2G  -- console=xencons xencons=xvc0 
ip=9.2.78.99::9.2.78.1:255.255.255.0:cso99:eth1:off  ro root=/dev/nfs 
nfsroot=9.2.208.204:/home/apw/devel/nfsroots/sles10-rootfs-2006-10-30 
init=/sbin/quickinit noshell 
quick=/homes/kix/butrico/libos/quickcfg-xen-ppc.sh

boot_of_module: FYI Dom0 is unknown, will be caught later
boot_of_module: dom0 mod @ 0x00493c78[0x493c78]
boot_of_module: dom0 mod string: console=xencons xencons=xvc0 
ip=9.2.78.99::9.2.78.1:255.255.255.0:cso99:eth1:off  ro root=/dev/nfs 
nfsroot=9.2.208.204:/home/apw/devel/nfsroots/sles10-rootfs-2006-10-30 
init=/sbin/quickinit noshell 
quick=/homes/kix/butrico/libos/quickcfg-xen-ppc.sh
find_space base=0x00493c78  eomem=0x8000  
size=0x8000  align=0x1000
find_space base=0x0049c000  eomem=0x8000  
size=0x0003  align=0x1000

creating oftree
pkg_save: saved device tree in 0x41c8 bytes
boot_of_devtree: devtree mod @ 0x0049c000[0x4cc000]
OF: timebase-frequency = 14318378 Hz
OF: clock-frequency = 250 KHz
ping = 0x: ping = 0x: ping = 0x:
NOT FOUND


get-property for device_type on zero phandle


HANG



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




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

Re: [XenPPC] Crash with ssh

2006-11-27 Thread Maria Butrico 
Jimi, where did you get the idea that this linux was SMP.  I recall that 
we build Linux for SMP even though we run it UP if we boot it on a xen 
partition.Maybe you see something I missed. 


Jimi Xenidis wrote:
Thanks for clarifying this Dilma, there is no Xen present if the Linux 
is SMP :)

-JX
On Nov 27, 2006, at 10:25 AM, Dilma DaSilva wrote:



This is not a xen problem. I believe it's a gpfs problem on the
shutdown/umount path. We're using gpfs with a kernel version that it
doesn't support yet and I have fixed problems related to clear_inode
before (Linux has changed some interfaces in the vfs layer on 2.6.17).

Dilma


David M Daly writes:

I got the following error this morning from the console on one of our
JS21s. I had a program that was supposed to ssh into the blade and 
reboot
it after shutting down GPFS. I don't think it did any of the gpfs 
shutdown
before crashing. Here is the error message. I saw it because I 
happened to

be on the SOL console ( I wouldn't normally be). This is the first time
I'm noticing this. I will post again if I see more errors of this kind.

cso85:/ # cpu 0x2: Vector: 700 (Program Check) at [c0017b5a7340]
pc: c00f62bc: .clear_inode+0x3c/0x120
lr: c00f62b4: .clear_inode+0x34/0x120
sp: c0017b5a75c0
   msr: 90029032
  current = 0xc0002facc540
  paca= 0xc05ae600
pid   = 17947, comm = umount
kernel BUG in clear_inode at
/root/xen-maria-latest/linux/linux-xen-ppc/fs/inode.c:251!
enter ? for help
2:mon>
2:mon>

This is built from Maria's tree on 11-9.

David Daly
Research Staff Member
32-003 IBM T.J. Watson Research Center
Yorktown Heights, NY, 10958
(914) 945-1845, T/L 862-1845
I got the following error this 
morning

from the console on one of our JS21s. I had a program that was supposed
to ssh into the blade and reboot it after shutting down GPFS. I 
don't think
it did any of the gpfs shutdown before crashing. Here is the error 
message.
I saw it because I happened to be on the SOL console ( I wouldn't 
normally
be). This is the first time I'm noticing this. I will post again if 
I see

more errors of this kind. 

cso85:/ # cpu 0x2: Vector: 700 
(Program

Check) at [c0017b5a7340]
    pc: c00f62bc:
.clear_inode+0x3c/0x120
    lr: c00f62b4:
.clear_inode+0x34/0x120
    sp: 
c0017b5a75c0
   msr: 
90029032
  current = 
0xc0002facc540
  paca    = 
0xc05ae600
    pid   = 17947, 
comm

= umount
kernel BUG in clear_inode at 
/root/xen-maria-latest/linux/linux-xen-ppc/fs/inode.c:251!

enter ? for help
2:mon>
2:mon>

This is built from Maria's tree 
on 11-9.



David Daly
Research Staff Member
32-003 IBM T.J. Watson Research Center
Yorktown Heights, NY, 10958
(914) 945-1845, T/L 
862-1845___

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


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



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



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

Re: [XenPPC] [linux-ppc-2.6] [LINUX][XEN][POWEPRC] def config changes

2006-10-25 Thread Maria Butrico 
I want to quibble about this change. 


First this is not an


# Automatically generated make config: don't edit


I thought we diligently updated this file by hand.   We edit it all the 
time.  The comment is flat out wrong.  (I know you did not change the 
comment today, but I am in a quibbling mood.)


Second quibble:

-# Sat Oct  7 08:37:53 2006
+# Thu Oct 12 16:16:49 2006


Why did you change the date?  May I point out that today is neither Oct 
7th nor is Oct 12.  Maybe Amos was right about the battery on your 
machine clock, after all.   May I point out that the change is spurious. 


Xen patchbot-linux-ppc-2.6 wrote:

# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID f4d382795e57b926cd82256bcb3a74c539731796
# Parent  4ab8b63fcff117bec150b9f6afd3ff292f51c1dd
[LINUX][XEN][POWEPRC] def config changes

 - turn off SCSI and IPR debugging now that it works
 - add CONFIG_NUMA to complimenet the memory hotplug that allows us to
   map granted memory

Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
 arch/powerpc/configs/xen_maple_defconfig |   15 +--
 1 files changed, 9 insertions(+), 6 deletions(-)

diff -r 4ab8b63fcff1 -r f4d382795e57 arch/powerpc/configs/xen_maple_defconfig
--- a/arch/powerpc/configs/xen_maple_defconfig  Tue Oct 24 11:24:33 2006 -0400
+++ b/arch/powerpc/configs/xen_maple_defconfig  Wed Oct 25 17:22:54 2006 -0400
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.17
-# Sat Oct  7 08:37:53 2006
+# Thu Oct 12 16:16:49 2006
 #
 CONFIG_PPC64=y
 CONFIG_64BIT=y
@@ -163,9 +163,9 @@ CONFIG_EEH=y
 CONFIG_EEH=y
 CONFIG_SCANLOG=y
 CONFIG_LPARCFG=y
-# CONFIG_NUMA is not set
+CONFIG_NUMA=y
+CONFIG_NODES_SHIFT=4
 CONFIG_ARCH_SELECT_MEMORY_MODEL=y
-CONFIG_ARCH_FLATMEM_ENABLE=y
 CONFIG_ARCH_SPARSEMEM_ENABLE=y
 CONFIG_ARCH_SPARSEMEM_DEFAULT=y
 CONFIG_SELECT_MEMORY_MODEL=y
@@ -173,12 +173,15 @@ CONFIG_SELECT_MEMORY_MODEL=y
 # CONFIG_DISCONTIGMEM_MANUAL is not set
 CONFIG_SPARSEMEM_MANUAL=y
 CONFIG_SPARSEMEM=y
+CONFIG_NEED_MULTIPLE_NODES=y
 CONFIG_HAVE_MEMORY_PRESENT=y
 # CONFIG_SPARSEMEM_STATIC is not set
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_MEMORY_HOTPLUG=y
 CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_MIGRATION=y
 CONFIG_RESOURCES_64BIT=y
+CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
 CONFIG_ARCH_MEMORY_PROBE=y
 # CONFIG_PPC_64K_PAGES is not set
 # CONFIG_SCHED_SMT is not set
@@ -512,14 +515,14 @@ CONFIG_SCSI_SAS_ATTRS=y
 # CONFIG_SCSI_INIA100 is not set
 # CONFIG_SCSI_SYM53C8XX_2 is not set
 CONFIG_SCSI_IPR=y
-CONFIG_SCSI_IPR_TRACE=y
-CONFIG_SCSI_IPR_DUMP=y
+# CONFIG_SCSI_IPR_TRACE is not set
+# CONFIG_SCSI_IPR_DUMP is not set
 # CONFIG_SCSI_QLOGIC_1280 is not set
 # CONFIG_SCSI_QLA_FC is not set
 # CONFIG_SCSI_LPFC is not set
 # CONFIG_SCSI_DC395x is not set
 # CONFIG_SCSI_DC390T is not set
-CONFIG_SCSI_DEBUG=y
+# CONFIG_SCSI_DEBUG is not set
 
 #

 # Multi-device support (RAID and LVM)

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




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

Re: [XenPPC] [xenppc-unstable] [TOOLS][POWERPC] use python "quad" encoding for 2 cell devtree values

2006-10-18 Thread Maria Butrico 
I cannot successfully make a libos domain with 2212M (2G+64).  I also 
cannot make one with 1024M.With 1024M the libos terminates, with 
2212 it traps.  There is no reason to believe that libos has code to 
handle any of that so this is not terribly surprising.  What intrigues 
me is that the in 1024 case xen terminated the domain, or so it looks at 
first glance and in the second case it does as well.I doubt I can be 
quick enough to attach the debugger and see why it trapped. 


I tested on one of 8G JS21.

(my libos is itself not necessarily in a stable state.  I was working on 
something else.)


The console output was illuminating

(XEN) allocated RMA for Dom[1]: 0x2000[0x400]
(XEN) Domain[1].0: initializing
(XEN) allocated RMA for Dom[2]: 0x2000[0x400]
(XEN) Domain[2].0: initializing
(XEN) allocated RMA for Dom[3]: 0x2000[0x400]
(XEN) Domain[3].0: initializing
(XEN) allocated RMA for Dom[4]: 0x2000[0x400]
(XEN) Domain[4].0: initializing
(XEN) allocated RMA for Dom[5]: 0x2000[0x400]
(XEN) Domain[5].0: initializing
(XEN) allocated RMA for Dom[6]: 0x2000[0x400]
(XEN) Domain[6].0: initializing

:)

There is nothing unusual in /var/xen

Jimi Xenidis wrote:


On Oct 18, 2006, at 5:50 PM, Maria Butrico wrote:


This patch is not yet in our tree.  I am getting a little tired of doing
this.


I bet! It can certainly wait, just know that you cannot create >= 2G 
domains until this makes it in to your stuff.

-JX

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




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

Re: [XenPPC] [xenppc-unstable] [TOOLS][POWERPC] use python "quad" encoding for 2 cell devtree values

2006-10-18 Thread Maria Butrico 
This patch is not yet in our tree.  I am getting a little tired of doing
this.

Maria Butrico



   
 Jimi Xenidis  
 <[EMAIL PROTECTED] 
 .com>  To 
   Orran Y Krieger/Watson/[EMAIL 
PROTECTED],   
 10/18/2006 04:40  Maria Butrico/Watson/[EMAIL PROTECTED],  
   
 PM[EMAIL PROTECTED] 
cc 
   XenPPC-devel

   Subject 
   Re: [XenPPC] [xenppc-unstable]  
   [TOOLS][POWERPC] use python "quad"  
   encoding for 2 cell devtree values  
   
   
   
   
   
   




The following changeset should fix the issue with DomU >=2G where our
python devtree code can only handle ints and math from a 2G value
promotes the type to long which before this patch we could not encode.

Please test on larger systems.
-JX
On Oct 18, 2006, at 4:20 PM, Xen patchbot-xenppc-unstable wrote:

> # HG changeset patch
> # User Jimi Xenidis <[EMAIL PROTECTED]>
> # Node ID d18a0c0b77d7004631559d4e2f9d31744fe9b34a
> # Parent  ece7037c72c6b7944ede2261ec1fe99c1489cff4
> [TOOLS][POWERPC] use python "quad" encoding for 2 cell devtree values
> When creating a 2G DomU pyhton chokes when it sees a long type.  If a
> value is of type long, or promoted to long it should be "packed" as a
> quad.
>
> Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
> ---
>  tools/python/xen/xend/FlatDeviceTree.py |   16 +---
>  1 files changed, 9 insertions(+), 7 deletions(-)
>
> diff -r ece7037c72c6 -r d18a0c0b77d7 tools/python/xen/xend/
> FlatDeviceTree.py
> --- a/tools/python/xen/xend/FlatDeviceTree.pyWed Oct 18 11:29:57

> 2006 -0400
> +++ b/tools/python/xen/xend/FlatDeviceTree.pyWed Oct 18 16:07:33

> 2006 -0400
> @@ -37,8 +37,10 @@ def _bincat(seq, separator=''):
>  '''Concatenate the contents of seq into a bytestream.'''
>  strs = []
>  for item in seq:
> -if type(item) == type(0):
> +if isinstance(item, int):
>  strs.append(struct.pack(">I", item))
> +elif isinstance(item, long):
> +strs.append(struct.pack(">Q", item))
>  else:
>  try:
>  strs.append(item.to_bin())
> @@ -287,9 +289,9 @@ def build(imghandler):
>  root.addprop('compatible', 'Momentum,Maple\0')
>
>  xen = root.addnode('xen')
> -xen.addprop('start-info', 0, 0x3ffc000, 0, 0x1000)
> +xen.addprop('start-info', long(0x3ffc000), long(0x1000))
>  xen.addprop('version', 'Xen-3.0-unstable\0')
> -xen.addprop('reg', 0, imghandler.vm.domid, 0, 0)
> +xen.addprop('reg', long(imghandler.vm.domid), long(0))
>  xen.addprop('domain-name', imghandler.vm.getName() + '\0')
>  xencons = xen.addnode('console')
>  xencons.addprop('interrupts', 1, 0)
> @@ -301,14 +303,14 @@ def build(imghandler):
>
>  # RMA node
>  rma = root.addnode('[EMAIL PROTECTED]')
> -rma.addprop('reg', 0, 0, 0, rma_bytes)
> +rma.addprop('reg', long(0), long(rma_bytes))
>  rma.addprop('device_type', 'memory\0')
>
>  # all the rest in a single node
>  remaining = totalmem - rma_bytes
>  if remaining > 0:
>  mem = root.addnode('[EMAIL PROTECTED]')
> -mem.addprop('reg', 0, rma_bytes, 0, remaining)
> +mem.addprop('reg', long(rma_bytes), long(remaining))
>  mem.addprop('device_type', 'memory\0')
>
>  # add CPU nodes
> @@ -346,8 +348,8 @@ def build(imghandler):
>  chose

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-09 Thread Maria Butrico 
Even though I proposed this, I like to withdraw the request.  We have 
identified a machine, a JS20 model 884241X, on which Xen with the SMP 
patch does not boot (Kawachiya-san machine).


It would be useful to know what kind of JS20 blades have successfully 
booted xen with the SMP patch.  In Yorktown we have booted successfully 
only on JS20 model 21X. 


Maria Butrico wrote:
Jimi, the problem with this approach is that as changes are made to 
the Xen code, you have no idea if they make the smp situation better 
or worse.  If you introduce a bug only visible with SMP or more likely 
to happen running MP you don't find out until someone picks up your 
code and applies the smp patch.


Jimi Xenidis wrote:


On Oct 3, 2006, at 12:25 PM, Maria Butrico wrote:

What's really interesting to me about this is that the invocation of 
the

icache invalidation did not go in till later.


But it did include the I/D cache flush of text.
The i-cache invalidate you speak requires the running of DomUs


So if anything we could find
this to be even more reliable one the other changes are also picked up.


not much has happened that would effect boot and ssh to dom0



I missed this:  what is transient?

I would like to suggest that the SMP patch be applied to the base, 
and that
in those case where we known that SMP fails, like on maples,  we use 
the

nosmp option.


I'm still not prepared to take the SMP patch, the I-Cache invalidate 
fix has improved the situation on maple, but not enough to convince 
me that there are no more troubles waiting to pounce.


-JX


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




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




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

Re: [XenPPC] Cannot boot from local disk

2006-10-06 Thread Maria Butrico 
Kawachiya-san, seems that your problem today is different from 
yesterday.  You have however not answered any of my questions.  So here 
is goes again. 


Kawachiya-san, can you tell us exactly what kind of js20 is this.  I just
learned that there are two, the 21X (of which we have some in Yorktown) and
the GA2.  You can tell from the machine/model type.

When you boot the machine, during the firmware bring up, how many
processors are reported?

(for the list: I am asked this question because there was a problem 
coming up MP)


I assume that yesterday, once you changed xen to boot UP, you were 
suppling the same command line to dom0 via yaboot, but what did dom0 
really get?


Your error message yesterday was

 Root-NFS: No NFS server available, giving up.
 VFS: Unable to mount root fs via NFS, trying floppy.

Obviously today you have regressed, but still we need answers to all 
those questions.



Kiyokuni Kawachiya wrote:

[XenPPC] [xenppc-unstable] [POWERPC][XEN] Remove boot wrapper, and


extensive Makefile simplifications.

It seems that the above change made my XenPPC unbootable from local disk.

I had been booting XenPPC through yaboot by adding the following lines to
/etc/yaboot.conf of SLES10.
(The /boot/xen-3.0-unstable is copied from xen/xen in the build tree.)

image = /boot/xen-3.0-unstable
label = xen
append = "xen -- root=/dev/hda3 sysrq=1 insmod=sym53c8xx insmod=ipr"

However, after the patch, yaboot failed to load the image with the
following message.

Welcome to yaboot version 10.1.14-r716.SuSE
booted from '/ht/[EMAIL PROTECTED],1/[EMAIL PROTECTED]'
Enter "help" to get some basic usage information
boot: xen
Please wait, loading kernel...
Can't find a loadable segment !
boot:

Is there any workaround to boot the new image from local disk?

Kiyokuni Kawachiya / IBM Tokyo Research Lab.


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




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

[XenPPC] [PATCH] fixes makefile clean logic

2006-10-04 Thread Maria Butrico 
summary:  fixes makefile clean logic

details: The three files xen-syms.S xen-lds and asm-offsets.s, all in the
xen/arch/powerpc subdirectory, are created by make.  Thus they should be
removed by make clean.

Signed-of-by: Maria Butrico <[EMAIL PROTECTED]>

diff -r ea14174c392b xen/arch/powerpc/Makefile
--- a/xen/arch/powerpc/Makefile Tue Oct 03 10:02:19 2006 -0400
+++ b/xen/arch/powerpc/Makefile Wed Oct 04 16:31:15 2006 -0400
@@ -149,4 +149,5 @@ dom0.bin: $(DOM0_IMAGE)
 
 clean::
$(MAKE) -f $(BASEDIR)/Rules.mk -C of_handler clean
-   rm -f firmware firmware_image dom0.bin .xen-syms
+   rm -f firmware firmware_image dom0.bin .xen-syms xen-syms.S \
+   xen.lds asm-offsets.s

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

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Maria Butrico 
Jimi, the problem with this approach is that as changes are made to the 
Xen code, you have no idea if they make the smp situation better or 
worse.  If you introduce a bug only visible with SMP or more likely to 
happen running MP you don't find out until someone picks up your code 
and applies the smp patch.


Jimi Xenidis wrote:


On Oct 3, 2006, at 12:25 PM, Maria Butrico wrote:


What's really interesting to me about this is that the invocation of the
icache invalidation did not go in till later.


But it did include the I/D cache flush of text.
The i-cache invalidate you speak requires the running of DomUs


So if anything we could find
this to be even more reliable one the other changes are also picked up.


not much has happened that would effect boot and ssh to dom0



I missed this:  what is transient?

I would like to suggest that the SMP patch be applied to the base, 
and that

in those case where we known that SMP fails, like on maples,  we use the
nosmp option.


I'm still not prepared to take the SMP patch, the I-Cache invalidate 
fix has improved the situation on maple, but not enough to convince me 
that there are no more troubles waiting to pounce.


-JX


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




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

[XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Maria Butrico 
What's really interesting to me about this is that the invocation of the
icache invalidation did not go in till later.  So if anything we could find
this to be even more reliable one the other changes are also picked up.

I missed this:  what is transient?

I would like to suggest that the SMP patch be applied to the base, and that
in those case where we known that SMP fails, like on maples,  we use the
nosmp option.

Maria Butrico



   
 [EMAIL PROTECTED] 
 ux.ibm.com
To 
 10/03/2006 11:54  xen-ppc-devel@lists.xensource.com   
 AM cc 
   
   Subject 
   Automated reliability report for
   SMP patch on JS2x   
   
   
   
   
   
   




An automated process has boooted Xen on two JS21 blades and one JS20
blade a total of 1241 times, recording 0 failures and 1237 passes, using
a correctness criteria of the creation of four domU's for the first
JS21, the launch of the ssh daemon for the second JS21, and the creation
of two domU's for the JS20.

The version of Xen used was changeset dd95dd13cd3e+, which is the
following tip of tree changeset plus the bootargs simplification patch
plus the SMP patch:

 changeset:   12184:02f6e775deb1
 user:Jimi Xenidis <[EMAIL PROTECTED]>
 date:Mon Oct 02 11:07:54 2006 -0400
 summary: Add Function to completely flush the I-Cache for a processor

---

changeset   : dd95dd13cd3e+
machine : cso92
pass: 401
fail: 0
transient   : 3
total   : 404
reliability : 100.0%

changeset   : dd95dd13cd3e+
machine : kpblade7
pass: 423
fail: 0
transient   : 1
total   : 424
reliability : 100.0%

changeset   : dd95dd13cd3e+
machine : kpblade1
pass: 413
fail: 0
transient   : 0
total   : 413
reliability : 100.0%




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

[Fwd: Re: [XenPPC] [PATCH] Parse Xen command line properly]

2006-10-02 Thread Maria Butrico 


--- Begin Message ---
A long overdue comment about the size of the buffer buff and the size of 
the buffer bootargs also 256 bytes in boot_of.c.  With the long file 
name for our nfs roots, combined with long names for our initialization 
scripts, I have actually gotten over the limit.  Naturally this occurred 
just shortly before an important deadline.   My current command line, 
for linux only, is 208 characters. 


Amos Waterland wrote:

We are improperly feeding the entire boot parameter string to Xen's
generic command line parser.  This can have unexpected results when one
of the dom0 parameters, such as console=X, has meaning to the Xen
parser.  First reported by Maria Butrico.

Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>

---

 setup.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff -r 261c458e46af xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c  Fri Sep 29 18:13:27 2006 -0400
+++ b/xen/arch/powerpc/setup.c  Mon Oct 02 00:17:07 2006 -0400
@@ -279,8 +279,20 @@ static void __init __start_xen(multiboot
 ticks_per_usec = timebase_freq / 100ULL;
 
 /* Parse the command-line options. */

-if ((mbi->flags & MBI_CMDLINE) && (mbi->cmdline != 0))
-cmdline_parse(__va((ulong)mbi->cmdline));
+if ((mbi->flags & MBI_CMDLINE) && (mbi->cmdline != 0)) {
+char *end, *src = (char *)(ulong)mbi->cmdline;
+char buff[256];
+
+end = strstr(src, "--");
+
+if (end && (end - src < sizeof(buff))) {
+strlcpy(buff, src, end - src);
+} else {
+strlcpy(buff, src, sizeof(buff));
+}
+
+cmdline_parse(buff);
+}
 
 /* We initialise the serial devices very early so we can get debugging. */

 ns16550.io_base = 0x3f8;

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



--- End Message ---
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] xm dump-core

2006-09-29 Thread Maria Butrico 
If anyone knows anything about how this is supposed to work I can take 
quick stab at it.  We can probably use it.


Jimi Xenidis wrote:


On Sep 28, 2006, at 3:58 PM, Maria Butrico wrote:

I can dump part of the core file out but not all.  I see a message 
about connection refused to xend.  Yet xend is running.Are there 
tools for reading the core file?


Sorry, not supported yet, not even in our checklist:
  http://wiki.xensource.com/xenwiki/XenPPC/XMChecklist

-JX






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

[XenPPC] xm dump-core

2006-09-28 Thread Maria Butrico 
I can dump part of the core file out but not all.  I see a message about 
connection refused to xend.  Yet xend is running.Are there tools for 
reading the core file?



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

[XenPPC] Xen hang

2006-09-26 Thread Maria Butrico 

This is new (at least for me)

(on a js21 with 8G, cso91)

(XEN) Physical RAM map:
(XEN) End of RAM: 10240MB (10485760kB)
(XEN) total_pages: 0x001fc000
(XEN) free_xenheap: 0x55000 - 0x40
(XEN) Xen heap: 63MB (65196kB)
(XEN) free_xenheap: 0xb36000 - 0x400
(XEN) free_xenheap: Go around the devtree: 0xb36000 - 0xb66000
(XEN) Domheap pages: 0x1fbc00 8124MB (8318976kB)
(XEN) CPU[PIR:0 IPI:0 Logical:0] Hello World!
(XEN) xen_mpic_init: start
(XEN) mpic: Setting up MPIC "Xen-U3-MPIC" version 1.2 at f804, max 4 
CPUs

(XEN) mpic: ISU size: 124, shift: 7, mask: 7f
(XEN) mpic: Initializing for 124 sources
(XEN) mpic: Setting up HT PICs workarounds for U3/U4
(XEN) mpic:   - HT:07.0 [0xf0] vendor 1022 device 7460 has 24 irqs
(XEN) xen_mpic_init: success
(XEN) Using scheduler: SMP Credit Scheduler (credit)

Recall that my tree is slightly modified.


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

Re: [XenPPC] JS20 does not boot with latest pull

2006-09-26 Thread Maria Butrico 

Dan, do you have a js20?

Jimi Xenidis wrote:

uh oh.
These are really old processor and may have SCOM issues
those having a boot problem please comment out the body on 
cpu_scom_init() in:

 xen/arch/powerpc/powerpc64/ppc970_scom.c

and see let me know if it works?
-JX

On Sep 25, 2006, at 5:52 PM, poff wrote:


Verified booting problems on JS20... Tail of serial output is below.
(SOL is not available on this blade chassis.)
Ping does not work, even after a few minutes.

...

 Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 3.4.1) 
Mon Sep 25 17:42:43 ED6

 Latest ChangeSet: Mon Sep 25 11:19:55 2006 -0400 12160:acfb1ac23f80

(XEN) Physical RAM map:
(XEN) End of RAM: 512MB (524288kB)
(XEN) total_pages: 0x0001c000
(XEN) free_xenheap: 0x9000 - 0x40
(XEN) Xen heap: 63MB (65500kB)
(XEN) free_xenheap: 0x757000 - 0x400
(XEN) free_xenheap: Go around the devtree: 0x757000 - 0x787000
(XEN) Domheap pages: 0x1bc00 444MB (454656kB)
(XEN) CPU[PIR:0 IPI:0 Logical:0] Hello World!
(XEN) SCOM PTSR: 0x
(XEN) spinning up at most 16 total processors ...
(XEN) Synchronizing timebase
(XEN) CPU[PIR:1 IPI:1 Logical:1] Hello World!
(XEN) SCOM PTSR: 0x
(XEN) Got ack




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



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

[XenPPC] console in the background

2006-09-09 Thread Maria Butrico 
Putting the partition xen console in the background (e. g, xm create -c 
... & or xm console &) seems to kill the console (xenconsole) process.  
Is this behavior expected?



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

[XenPPC] [PATCH] fix allocation bug in xen console

2006-09-08 Thread Maria Butrico 
summary:  fixes allocation error for xen console area

details: previous code worked correctly only if the allocated structure fitted
in same page as the base address.  If the allocated structure did not fit, the
computation for the allocation was incorrect.

Signed-of-by: Maria Butrico <[EMAIL PROTECTED]>

--- a/xen/arch/powerpc/of_handler/xencomm.c Tue Sep 05 15:25:06 2006 -0400
+++ b/xen/arch/powerpc/of_handler/xencomm.c Fri Sep 08 08:38:06 2006 -0400
@@ -50,18 +50,18 @@ static void *__xencomm_alloc_mini(void *
 static void *__xencomm_alloc_mini(void *area, int arealen)
 {
 unsigned long base = (unsigned long)area;
-unsigned int pageoffset;
+unsigned int left_in_page;
 
-pageoffset = base % PAGE_SIZE;
+left_in_page = PAGE_SIZE - base % PAGE_SIZE;
 
 /* we probably fit right at the front of area */
-if ((PAGE_SIZE - pageoffset) >= sizeof(struct xencomm_mini)) {
+if (left_in_page >= sizeof(struct xencomm_mini)) {
 return area;
 }
 
 /* if not, see if area is big enough to advance to the next page */
-if ((arealen - pageoffset) >= sizeof(struct xencomm_mini))
-return (void *)(base + pageoffset);
+if ((arealen - left_in_page) >= sizeof(struct xencomm_mini))
+return (void *)(base + left_in_page);
 
 /* area was too small */
 return NULL;

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

Re: [XenPPC] heads up: large nasty merge

2006-09-06 Thread Maria Butrico 

Tony Breeds wrote:

On Tue, Sep 05, 2006 at 06:04:54PM -0500, Hollis Blanchard wrote:
  

I just committed a large nasty merge to xenppc-unstable and
linux-ppc-2.6. You definitely need to pull both at once.

The big change is that dom0_ops was fragmented into separate hcalls, so
if you don't update Linux with Xen you will get lots of "invalid
argument" errors from every dom0_op hcall, which xend does an awful lot
of.

I've built and booted a domU via xend, but it's possible something
didn't get rebuilt or I missed a file to check in, so please let me know
if you have problems.



I've failed to get the linux.hg tree to build.  xen.hg seems fine.
I made a few changes locally to try and keep things moving but I got
stuck.

Early on I get told that "arch-powerpc.h" doesn't exist, so I ran:
hg mv include/xen/interface/arch-ppc64.h include/xen/interface/arch-powerpc.h
Which helped.

With this is palce I get a little further in the build then I start to
get complaints about __XEN_INTERFACE_VERSION__ being redefined.  To work
around this I removed the:

#if !(defined(__XEN__) || defined(__XEN_TOOLS__))
/* not sure how this is supposed to get asserted */
#define __XEN_INTERFACE_VERSION__ 0x00030202
#endif

from the (new arch-powerpc.h) file.  and added:

diff -r 0d95131b439e arch/powerpc/Makefile
--- a/arch/powerpc/Makefile Tue Sep 05 18:00:40 2006 -0500
+++ b/arch/powerpc/Makefile Wed Sep 06 15:43:54 2006 +1000
@@ -60,6 +60,8 @@ endif
 
 LDFLAGS_vmlinux:= -Bstatic
 
+CPPFLAGS-$(CONFIG_XEN) += \

+   -D__XEN_INTERFACE_VERSION__=$(CONFIG_XEN_INTERFACE_VERSION)
 # The -Iarch/$(ARCH)/include is temporary while we are merging
 CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -Iarch/$(ARCH)/include
 AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)

[sorry a single patch isn't easy here as an hg rename is an delete+add,
 patching the new file just loses context :(]

At this point I end up with:

I get told include/xen/interface/{domctl,sysctl,platform}.h are missing.
Also hg manifest still tells me that include/xen/interface/dom0_ops.h still
exists.  I don't think I can trivially recreate these files so I stopped
here.

Hope this helps.

Yours Tony

   linux.conf.au   http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007  The Australian Linux Technical Conference!


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
  
I am poking around Jimi's own tree to try and find the pieces.  
arch-powerpc.h was not only renamed but also changed. Have not gotten a 
full build yet and will send files when I do.



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

[XenPPC] console=com2 boot argument

2006-09-05 Thread Maria Butrico 

This boot command line does not work

*bootargs = xen console=com2 -- console=ttyS1,19200 ro root=/dev/nfs 
nfsroot=9.2.208.86:/home/apw/devel/nfsroots/sles10-rootfs 
ip=9.2.129.20::9.2.129.2:255.255.255.0:kpblade7:eth1:off*



The problem is that in console.c opt_console is set to 'ttyS1,19200' 

Naturally the fix it to remove the second console=, and I think I have 
fallen in this trap already once :(



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

Re: [XenPPC] Out of memory issues with xen

2006-08-25 Thread Maria Butrico 

Hollis Blanchard wrote:

On Fri, 2006-08-25 at 15:16 -0400, Jimi Xenidis wrote:
  

On Aug 25, 2006, at 3:00 PM, Hollis Blanchard wrote:



On Fri, 2006-08-25 at 14:18 -0400, Maria Butrico wrote:
  

I should report to the list some of issues we have been having with
memory when using xen, it's dom0 and another partition.

The first problem is that by default dom0 only has 64M and that  
there is
no way to change this other that changing xen (the fix is easy  
enough).

64M is too little to run the compiler and build the tools.

64M is plenty. I've never suffered from any memory issues while  
building the tools.



Maybe because they're using NFS they have more memory pressure.

  
No.  We have memory pressure even when we boot the the local disk.  
Please see 
http://lists.xensource.com/archives/html/xen-ppc-devel/2006-08/msg00330.html.

You don't need to run a compiler in dom0. I don't...
  
I have the same question on this one that Jimi already asked and that 
was already answered. In any case we need to run the compiler eventually 
the GPFS client and lots of other junk. 


Funny, I do so I can "$ make install-tools" in my Dom0.
Hollis, how do you install your tools?
Do the cross build yet?



No, I haven't pursued that because I haven't had the time.

I build on another PPC system, "make DESTDIR=foo install-tools", and
copy foo/* to the victim.

  



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

[XenPPC] Out of memory issues with xen

2006-08-25 Thread Maria Butrico 
I should report to the list some of issues we have been having with 
memory when using xen, it's dom0 and another partition. 

The first problem is that by default dom0 only has 64M and that there is 
no way to change this other that changing xen (the fix is easy enough).  
64M is too little to run the compiler and build the tools. 

The second problem is that when we change xen to give dom0 128M dom0 we 
do not have enough memory to make another partition even though the 
machine has 512M.  This is a bug that Jimi is currently looking into (I 
think).


So the current state of things for us developing an OS on xen is that we 
boot with 128M, build and save the tools, then re-boot with 64M and run 
the OS.  Of course, we do not have to rebuild the tools all the time 
while we rebuild the OS quite a few times. 

There is an effort, related to our larger project, to use an nfsroot for 
xen.  This almost works, but in 64M run out of memory quickly.  There 
being no paging space with this configuration when the kernel has no 
more space it crashes. 

Ideally we would like at least 128M on dom0 and the ability to make 
another partition of 64M or 128M. 



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

Re: [XenPPC] Error creating domain on JS20 (Fw: [Prose-jvm] Brief Status in TRL (2006/08/24))

2006-08-25 Thread Maria Butrico 

Kawachiya-san tried this patch and it worked for him.  Thank you.

Hollis Blanchard wrote:

On Thu, 2006-08-24 at 10:35 -0500, Hollis Blanchard wrote:
  

On Thu, 2006-08-24 at 10:42 -0400, Kiyokuni Kawachiya wrote:



Today, I installed necessary tools including mercurial to LinuxPPC,
self-built XenPPC, dom0 Linux, and Xen Tools on LinuxPPC, and installed
them.  I also built j9-xen-ppc with the latest codes, and tried to start it
on my Linux/XenPPC/JS20.  The xend daemon was successfully started, but
when I tried "xm create -c xen-domain-config", it failed with the following
message.

Error: [Errno 2] No such file or directory:
'/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]'

The directory does not exist in my dom0 Linux, but "PowerPC,[EMAIL PROTECTED]" 
exists
instead.  Maybe, my JS20 is newer than Watson's, and uses different CPU
(970FX).  Today, I have no time to debug this further.  Any solution?
  

I'll try to come up with a more general solution.



Here is the more general solution: it searches /cpus for the first node
with device_type containing "cpu", regardless of how the node is named.

I won't commit until I hear a couple "works for me" reports (and no
"fails miserably" reports :) .

diff -r b2f2c477895a tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py   Tue Aug 22 16:48:58 2006 -0500
+++ b/tools/python/xen/xend/FlatDeviceTree.py   Thu Aug 24 15:16:13 2006 -0500
@@ -22,6 +22,9 @@ import struct
 import struct
 import stat
 import re
+import glob
+
+_host_devtree_root = '/proc/device-tree'
 
 _OF_DT_HEADER = int("d00dfeed", 16) # avoid signed/unsigned FutureWarning

 _OF_DT_BEGIN_NODE = 0x1
@@ -231,29 +234,36 @@ class Tree(_Node):
 header.totalsize = len(payload) + _alignup(len(header.to_bin()), 8)
 return _pad(header.to_bin(), 8) + payload
 
-_host_devtree_root = '/proc/device-tree'

-def _getprop(propname):
-'''Extract a property from the system's device tree.'''
-f = file(os.path.join(_host_devtree_root, propname), 'r')
+def _readfile(fullpath):
+'''Return full contents of a file.'''
+f = file(fullpath, 'r')
 data = f.read()
 f.close()
 return data
 
+def _find_first_cpu(dirpath):

+'''Find the first node of type 'cpu' in a directory tree.'''
+cpulist = glob.glob(os.path.join(dirpath, 'cpus', '*'))
+for node in cpulist:
+try:
+data = _readfile(os.path.join(node, 'device_type'))
+except IOError:
+continue
+if 'cpu' in data:
+return node
+raise IOError("couldn't find any CPU nodes under " + dirpath)
+
 def _copynode(node, dirpath, propfilter):
-'''Extract all properties from a node in the system's device tree.'''
+'''Copy all properties and children nodes from a directory tree.'''
 dirents = os.listdir(dirpath)
 for dirent in dirents:
 fullpath = os.path.join(dirpath, dirent)
 st = os.lstat(fullpath)
 if stat.S_ISDIR(st.st_mode):
 child = node.addnode(dirent)
-_copytree(child, fullpath, propfilter)
+_copynode(child, fullpath, propfilter)
 elif stat.S_ISREG(st.st_mode) and propfilter(fullpath):
-node.addprop(dirent, _getprop(fullpath))
-
-def _copytree(node, dirpath, propfilter):
-path = os.path.join(_host_devtree_root, dirpath)
-_copynode(node, path, propfilter)
+node.addprop(dirent, _readfile(fullpath))
 
 def build(imghandler):

 '''Construct a device tree by combining the domain's configuration and
@@ -289,15 +299,18 @@ def build(imghandler):
 cpus.addprop('#address-cells', 1)
 
 # Copy all properties the system firmware gave us, except for 'linux,'

-# properties, from 'cpus/@0', once for every vcpu. Hopefully all cpus are
-# identical...
+# properties, from the first CPU node in the device tree. Do this once for
+# every vcpu. Hopefully all cpus are identical...
 cpu0 = None
+cpu0path = _find_first_cpu(_host_devtree_root)
 def _nolinuxprops(fullpath):
 return not os.path.basename(fullpath).startswith('linux,')
 for i in range(imghandler.vm.getVCpuCount()):
-cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]')
-_copytree(cpu, 'cpus/PowerPC,[EMAIL PROTECTED]', _nolinuxprops)
-# and then overwrite what we need to
+# create new node and copy all properties
+cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]' % i)
+_copynode(cpu, cpu0path, _nolinuxprops)
+
+# overwrite what we need to
 pft_size = imghandler.vm.info.get('pft-size', 0x14)
 cpu.setprop('ibm,pft-size', 0, pft_size)
 

  




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

Re: [XenPPC] current crash

2006-08-25 Thread Maria Butrico 
Additional information:  Orran and I have modified xen to show all 
hcalls made by domains other than 0 and idle.  In addition we are not 
showing hcall x20, event channel operation (because we get one for every 
character put to the partition console.)


Should the code below also show HSRRs?

Orran Y Krieger wrote:


Been doing a binary search to find at least one of the things causing 
a crash.   What I have now is that the following call from libOS 
reliably crashes xen.


the call is:
rc = hcall_read(ret, flags, idx + i);
In the library OS , with parameters:
flags - 0, idx = 0 ret = 240948

That coems into xen as hcall "c" with the following registers:
(XEN) sync_vcpu_execstate: called

(XEN) [ Xen-3.0-unstable ]

(XEN) CPU:    DOMID: 0003

(XEN) pc 00102a40 msr 

(XEN) lr 85e8 ctr 001098f0

(XEN) srr0  srr1 

(XEN) r00: 00240998 002408e8 00276100 
000c


(XEN) r04:   001c 
002403a0


(XEN) r08: 002554b8  002554b8 
0003


(XEN) r12: 083f   



(XEN) r16:    



(XEN) r20:    



(XEN) r24:    



(XEN) r28:    
002408e8



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




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

Re: [XenPPC] Error creating domain on JS20 (Fw: [Prose-jvm] Brief Status in TRL (2006/08/24))

2006-08-24 Thread Maria Butrico 

I have the latest SLOF (6331)

kpblade4:/proc/device-tree/cpus # ls
#address-cells  linux,phandle  name  PowerPC,[EMAIL PROTECTED]  #size-cells  
smp-enabled

I also probably have a old blade.   But your statement is correct: 


"Almost all JS20".  However, that is not the same as all the JS20.

Segher Boessenkool wrote:
The directory does not exist in my dom0 Linux, but "PowerPC,[EMAIL PROTECTED]" 
exists

instead.  Maybe, my JS20 is newer than Watson's, and uses different CPU
(970FX).  Today, I have no time to debug this further.  Any solution?


You have a newer SLOF version, only the ancient version uses
plain "970" for everything.  Almost all JS20's actually are 970FX.


we have 970, 970FX, 970MP, 970PG and there may be others :)


970, 970FX, 970GX, 970MP, actually.


can we glob this in the python?


Shouldn't be any reason to glob for 970, even -- all device nodes
below /cpus are cpus, always.


Segher


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




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

[XenPPC] Error creating domain on JS20 (Fw: [Prose-jvm] Brief Status in TRL (2006/08/24))

2006-08-24 Thread Maria Butrico 



Maria Butrico

- Forwarded by Maria Butrico/Watson/IBM on 08/24/2006 10:15 AM -
   
 Kiyokuni  
 Kawachiya 
 <[EMAIL PROTECTED]  To 
 com>  [EMAIL PROTECTED]
 Sent by:   cc 
 prose-jvm-bounces 
 @opensource.ibm.c Subject 
 om[Prose-jvm] Brief Status in TRL 
   (2006/08/24)
   
 08/24/2006 08:49  
 AM
   
   
 Please respond to 
 [EMAIL PROTECTED] 
rce.ibm.com
   
   





Today, I installed necessary tools including mercurial to LinuxPPC,
self-built XenPPC, dom0 Linux, and Xen Tools on LinuxPPC, and installed
them.  I also built j9-xen-ppc with the latest codes, and tried to start it
on my Linux/XenPPC/JS20.  The xend daemon was successfully started, but
when I tried "xm create -c xen-domain-config", it failed with the following
message.

Error: [Errno 2] No such file or directory:
'/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]'

The directory does not exist in my dom0 Linux, but "PowerPC,[EMAIL PROTECTED]" 
exists
instead.  Maybe, my JS20 is newer than Watson's, and uses different CPU
(970FX).  Today, I have no time to debug this further.  Any solution?

Kiyokuni KAWACHIYA, Ph.D. / IBM Tokyo Research Laboratory
___
Prose-jvm mailing list
[EMAIL PROTECTED]
http://w3.opensource.ibm.com/mailman/listinfo/prose-jvm


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

Re: [XenPPC] making xen tools on dom0 can be slow

2006-08-22 Thread Maria Butrico 

Maria Butrico wrote:

This was discussed yesterday and it was suggested that I should enter a bug
for this.  Since then I have done a few experiments:

By default dom0 has 64M.  Under these condition make tools takes 24 minutes
on a js20.

make[1]: Leaving directory `/home/j9/xen-ppc/tools'

real24m1.321s
user0m34.716s
sys 0m23.272s

I have found this is about the case on average.  This is with the xen
source tree on nfs.  I dismiss this as a network related problem since I
see no evidence of this.

By changing xen to give 128M to each domain and therefore to dom0, the same
make, also with source over nfs takes less than 2 minutes.

make[1]: Leaving directory `/home/j9/xen-ppc/tools'

real1m15.445s
user0m32.800s
sys 0m14.753s

I will not enter this as a bug.  If anything the bug is that one might not
specify the memory size for dom0.

(On a related note, once we alter xen to give each domain 128M, xm create
no longer works.  Jimi is debugging this.)

Also I reported slowness for starting xend.  I am still working with this
and will post to the list as soon as I have more data.  Simply giving more
memory to dom0 does not fix the slow xend start problem.

Maria Butrico


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
  
Jimi and I have looked more carefully at the xend startup problem.  xend 
is very slow if the tools or any part of the environment variable PATH 
are in an nfs mounted directory.  Xend starts in reasonable time if the 
tools are local and no part of the PATH environment variable points a to 
a remote directory. 



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

[XenPPC] making xen tools on dom0 can be slow

2006-08-22 Thread Maria Butrico 

This was discussed yesterday and it was suggested that I should enter a bug
for this.  Since then I have done a few experiments:

By default dom0 has 64M.  Under these condition make tools takes 24 minutes
on a js20.

make[1]: Leaving directory `/home/j9/xen-ppc/tools'

real24m1.321s
user0m34.716s
sys 0m23.272s

I have found this is about the case on average.  This is with the xen
source tree on nfs.  I dismiss this as a network related problem since I
see no evidence of this.

By changing xen to give 128M to each domain and therefore to dom0, the same
make, also with source over nfs takes less than 2 minutes.

make[1]: Leaving directory `/home/j9/xen-ppc/tools'

real1m15.445s
user0m32.800s
sys 0m14.753s

I will not enter this as a bug.  If anything the bug is that one might not
specify the memory size for dom0.

(On a related note, once we alter xen to give each domain 128M, xm create
no longer works.  Jimi is debugging this.)

Also I reported slowness for starting xend.  I am still working with this
and will post to the list as soon as I have more data.  Simply giving more
memory to dom0 does not fix the slow xend start problem.

Maria Butrico


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

[XenPPC] [PATCH] Fix domU device tree creation for JS20/1

2006-08-21 Thread Maria Butrico 
Summary:  Fix device tree creation for domU for js20/1 under SLOF

The device tree of dom0 on js20 and js21 with SLOF does not have the cpus'
d and i cache sets nor does it have the l2 cache subdirectory.  

Signed-off-by:  Maria Butrico <[EMAIL PROTECTED]>

diff -r 326e6736d92b tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py   Mon Aug 21 10:04:37 2006 -0400
+++ b/tools/python/xen/xend/FlatDeviceTree.py   Mon Aug 21 14:38:46 2006 -0400
@@ -245,24 +245,23 @@ def build(imghandler):
 cpu.addprop('reg', i)
 cpu.addprop('cpu#', i)
 cpu.addprop('device_type', 'cpu\0')
-for prop in ('d-cache-size', 'd-cache-line-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-line-size', 'i-cache-sets',
- 'clock-frequency', 'timebase-frequency',
- 'timebases-in-sync'):
+for prop in ('d-cache-size', 'd-cache-line-size',
+ 'i-cache-size', 'i-cache-line-size',
+ 'clock-frequency', 'timebase-frequency'):
 val = _getprop(os.path.join('cpus/PowerPC,[EMAIL PROTECTED]', 
prop))
 cpu.addprop(prop, val)
 # XXX 64-bit, more
 
 # L2 cache
-l2 = cpu.addnode('l2-cache')
-l2.addprop('name', 'l2-cache\0')
-l2.addprop('device_type', 'cache\0')
-for prop in ('d-cache-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-sets',
- 'cache-unified'):
-fullprop = os.path.join('cpus/PowerPC,[EMAIL PROTECTED]/l2-cache' 
% i, prop)
-val = _getprop(fullprop)
-l2.addprop(prop, val)
+#l2 = cpu.addnode('l2-cache')
+#l2.addprop('name', 'l2-cache\0')
+#l2.addprop('device_type', 'cache\0')
+#for prop in ('d-cache-size', 'd-cache-sets',
+# 'i-cache-size', 'i-cache-sets',
+# 'cache-unified'):
+#fullprop = os.path.join('cpus/PowerPC,[EMAIL PROTECTED]/l2-cache' 
% i, prop)
+#val = _getprop(fullprop)
+#l2.addprop(prop, val)
 
 # set default CPU
 if cpu0 == None:

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

[XenPPC] xend and device tree on js20 and js21

2006-08-21 Thread Maria Butrico 

This is what the device tree looks like on a js21 (under SLOF)

kpblade7 PowerPC,[EMAIL PROTECTED] # ls -l
total 11
-r--r--r--  1 root root  4 Aug 21 12:42 clock-frequency
-r--r--r--  1 root root  4 Aug 21 12:42 d-cache-line-size
-r--r--r--  1 root root  4 Aug 21 12:42 d-cache-size
-r--r--r--  1 root root  4 Aug 21 12:42 device_type
-r--r--r--  1 root root  4 Aug 21 12:42 i-cache-line-size
-r--r--r--  1 root root  4 Aug 21 12:42 i-cache-size
-r--r--r--  1 root root  8 Aug 21 12:42 ibm,pft-size
-r--r--r--  1 root root  4 Aug 21 12:42 linux,phandle
-r--r--r--  1 root root 14 Aug 21 12:42 name
-r--r--r--  1 root root  4 Aug 21 12:42 reg
-r--r--r--  1 root root  4 Aug 21 12:42 timebase-frequency


This is a js20, also under SLOF

kpblade4:/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED] # ls -l
total 11
-r--r--r-- 1 root root  4 2006-08-21 13:05 clock-frequency
-r--r--r-- 1 root root  4 2006-08-21 13:05 d-cache-line-size
-r--r--r-- 1 root root  4 2006-08-21 13:05 d-cache-size
-r--r--r-- 1 root root  4 2006-08-21 13:05 device_type
-r--r--r-- 1 root root  8 2006-08-21 13:05 ibm,pft-size
-r--r--r-- 1 root root  4 2006-08-21 13:05 i-cache-line-size
-r--r--r-- 1 root root  4 2006-08-21 13:05 i-cache-size
-r--r--r-- 1 root root  4 2006-08-21 13:05 linux,phandle
-r--r--r-- 1 root root 12 2006-08-21 13:05 name
-r--r--r-- 1 root root  4 2006-08-21 13:05 reg
-r--r--r-- 1 root root  4 2006-08-21 13:05 timebase-frequency


Notice that d-cache-sets is is not there and neither is the entire 
directory l2-cache




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

Re: [XenPPC] [PATCH] Fix compilation errors

2006-08-21 Thread Maria Butrico 
I am not sure what this means.  The code from the hg repository still 
does not compile.



Jimi Xenidis wrote:


On Aug 20, 2006, at 9:58 PM, Maria Butrico wrote:


Summary:  Allow compilation under gcc4

diff -r dbe9249ba61b xen/arch/powerpc/oftree.h


I covered the current.h issues with dan, how about this for oftree.h, 
it clean up some too:


diff -r 792d2d89749a xen/arch/powerpc/ofd_fixup.c
--- a/xen/arch/powerpc/ofd_fixup.cMon Aug 21 06:57:14 2006 -0400
+++ b/xen/arch/powerpc/ofd_fixup.cMon Aug 21 07:23:48 2006 -0400
@@ -24,6 +24,7 @@
#include 
#include 
#include "of-devtree.h"
+#include "oftree.h"
#undef RTAS
@@ -440,8 +441,7 @@ static ofdn_t ofd_xen_props(void *m, str
 }
 return n;
}
-extern int ofd_dom0_fixup(
-struct domain *d, ulong oftree, start_info_t *si, ulong dst);
+
int ofd_dom0_fixup(struct domain *d, ulong mem, start_info_t *si, 
ulong eoload)

{
 void *m;
diff -r 792d2d89749a xen/arch/powerpc/oftree.h
--- a/xen/arch/powerpc/oftree.hMon Aug 21 06:57:14 2006 -0400
+++ b/xen/arch/powerpc/oftree.hMon Aug 21 07:23:48 2006 -0400
@@ -25,7 +25,7 @@ extern ulong oftree_len;
extern ulong oftree_len;
extern int ofd_dom0_fixup(
-struct domain *d, ulong oftree, start_info_t *si, ulong dst);
+struct domain *d, ulong mem, start_info_t *si, ulong dst);
extern int firmware_image_start[0];
extern int firmware_image_size[0];





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

Re: [XenPPC] xend error messages

2006-08-21 Thread Maria Butrico 

Jimi Xenidis wrote:


On Aug 19, 2006, at 4:38 PM, Maria Butrico wrote:


These are from xend-debug.log.  What do they indicate?  Are they fatal?

/home/j9/xen-tools/etc/xen/scripts/xen-network-common.sh: line 130: 
brctl: command not found
/usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The xmllib module 
is obsolete.  Use xml.sax instead.
 warnings.warn("The xmllib module is obsolete.  Use xml.sax 
instead.", DeprecationWarning)


 warnings.warn("The xmllib module is obsolete.  Use xml.sax 
instead.", DeprecationWarning)


I am not too worried about the deprecated call.


Don;t be, thats normal for the SLES-10 distro


I am worried about brctl.


Yes, you need the bridge control package:
  # yast -i bridge-utils

-JX



I installed the bridge control package. Now in xend-debug.log I see

Nothing to flush.
Nothing to flush.

I hope this is also normal.


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

Re: [XenPPC] xend error messages

2006-08-21 Thread Maria Butrico 

poff wrote:

We have xen running on an Intel blade with SuSE10; may be helpful to view scripts 
& logs...
  
Thank you Don.  Kawachiya-san also has mini-os running on x86 and I have 
his scripts.   They work for him, but not for me.



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

[XenPPC] xm error

2006-08-21 Thread Maria Butrico 
I get the same error with xm (I updated last night). 

[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:189) XendDomainInfo.create(['vm', ['name', 'J9-Lib-OS'], 
['memory', 32], ['on_crash', 'destroy'], ['vcpus', 1], ['image', 
['linux', ['kernel', '/home/j9/bin/j9')
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:295) parseConfig: config is ['vm', ['name', 
'J9-Lib-OS'], ['memory', 32], ['on_crash', 'destroy'], ['vcpus', 1], 
['image', ['linux', ['kernel', '/home/j9/bin/j9'
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:394) parseConfig: result is {'shadow_memory': None, 
'uuid': None, 'on_crash': 'destroy', 'on_reboot': None, 'localtime': 
None, 'image': ['linux', ['kernel', '/home/j9/bin/j9']], 'on_poweroff': 
None, 'bootloader_args': None, 'cpus': None, 'name': 'J9-Lib-OS', 
'backend': [], 'vcpus': 1, 'cpu_weight': None, 'features': None, 
'vcpu_avail': None, 'memory': 32, 'device': [], 'bootloader': None, 
'cpu': None, 'maxmem': None}
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:1223) XendDomainInfo.construct: None
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:1255) XendDomainInfo.initDomain: 1 1.0
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] ERROR 
(XendDomainInfo:201) Domain construction failed

Traceback (most recent call last):
 File "/home/j9/xen-tools/usr/lib/python/xen/xend/XendDomainInfo.py", 
line 194, in create

   vm.initDomain()
 File "/home/j9/xen-tools/usr/lib/python/xen/xend/XendDomainInfo.py", 
line 1333, in initDomain

   raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:1419) XendDomainInfo.destroy: domid=1
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG 
(XendDomainInfo:1427) XendDomainInfo.destroyDomain(1)





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

[XenPPC] [PATCH]

2006-08-20 Thread Maria Butrico 
Summary:  Allow compilation under gcc4

Current Xen does not compile.  Declaration shadows parameters.

Signed-off-by:  Maria Butrico <[EMAIL PROTECTED]>


diff -r dbe9249ba61b xen/arch/powerpc/oftree.h
--- a/xen/arch/powerpc/oftree.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/arch/powerpc/oftree.h Sun Aug 20 21:19:04 2006 -0400
@@ -25,7 +25,7 @@ extern ulong oftree_len;
 extern ulong oftree_len;
 
 extern int ofd_dom0_fixup(
-struct domain *d, ulong oftree, start_info_t *si, ulong dst);
+struct domain *d, ulong oftree1, start_info_t *si, ulong dst);
 
 extern int firmware_image_start[0];
 extern int firmware_image_size[0];
diff -r dbe9249ba61b xen/include/asm-powerpc/current.h
--- a/xen/include/asm-powerpc/current.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/include/asm-powerpc/current.h Sun Aug 20 21:16:02 2006 -0400
@@ -66,7 +66,7 @@ static inline struct cpu_user_regs *gues
 
 static inline void reset_stack_and_jump(void (*f)(void))
 {
-void _reset_stack_and_jump(void (*f)(void), struct cpu_user_regs *regs);
+void _reset_stack_and_jump(void (*f1)(void), struct cpu_user_regs *regs);
 struct cpu_user_regs *regs = guest_cpu_user_regs();
 
 #ifdef TRACK_RESUME



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

[XenPPC] [PATCH] Fix compilation errors

2006-08-20 Thread Maria Butrico 
Summary:  Allow compilation under gcc4

Current Xen does not compile.  Declaration shadows parameters.

Signed-off-by:  Maria Butrico <[EMAIL PROTECTED]>


diff -r dbe9249ba61b xen/arch/powerpc/oftree.h
--- a/xen/arch/powerpc/oftree.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/arch/powerpc/oftree.h Sun Aug 20 21:19:04 2006 -0400
@@ -25,7 +25,7 @@ extern ulong oftree_len;
 extern ulong oftree_len;
 
 extern int ofd_dom0_fixup(
-struct domain *d, ulong oftree, start_info_t *si, ulong dst);
+struct domain *d, ulong oftree1, start_info_t *si, ulong dst);
 
 extern int firmware_image_start[0];
 extern int firmware_image_size[0];
diff -r dbe9249ba61b xen/include/asm-powerpc/current.h
--- a/xen/include/asm-powerpc/current.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/include/asm-powerpc/current.h Sun Aug 20 21:16:02 2006 -0400
@@ -66,7 +66,7 @@ static inline struct cpu_user_regs *gues
 
 static inline void reset_stack_and_jump(void (*f)(void))
 {
-void _reset_stack_and_jump(void (*f)(void), struct cpu_user_regs *regs);
+void _reset_stack_and_jump(void (*f1)(void), struct cpu_user_regs *regs);
 struct cpu_user_regs *regs = guest_cpu_user_regs();
 
 #ifdef TRACK_RESUME



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

[XenPPC] shadow.c

2006-08-20 Thread Maria Butrico 
#include 
#include 
#include 
#include 

int shadow_control_op(struct domain *d, 
  dom0_shadow_control_t *sc,
  XEN_GUEST_HANDLE(dom0_op_t) u_dom0_op)
{
if ( unlikely(d == current->domain) )
{
DPRINTK("Don't try to do a shadow op on yourself!\n");
return -EINVAL;
}

switch ( sc->op )
{
case DOM0_SHADOW_CONTROL_OP_OFF:
return 0;

case DOM0_SHADOW2_CONTROL_OP_GET_ALLOCATION:
sc->mb = 0;
return 0;
case DOM0_SHADOW2_CONTROL_OP_SET_ALLOCATION:
if (sc->mb > 0) {
BUG();
return -ENOMEM;
}
return 0;

default:
printk("Bad shadow op %u\n", sc->op);
BUG();
return -EINVAL;
}
}

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

[XenPPC] shadow.c

2006-08-20 Thread Maria Butrico 

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

[XenPPC] xen does not compile where is shadow.c?

2006-08-20 Thread Maria Butrico 

I get lots of shadow errors.  patch forthcoming.  Where is shadow.c?




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

[XenPPC] xm use

2006-08-20 Thread Maria Butrico 

From the wiki

Ramdisk: Since we do not have VIO yet you will have to use a ramdisk fro 
your rootf, one is available from this link 
.


Err, my tiny does not need any disk or vio.  I am not starting linux.  
Do I still need a ramdisk (and if so what for?). 



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

Re: [XenPPC] new dom1 script, ok.. we are back to normal functionality,

2006-08-20 Thread Maria Butrico 

Jimi Xenidis wrote:
I managed to introduce a bug during my first merge, and we have shadow 
ops to deal with.


Sorry for the inconvenience, Here is my latest dom1 script.

you can get the ramdisk.image.gz from:
  
http://wiki.xensource.com/xenwiki/XenPPC/Build?action=AttachFile&do=get&target=ramdisk.image.gz 



after you make sure that dom1 and amdisk.image.gz are in /root,  
simply (as root, in /root):

  # xm create -c dom1


-JX



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

Are the problems with the tools also fixed?


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

[XenPPC] [PATCH] Fix compilation error in tools

2006-08-19 Thread Maria Butrico 
Summary:  Fixes compilation error

Unmodified (without patch) code does not compile on stock SLES10 systems.

Signed-off-by:  Maria Butrico  <[EMAIL PROTECTED]>

diff -r 279843441136 tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.cWed Aug 16 17:19:38 2006 -0500
+++ b/tools/libxc/powerpc64/xc_linux_build.cSat Aug 19 18:43:16 2006 -0400
@@ -173,7 +173,7 @@ static int load_devtree(
 struct boot_param_header *header;
 uint64_t *prop;
 unsigned int devtree_size;
-unsigned int proplen;
+int proplen;
 int rc = 0;
 
 header = devtree;

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

[XenPPC] domain creation error

2006-08-19 Thread Maria Butrico 
I am trying to create a domain.  The error I receive from xm is very 
generic and I cannot readily see what is wrong:


This is what I get

xm create xen-domain-config
Using config file "xen-domain-config".
/usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The xmllib module is 
obsolete.  Use xml.sax instead.
 warnings.warn("The xmllib module is obsolete.  Use xml.sax instead.", 
DeprecationWarning)

Error: (22, 'Invalid argument')

My configuration file is very simple:
#  -*- mode: python; -*-
#
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 
'xm create'.

# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#

#
# Kernel image file.
kernel = "/home/j9/bin/j9"

# Initial memory allocation (in megabytes) for the new domain.
memory = 32

# A name for your domain. All domains must have different names.
name = "J9-Lib-OS"

on_crash = 'destroy'



From xend.log

[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:186) XendDomainInfo.create(['vm', ['name', 'J9-Lib-OS'], 
['memory', 32], ['on_crash', 'destroy'], ['vcpus', 1], ['image', 
['linux', ['kernel', '/home/j9/bin/j9')
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:292) parseConfig: config is ['vm', ['name', 
'J9-Lib-OS'], ['memory', 32], ['on_crash', 'destroy'], ['vcpus', 1], 
['image', ['linux', ['kernel', '/home/j9/bin/j9'
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:391) parseConfig: result is {'uuid': None, 'on_crash': 
'destroy', 'on_reboot': None, 'localtime': None, 'image': ['linux', 
['kernel', '/home/j9/bin/j9']], 'on_poweroff': None, 'bootloader_args': 
None, 'cpus': None, 'name': 'J9-Lib-OS', 'backend': [], 'vcpus': 1, 
'cpu_weight': None, 'features': None, 'vcpu_avail': None, 'memory': 32, 
'device': [], 'bootloader': None, 'cpu': None, 'maxmem': None}
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:1219) XendDomainInfo.construct: None
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:1251) XendDomainInfo.initDomain: 1 1.0
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] ERROR 
(XendDomainInfo:198) Domain construction failed

Traceback (most recent call last):
 File "/home/j9/xen-tools/usr/lib/python/xen/xend/XendDomainInfo.py", 
line 191, in create

   vm.initDomain()
 File "/home/j9/xen-tools/usr/lib/python/xen/xend/XendDomainInfo.py", 
line 1318, in initDomain

   raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:1404) XendDomainInfo.destroy: domid=1
[2006-08-19 20:39:03 xend.XendDomainInfo 4453] DEBUG 
(XendDomainInfo:1412) XendDomainInfo.destroyDomain(1)






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

[XenPPC] xend error messages

2006-08-19 Thread Maria Butrico 

These are from xend-debug.log.  What do they indicate?  Are they fatal?

/home/j9/xen-tools/etc/xen/scripts/xen-network-common.sh: line 130: 
brctl: command not found
/usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The xmllib module is 
obsolete.  Use xml.sax instead.
 warnings.warn("The xmllib module is obsolete.  Use xml.sax instead.", 
DeprecationWarning)


 warnings.warn("The xmllib module is obsolete.  Use xml.sax instead.", 
DeprecationWarning)


I am not too worried about the deprecated call.  I am worried about brctl.




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

[XenPPC] xm and xend use

2006-08-18 Thread Maria Butrico 
Are there debug option of any sort for these two?  debug build options? 

PS: Send more memory, anytime. 



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

[XenPPC] packages needed to support xen tools

2006-08-16 Thread Maria Butrico 

From the xen/ppc wiki:
---
For convenience, here is a list of rpms I needed for Dom0 running 
SLES-10 *libgcrypt-devel*, *glibc-devel*, *python-devel*, 
*ncurses-devel-5.5-18*, *zlib-devel*, *openssl-devel*, and *gcc*.




I am looking at the sles10 install dvd  images.  We have

libgcrypt-devel-1.2.2-13.2.ppc.rpm  and 
libgcrypt-devel-64bit-1.2.2-13.2.ppc.rpm


./suse/ppc/glibc-devel-2.4-31.2.ppc.rpm
./suse/ppc/glibc-devel-64bit-2.4-31.2.ppc.rpm

./suse/ppc/ncurses-devel-5.5-18.2.ppc.rpm
./suse/ppc/ncurses-devel-64bit-5.5-18.2.ppc.rpm

./suse/ppc/zlib-devel-1.2.3-15.2.ppc.rpm
./suse/ppc/zlib-devel-64bit-1.2.3-15.2.ppc.rpm

./suse/ppc/openssl-devel-0.9.8a-18.4.ppc.rpm
./suse/ppc/openssl-devel-64bit-0.9.8a-18.4.ppc.rpm

and a whole bunch of gcc.

Which ones are the ones I want?

(There is only one python-devel)






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

Re: [XenPPC] mini-os

2006-08-16 Thread Maria Butrico 
Mini-os on x86 seems to work.  Someone working with us has successfully 
augmented it with a stripped down version of the J9 JVM.


I have another question related to small, non-linux, os'es that can be 
used as a model to build a domU for xen/ppc.  I am basically redoing a 
similar thing, that is a small domU with a stipped down JVM.  I was 
hoping to start with a working, small os .  Are there any out there that 
have been ported to Xen/ppc? 


Hollis Blanchard wrote:

On Tue, 2006-08-15 at 15:13 -0400, Maria Butrico wrote:
  

What is the correct invocation for building mini-os for powerpc?



I don't believe anybody has ever tried it. In fact I seem to recall
hearing that for a while mini-os didn't even work for x86-64, so I have
grave doubts as to its portability. I haven't even glanced at it myself.

  




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

[XenPPC] mini-os

2006-08-15 Thread Maria Butrico 

What is the correct invocation for building mini-os for powerpc?

Maria Butrico


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

[Fwd: Re: [XenPPC] wiki instructions]

2006-08-14 Thread Maria Butrico 
Jimi was right this time.  After raising the issue, I think I should 
clarify for all. 
--- Begin Message ---
Jimi, you are correct.  Orran and I were having some issues, but I 
cannot verify that any of the changes we made were related to this.  I 
will update my build scripts.


Jimi Xenidis wrote:


On Aug 14, 2006, at 12:56 PM, Maria Butrico wrote:


The wiki at http://wiki.xensource.com/xenwiki/XenPPC/Build states

if your cross toolchain is not capable of generating both 64-bit and 
32-bit code then you will have to add 
CROSS32_COMPILE=powerpc-unknown-linux-gnu- to all you Linux building 
commands.


I have been iusing CROSS_COMPILE32.  Is this a type or would both work?


hmm, WRT to Linux, _only_ CROSS32_COMPILE should work.
If CROSS_COMPILE32 then nothing special will happen and your compiler 
you defined with CROSS_COMPILER can handle both.




Also it states:

make -C ~/xen/xenppc-unstable.hg/xen 
DOM0_IMAGE=~/xen/linux/xen/arch/powerpc/boot/zImage


Is zImage also supposed to work in this command.  I use vmlinux.strip.


Yes a zImage can now be used (and vmlinux* will also work), it results 
in a much smaller image and can allow you to imbed a ramdisk if you wish.


Details:
  
http://lists.xensource.com/archives/html/xen-ppc-devel/2006-06/msg00294.html 



-JX







--- End Message ---
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] wiki instructions

2006-08-14 Thread Maria Butrico 

The wiki at http://wiki.xensource.com/xenwiki/XenPPC/Build states

if your cross toolchain is not capable of generating both 64-bit and 
32-bit code then you will have to add 
CROSS32_COMPILE=powerpc-unknown-linux-gnu- to all you Linux building 
commands.


I have been iusing CROSS_COMPILE32.  Is this a type or would both work?

Also it states:

make -C ~/xen/xenppc-unstable.hg/xen 
DOM0_IMAGE=~/xen/linux/xen/arch/powerpc/boot/zImage

Is zImage also supposed to work in this command.  I use vmlinux.strip.  





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

[XenPPC] building xen in separate build directory

2006-08-11 Thread Maria Butrico 
Is there a make option to build xen (for ppc) in such a a way that the 
object files and the rest of the output of make will go in a 
subdirectory other than the one where the source is?



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

Re: [XenPPC] Booting xen_maple_defconfig kernel on bare hardware

2006-07-27 Thread Maria Butrico 

Maria Butrico wrote:

Maria Butrico wrote:


You are correct.  The output is stopping, but the machine is up.  I 
cannot ssh to it tho, but I can ping it.  It has been more than 15 
minutes since I rebooted so it's not that it has not had time to 
start all the things.  How far did you get and did you see all the 
console output?  I was using the nfsroot from kmac and I retried with 
the ones on kreg.   Things improved once I removed the console= 
directive from the command line.  Now I see why sshd and a few other 
things did not start.  My message is


/etc/init.d/sshd start
* Starting sshd...modprobe: FATAL: Could not load 
/lib/modules/2.6.17-Xen/modules.dep: No such file or directory


I am sending to the entire list as things might be of general 
interest again.




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

This is a portion of the console output

+ mount -n -t devfs none /dev
modprobe: FATAL: Could not load /lib/modules/2.6.17-Xen/modules.dep: 
No such file or directory


mount: unknown filesystem type 'devfs'



+ /etc/init.d/sshd start
* Starting sshd...modprobe: FATAL: Could not load 
/lib/modules/2.6.17-Xen/modules.dep: No such file or directory



Err.  Turns out that sshd started after all.  The message was 
deceiving.   So in fact, we get a working system even with the gentoo 
nfsroot.   As I said in another note, the kernel can also use the SLES10 
rootfs, at least on a js20. 


Err



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

Re: [XenPPC] Booting xen_maple_defconfig kernel on bare hardware

2006-07-27 Thread Maria Butrico 

Amos Waterland wrote:

It would be nice to boot the exact same Linux kernel binary image on
bare hardware and as a Xen dom0 on that same hardware.  At present we
cannot do this: you stop seeing output early in the boot process.

I spent some time using OF output routines to track down the problem,
and it turns out that CONFIG_XEN_DISABLE_SERIAL=y disables all standard
serial device drivers.  So when you boot a kernel compiled with
CONFIG_XEN on bare hardware you stop seeing any output after the RTC is
probed, but the real problem occurs much later when Linux panics because
it can't open an initial console.

The below patch (not for submission) allows the same Linux kernel image to
boot as a dom0 and on bare JS20 hardware.  Note that this patch applies on
top of the "refresh xen_maple_defconfig" patch sent earlier.

The reason it is not for submission is that while it boots on bare JS21
hardware, it fails to boot as a dom0 on the same hardware.  The console
spews a lot of garbage characters and external networking never comes up.

So CONFIG_XEN_DISABLE_SERIAL probably needs turn on some intelligent
runtime probing of whether we are running on bare hardware or on Xen.
If the former, do nothing, if the latter, remove the serial devices from
the list of available consoles.  No?

  


On our js20 (kpblade4, for those at watson) where I managed to install 
SLES10 I was able to boot the xen kernel with the modification indicated 
by Amos using the sles10 rootfs from disk.  A few things failed, but 
overall it was better than expected.  I built the linux kernel with the 
following configuration.


CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="root=/dev/hda3 
ip=9.2.129.5::9.2.129.2:255.255.255.0:kpblade4:eth1:off"





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

Re: [XenPPC] Booting xen_maple_defconfig kernel on bare hardware

2006-07-27 Thread Maria Butrico 

Maria Butrico wrote:


You are correct.  The output is stopping, but the machine is up.  I 
cannot ssh to it tho, but I can ping it.  It has been more than 15 
minutes since I rebooted so it's not that it has not had time to start 
all the things.  How far did you get and did you see all the console 
output?  I was using the nfsroot from kmac and I retried with the ones 
on kreg.   Things improved once I removed the console= directive from 
the command line.  Now I see why sshd and a few other things did not 
start.  My message is


/etc/init.d/sshd start
* Starting sshd...modprobe: FATAL: Could not load 
/lib/modules/2.6.17-Xen/modules.dep: No such file or directory


I am sending to the entire list as things might be of general interest 
again.




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

This is a portion of the console output

+ mount -n -t devfs none /dev
modprobe: FATAL: Could not load /lib/modules/2.6.17-Xen/modules.dep: No 
such file or directory


mount: unknown filesystem type 'devfs'



+ /etc/init.d/sshd start
* Starting sshd...modprobe: FATAL: Could not load 
/lib/modules/2.6.17-Xen/modules.dep: No such file or directory



And a few others. 



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

Re: [XenPPC] Booting xen_maple_defconfig kernel on bare hardware

2006-07-27 Thread Maria Butrico 


You are correct.  The output is stopping, but the machine is up.  I 
cannot ssh to it tho, but I can ping it.  It has been more than 15 
minutes since I rebooted so it's not that it has not had time to start 
all the things.  How far did you get and did you see all the console 
output?  I was using the nfsroot from kmac and I retried with the ones 
on kreg.   Things improved once I removed the console= directive from 
the command line.  Now I see why sshd and a few other things did not 
start.  My message is


/etc/init.d/sshd start
* Starting sshd...modprobe: FATAL: Could not load 
/lib/modules/2.6.17-Xen/modules.dep: No such file or directory


I am sending to the entire list as things might be of general interest 
again. 





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

Re: [XenPPC] noHV status

2006-07-26 Thread Maria Butrico 

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@lists.xensource.com
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: 07ffe000
(XEN) shared_info: 0x3fff000,0

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