* [xen-4.4-testing test] 26423: regressions - FAIL
@ 2014-05-23 16:21 xen.org
0 siblings, 0 replies; only message in thread
From: xen.org @ 2014-05-23 16:21 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
[-- Attachment #1: Type: text/plain, Size: 16327 bytes --]
flight 26423 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/26423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-localmigrate/x10 fail REGR. vs. 26293
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail REGR. vs. 26293
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 26293
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass
test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail never pass
test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
version targeted for testing:
xen 5e6c1c306330ceeb12d3bd2315db86de76bf0e36
baseline version:
xen fed8691385b5a849d8fb938630a9cce97348c8a5
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Don Slutz <dslutz@verizon.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jason Andryuk <andryuk@aero.org>
Julien Grall <julien.grall@linaro.org>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------
jobs:
build-amd64-xend pass
build-i386-xend pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 fail
test-amd64-i386-rumpuserxen-i386 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 5e6c1c306330ceeb12d3bd2315db86de76bf0e36
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Apr 9 12:51:14 2014 +0100
tools: arm: improve placement of initial modules.
314c9815e2f5 "tools: implement initial ramdisk support for ARM." broke starting
guests with <= 128 MB ram by placing the boot modules (dtb and initrd)
immediately after the kernel in this case, running the risk of them being
overwritten. Instead place the modules at the end of RAM, as the hypervisor
does for dom0.
The hypervisor also falls back to placing things before the kernel as a last
resort before failing, so add that here too.
Tested with the Debian installer initrd and guests of 96MB, 128MB, 256MB and
1GB. All work, also tested with 64MB but the installer doesn't run with so
little RAM (but our placement of the initrd is correct).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 6f4ff742a5caa411397fc38233f818e64a0c541c)
commit 29d303db896fcebae62351ead8fc429afa0a1f0e
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Apr 4 14:28:45 2014 +0100
tools: implement initial ramdisk support for ARM.
The ramdisk is passed to the kernel as a property in the chosen node of the
device tree. This is somewhat tricky since in order to place the ramdisk and
dtb in ram we first need to know the size of the dtb. So we initially create a
DTB with placeholders for the ramdisk and finalise the value (which doesn't
change the size) once we know where everything is.
Rename libxl__arch_domain_configure to xl__arch_domain_init_hw_description to
better reflect its use and to be consistent with the new
libxl__arch_domain_finalise_hw_description.
The common xc_dom_build_image() function did not support explicit placement of
the ramdisk, instead passing 0 to xc_dom_alloc_segment, meaning "pick
somewhere". This change instead passes ramdisk_seg.vstart. If nothing has set
vstart then it will be zero because the entire dom struct is zeroed on
allocation in xc_dom_allocate(). Therefore there is no change to the behaviour
on x86. This is also consistent with how other segments (kernel, dtb) are
handled.
Furthermore if the ramdisk has been explicitly placed then xc_dom_build_image()
assumes that it is not to be decompressed (since that would muck up the sizings
used on placement).
With all that I'm able to boot a domain using the current Debian Jessie armhf
installer initrd and have it complete successfully.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
[ ijc -- s/itherwise/otherwise and dropped bogus emacs magic change ]
(cherry picked from commit 314c9815e2f5dc8a9fec11e0cf9b49b16ed0e96b)
commit 131fa5672a7fb349dd8c44315b1bea8b182efe1c
Author: Jason Andryuk <andryuk@aero.org>
Date: Fri May 16 16:41:17 2014 -0400
libxc: Free logger after printing error message
On error, PERROR calls the already destroyed logger, which can segfault.
Re-order the calls, so the logger is still available.
Signed-off-by: Jason Andryuk <andryuk@aero.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 86216963fd1d89883bb8120535704fdc79fdad50)
commit 6c6cc5af3d5ee0477651f4b3e63230403269f8c5
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed Feb 19 14:03:29 2014 +0000
libxl: Fix error path in libxl_device_events_handler
libxl_device_events_handler would fail to call AO_ABORT if it failed;
instead it would simply return rc. (This leaves the egc etc. from the
now-abolished stack frame potentially live, and leaves the ctx
locked.)
In xl, this is of no consequence, because xl will immediately exit in
this situation. This is very likely to be true in any other callers
(of which we don't know of any, anyway).
Coverity-ID: 1181840
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CC: coverity@xenproject.org
(cherry picked from commit c566ab68af7da089ae2b0ff664d02a93a0647584)
commit 3aaa40fd582764c89126d48a13931d2221e33e04
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Feb 18 15:59:05 2014 +0000
tools/libxl: Don't read off the end of tinfo[]
It is very common for BIOSes to advertise more cpus than are actually present
on the system, and mark some of them as offline. This is what Xen does to
allow for later CPU hotplug, and what BIOSes common to multiple different
systems do to to save fully rewriting the MADT in memory.
An excerpt from `xl info` might look like:
...
nr_cpus : 2
max_cpu_id : 3
...
Which shows 4 CPUs in the MADT, but only 2 online (as this particular box is
the dual-core rather than the quad-core SKU of its particular brand)
Because of the way Xen exposes this information, a libxl_cputopology array is
bounded by 'nr_cpus', while cpu bitmaps are bounded by 'max_cpu_id + 1'.
The current libxl code has two places which erroneously assume that a
libxl_cputopology array is as long as the number of bits found in a cpu
bitmap, and valgrind complains:
==14961== Invalid read of size 4
==14961== at 0x407AB7F: libxl__get_numa_candidate (libxl_numa.c:230)
==14961== by 0x407030B: libxl__build_pre (libxl_dom.c:167)
==14961== by 0x406246F: libxl__domain_build (libxl_create.c:371)
...
==14961== Address 0x4324788 is 8 bytes after a block of size 24 alloc'd
==14961== at 0x402669D: calloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==14961== by 0x4075BB9: libxl__zalloc (libxl_internal.c:83)
==14961== by 0x4052F87: libxl_get_cpu_topology (libxl.c:4408)
==14961== by 0x407A899: libxl__get_numa_candidate (libxl_numa.c:342)
...
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
(cherry picked from commit 81b03050485708698ce2245d9abefce07aafb704)
commit 5ee75ef147f83457fa28d4d4374efcf066581e26
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sat May 10 02:18:33 2014 +0100
tools/pygrub: Fix error handling if no valid partitions are found
If no partitions at all are found, pygrub never creates the name 'fs',
resulting in a NameError indicating the lack of fs, rather than a
RuntimeError explaining that no partitions were found.
Set fs to None right at the start, and use the pythonic idiom "if fs is None:"
to protect against otherwise valid values for fs which compare equal to
0/False.
Reported-by: Sven Köhler <sven.koehler@gmail.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit d75215805ce6ed20b3807955fab6a7f7a3368bee)
commit d6eff6fcc05f7167e5b2232d3bc60047fffb8fc4
Author: Wei Liu <wei.liu2@citrix.com>
Date: Wed Apr 9 14:29:13 2014 +0100
libxl_json: remove extra "break"
... otherwise JSON array elements are not freed and memory is leaked.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 3eb54a2fdbc216b39dc2c0a86f11a32d4c838269)
commit 6ce0c3fca9bd1c0d45908452d6e5e9f7bf22f7b7
Author: Julien Grall <julien.grall@linaro.org>
Date: Fri Apr 4 11:13:32 2014 +0200
tmem: remove dumb check in do_tmem_destroy_pool
do_tmem_destroy_pool is checking if pools == NULL. But, pools is a fixed
array.
Clang 3.5 will fail to compile xen/common/tmem.c with the following error:
tmem.c:1848:18: error: comparison of array 'client->pools' equal to a null
pointer is always false [-Werror,-Wtautological-pointer-compare]
if ( client->pools == NULL )
Coverity-ID:1055632
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(cherry picked from commit ac0f56a2fa407e0704fade12630a5a960dedce87)
commit c32c41e21f8b2d16f98f50b9ddbd37ae656fc020
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue Feb 11 11:38:24 2014 +0100
tools: require OCaml version 3.09.3 or greater
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Tested-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com>
(cherry picked from commit a37c389930936c3a9b1215c385fdd22854836871)
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2014-05-23 16:21 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-23 16:21 [xen-4.4-testing test] 26423: regressions - FAIL xen.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).