|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.4-testing test] 26423: regressions - FAIL
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@xxxxxxxxxx> Don Slutz <dslutz@xxxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jason Andryuk <andryuk@xxxxxxxx> Julien Grall <julien.grall@xxxxxxxxxx> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Roger Pau Monne <roger.pau@xxxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> ------------------------------------------------------------ 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@xxxxxxxxxx> 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@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit 6f4ff742a5caa411397fc38233f818e64a0c541c) commit 29d303db896fcebae62351ead8fc429afa0a1f0e Author: Ian Campbell <ian.campbell@xxxxxxxxxx> 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@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> [ ijc -- s/itherwise/otherwise and dropped bogus emacs magic change ] (cherry picked from commit 314c9815e2f5dc8a9fec11e0cf9b49b16ed0e96b) commit 131fa5672a7fb349dd8c44315b1bea8b182efe1c Author: Jason Andryuk <andryuk@xxxxxxxx> 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@xxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit 86216963fd1d89883bb8120535704fdc79fdad50) commit 6c6cc5af3d5ee0477651f4b3e63230403269f8c5 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: coverity@xxxxxxxxxxxxxx (cherry picked from commit c566ab68af7da089ae2b0ff664d02a93a0647584) commit 3aaa40fd582764c89126d48a13931d2221e33e04 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxx> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (cherry picked from commit 81b03050485708698ce2245d9abefce07aafb704) commit 5ee75ef147f83457fa28d4d4374efcf066581e26 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit d75215805ce6ed20b3807955fab6a7f7a3368bee) commit d6eff6fcc05f7167e5b2232d3bc60047fffb8fc4 Author: Wei Liu <wei.liu2@xxxxxxxxxx> 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@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit 3eb54a2fdbc216b39dc2c0a86f11a32d4c838269) commit 6ce0c3fca9bd1c0d45908452d6e5e9f7bf22f7b7 Author: Julien Grall <julien.grall@xxxxxxxxxx> 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@xxxxxxxxxx> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> (cherry picked from commit ac0f56a2fa407e0704fade12630a5a960dedce87) commit c32c41e21f8b2d16f98f50b9ddbd37ae656fc020 Author: Roger Pau Monne <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxx> Tested-by: Don Slutz <dslutz@xxxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Cc: Ian Jackson <ian.jackson@xxxxxxxxxx> (cherry picked from commit a37c389930936c3a9b1215c385fdd22854836871) (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |