I am part of the Unisys xen team. We plan to run xm-test weekly and post the
results.
Here is our first posting.
April 25, 2006
Configuration:
SLES 10 Beta 10
Unisys ES7000/1
x86_64
32 processors
16 GB RAM
xen-unstable changeset 9734
Xm-test execution summary:
PASS: 108
FAIL: 7
XPASS: 0
XFAIL: 3
Details:
FAIL: 13_create_multinic_pos
(7 nics) Console didn''t respond probably crashed!
FAIL: 01_enforce_dom0_cpus_basic_pos
/proc/cpuinfo says xend didn''t enforce dom0_cpus (30 != 1)
FAIL: 01_memset_basic_pos
DomU reported incorrect memory amount 59 MB
FAIL: 03_memset_random_pos
Expected 61 MB, domU reported 59 MB
XFAIL: 02_network_local_ping_pos
ping loopback failed for size 65507. ping eth0 failed for size 65507.
XFAIL: 05_network_dom0_ping_pos
Ping to dom0 failed for size 65507.
XFAIL: 11_network_domU_ping_pos
Ping failed for size 65507.
Sue Krysan
Linux Systems Group
Unisys Corporation
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Tue, Apr 25, 2006 at 03:52:58PM -0400, Krysan, Susan wrote:> I am part of the Unisys xen team. We plan to run xm-test weekly and post the results. > > Here is our first posting. > > April 25, 2006 > > Configuration: > > SLES 10 Beta 10 > Unisys ES7000/1 > x86_64 > 32 processors > 16 GB RAM > xen-unstable changeset 9734 > > Xm-test execution summary: > PASS: 108 > FAIL: 7 > XPASS: 0 > XFAIL: 3 > > > Details: > > FAIL: 13_create_multinic_pos > (7 nics) Console didn''t respond probably crashed! > > FAIL: 01_enforce_dom0_cpus_basic_pos > /proc/cpuinfo says xend didn''t enforce dom0_cpus (30 != 1) > > FAIL: 01_memset_basic_pos > DomU reported incorrect memory amount 59 MB > > FAIL: 03_memset_random_pos > Expected 61 MB, domU reported 59 MBWill you be drilling down into these failures? That would certainly be appreciated. The memset failures happen only on 64-bit platforms, and no-one''s had time to figure out whether this is a conversion issue somewhere in the test or Xend or Xen itself. The enforce_dom0_cpus failure is odd, given that 30 is neither the number of physical CPUs, nor a power of two, nor the number that was requested! The multinic crash is certainly a real kernel bug, and a backtrace or some debugging for that would be very useful too. Thanks, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan, We are looking into the xm-test failures. regarding> FAIL: 01_enforce_dom0_cpus_basic_pos > /proc/cpuinfo says xend didn''t enforce dom0_cpus (30 != 1)We noticed that when this test resets dom0_cpus to 1 it takes a few seconds for /proc/cpuinfo to reduce from 32 processors to 1 processor. So we put in a sleep of 10 seconds in the test script, right before it checks /proc/cpuinfo. Then the test succeeds. We see the same failure with 16 processors, but not 8 processors. Should this test be patched to introduce a sleep statement for systems with 16 or more processors? Thanks, Sue Krysan Linux Systems Group Unisys Corporation -----Original Message----- From: Ewan Mellor [mailto:ewan@xensource.com] Sent: Wednesday, April 26, 2006 6:42 PM To: Krysan, Susan Cc: xen-devel@lists.xensource.com; Vessey, Bruce A; Ikhizgilov, Timur; Carb, Brian A Subject: Re: [Xen-devel] xm-test results On Tue, Apr 25, 2006 at 03:52:58PM -0400, Krysan, Susan wrote:> I am part of the Unisys xen team. We plan to run xm-test weekly and post the results. > > Here is our first posting. > > April 25, 2006 > > Configuration: > > SLES 10 Beta 10 > Unisys ES7000/1 > x86_64 > 32 processors > 16 GB RAM > xen-unstable changeset 9734 > > Xm-test execution summary: > PASS: 108 > FAIL: 7 > XPASS: 0 > XFAIL: 3 > > > Details: > > FAIL: 13_create_multinic_pos > (7 nics) Console didn''t respond probably crashed! > > FAIL: 01_enforce_dom0_cpus_basic_pos > /proc/cpuinfo says xend didn''t enforce dom0_cpus (30 != 1) > > FAIL: 01_memset_basic_pos > DomU reported incorrect memory amount 59 MB > > FAIL: 03_memset_random_pos > Expected 61 MB, domU reported 59 MBWill you be drilling down into these failures? That would certainly be appreciated. The memset failures happen only on 64-bit platforms, and no-one''s had time to figure out whether this is a conversion issue somewhere in the test or Xend or Xen itself. The enforce_dom0_cpus failure is odd, given that 30 is neither the number of physical CPUs, nor a power of two, nor the number that was requested! The multinic crash is certainly a real kernel bug, and a backtrace or some debugging for that would be very useful too. Thanks, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, May 03, 2006 at 03:56:07PM -0400, Krysan, Susan wrote:> Ewan, > We are looking into the xm-test failures. > > regarding > > FAIL: 01_enforce_dom0_cpus_basic_pos > > /proc/cpuinfo says xend didn''t enforce dom0_cpus (30 != 1) > > We noticed that when this test resets dom0_cpus to 1 it takes a few seconds > for /proc/cpuinfo to reduce from 32 processors to 1 processor. So we put in > a sleep of 10 seconds in the test script, right before it checks > /proc/cpuinfo. Then the test succeeds. We see the same failure with 16 > processors, but not 8 processors. Should this test be patched to introduce > a sleep statement for systems with 16 or more processors?That''s great work, thanks. It''s nice to know that it''s the test that''s broken, not the code ;-) A sleep would be fine, but even better than that would be a loop that monitors /proc/cpuinfo, waiting for it to come down to 1 (with a timeout of course). That way, we are guaranteed to wait exactly long enough, and no longer. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> A sleep would be fine, but even better than that would be a loop that > monitors > /proc/cpuinfo, waiting for it to come down to 1 (with a timeout of > course). > That way, we are guaranteed to wait exactly long enough, and nolonger. Ewan, Your method looks better than a just a sleep. We will check in a patch for this. Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel