WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: xm-test Was: [XenPPC] [xenppc-unstable] [TOOLS][XM-TEST] *


On Oct 10, 2006, at 12:54 PM, Jimi Xenidis wrote:

These patches mostly from Tony allow us to run xm-test to completion.
There is no claim that all of these work, but at least we are able to generate reports. See http://wiki.xensource.com/xenwiki/XenPPC/Run/XM-Test for more info.

Here is the passfail output of the default test suite (no analysis has been done yet):

REASON: block-attach failed: device did not switch to Connected state
FAIL: 01_block_attach_device_pos.test

REASON: block-attach failed: device did not switch to Connected state
FAIL: 02_block_attach_file_device_pos.test

REASON: Device is not actually attached to domU
FAIL: 04_block_attach_device_repeatedly_pos.test

Ok, so xm-test is not all the way there.
The above failures are cause by the xm-test python script creatin an incorrect Domain script:

the scrip tbuild for 01_block_attach_device_pos.test is missing the "disk=" definition.

# cat /tmp/xm-test.conf
# Xen configuration generated by xm-test
ramdisk = "/root/work/xen/xenppc-unstable.hg/tools/xm-test/ramdisk/ initrd.img"
kernel = "/boot/vmlinux-2.6.17-Xen"
name = "01_block_attach_device_pos-1160358219"
extra = "xencons=tty128 console=tty128"
vcpus = 1
memory = 64
root = "/dev/ram0"

This is not easily fixed AFAICT.
Any thougths on this would be appreciated.
-JX



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