* [xen-unstable test] 115037: regressions - FAIL
@ 2017-10-22 23:49 osstest service owner
2017-10-23 8:40 ` Jan Beulich
0 siblings, 1 reply; 8+ messages in thread
From: osstest service owner @ 2017-10-22 23:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 25144 bytes --]
flight 115037 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail like 114644
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 114644
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 114644
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 114644
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 114644
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qcow2 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
xen 8e77dabc58c4b6c747dfb4b948551147905a7840
baseline version:
xen 24fb44e971a62b345c7b6ca3c03b454a1e150abe
Last test of basis 114644 2017-10-17 10:49:11 Z 5 days
Failing since 114670 2017-10-18 05:03:38 Z 4 days 6 attempts
Testing same since 114808 2017-10-20 14:56:19 Z 2 days 4 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
David Esler <drumandstrum@gmail.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@linaro.org>
Roger Pau Monné <roger.pau@citrix.com>
Stefano Stabellini <sstabellini@kernel.org>
Tim Deegan <tim@xen.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd fail
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-rumprun-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 pass
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-i386-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 8e77dabc58c4b6c747dfb4b948551147905a7840
Author: Wei Liu <wei.liu2@citrix.com>
Date: Mon Oct 16 15:04:10 2017 +0100
libxl: annotate s to be nonnull in libxl__enum_from_string
Hope this can placate coverity.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 575da5ceb427ce649eb22c1aea105af147d22487
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu Oct 19 15:29:56 2017 +0100
tools/Makefile: unset MAKELEVEL before building QEMU
Since QEMU commits aef45d51d1204f3335fb99de6658e0c5612c2b67
"build: automatically handle GIT submodule checkout for dtc"
the QEMU makefiles rely on the variable MAKELEVEL to make a decision on
whether to update some git submodules or not. Since we call QEMU build
from within the Xen one, MAKELEVEL would already be greater than 0 and
the git submodules would not be updated and QEMU would fail to build.
Fix this by removing MAKELEVEL from the environment before trying to
build QEMU.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 8ba5f63d3afd59001c35b1494f0416131de439a4
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Oct 20 09:31:54 2017 +0200
gcov: support gcc 7.x
Taking Linux commit 0538421343 ("gcov: support GCC 7.1") as reference,
enable gcc 7 support requiring __gcov_exit() and having 9 counters.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 4e3fb2fb47d6403f8411727eefe2b885c6ad514e
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Fri Oct 20 09:30:13 2017 +0200
ubsan: add clang 5.0 support
clang 5.0 changed the layout of the type_mismatch_data structure and
introduced __ubsan_handle_type_mismatch_v1 and
__ubsan_handle_pointer_overflow.
This commit adds support for the new structure layout, adds the
missing handlers and the new types for type_check_kinds.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
[jb: unconditionally emit always the same message in
__ubsan_handle_pointer_overflow()]
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 78e693cc123296db2f79e792cf474544c1ffd064
Author: David Esler <drumandstrum@gmail.com>
Date: Fri Oct 20 09:29:29 2017 +0200
x86/boot: fix early error output
In 9180f5365524 a change was made to the send_chr function to take in
C-strings and output a character at a time until a NULL was encountered.
However, when there is no VGA there is no code to increment the current
character position resulting in an endless loop of the first character.
This moves the (implicit) increment such that it occurs in all cases.
Signed-off-by: David Esler <drumandstrum@gmail.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
[jb: correct title and description]
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
commit 4a1d823f70ac8182cbc5a4bd3c76beeb952e9683
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Fri Oct 20 09:27:23 2017 +0200
x86/string: fix memmove when size is 0
ubsan in clang 5.0 complains with:
(XEN) UBSAN: Undefined behaviour in string.c:50:28
(XEN) pointer overflow:
(XEN) addition of unsigned offset to ffff830000100000 overflowed to ffff8300000fffff
[...]
(XEN) Xen call trace:
(XEN) [<ffff82d0802dce0d>] ubsan.c#ubsan_epilogue+0xd/0xc0
(XEN) [<ffff82d0802de145>] __ubsan_handle_pointer_overflow+0xa5/0xe0
(XEN) [<ffff82d0803bf627>] memmove+0x67/0x80
(XEN) [<ffff82d080679f87>] page_alloc.c#bootmem_region_add+0x157/0x220
(XEN) [<ffff82d080679c66>] init_boot_pages+0x56/0x220
(XEN) [<ffff82d0806bcb9d>] __start_xen+0x2c2d/0x4b50
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x60
This is due to memmove doing a n-1+addr when n is 0. This is harmless
because the loop is bounded to 0. Fix this by returning earlier when n
is 0.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
[jb: add return value and unlikely()]
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 6ccf25d46c18ff274e68dde8c8da3c656f7699e2
Author: Julien Grall <julien.grall@linaro.org>
Date: Thu Oct 19 18:09:05 2017 +0100
xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2
Per 8.4.8 in ARM IHI 0069D, ICH_VMCR_EL2.VFIQEn is RES1 when
ICC_SRE_EL1.SRE is 1. This causes a Group 0 interrupt (as generated in
GICv2 mode) to be delivered as a FIQ to the guest, with potentially
consequence. So we must make sure that ICC_SRE_EL1 has been actually
programmed before at ICH_VMCR_EL2.
This was discovered when booting EFI in a GICv2 guest on a GICv3
hardware.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit 0c8055c2f45f489aff67f4d362f3fdc192cc2d94
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Wed Oct 18 14:29:58 2017 -0700
arm: configure interrupts to be in non-secure group1
Xen uses non-secure group1 interrupts, however it doesn't configure the
GICv3 accordingly. Xen needs to set GICD_IGROUPR for SPIs and
GICR_IGROUPR0 for local interrupt to "1" to specify that interrupts
belong to group1. This is particularly important if the system has
GICD_CTLR.DS set, also see commit
7c9b973061b03af62734f613f6abec46c0dd4a88 in Linux.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Released-acked-by: Julien Grall <julien.grall@linaro.org>
commit 5dd3907a2af37060a675dd3bc5a02b7b38dac66c
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Oct 17 15:11:23 2017 +0100
xen/public: Correct the definition of GNTTAB_CACHE_SOURCE_GREF
Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
(d79) XSA-232 PoC
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25
(XEN) left shift of 1 by 31 places cannot be represented in type 'int'
(XEN) ----[ Xen-4.10.0-rc x86_64 debug=y Tainted: H ]----
Update all of the GNTTAB_CACHE_* constants to be unsigned integers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 8d7b633adab76a778ccf3e3417e903b35333c528
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Aug 29 10:35:31 2017 +0000
x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
There are currently three functions which write L4 pagetables for Xen, but
they all behave subtly differently. sh_install_xen_entries_in_l4() in
particular is catering for two different usecases, which makes the safety of
the linear mappings hard to follow.
By consolidating the L4 pagetable writing in a single function, the resulting
setup of Xen's virtual layout is easier to understand.
No practical changes to the resulting L4, although the logic has been
rearranged to avoid rewriting some slots. This changes the zap_ro_mpt
parameter to simply ro_mpt.
Both {hap,sh}_install_xen_entries_in_l4() get folded into their callers. The
hap side only a single caller, while the shadow side has two. The shadow
split helps highlight the correctness of the linear slots.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Release-acked-by: Julien Grall <julien.gral@linaro.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit 5cf67895f8c9fb4adcaab9172b43076599003db4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Aug 29 11:35:31 2017 +0100
x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()
Having all of this logic together makes it easier to follow Xen's virtual
setup across the whole system.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Release-acked-by: Julien Grall <julien.gral@linaro.org>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit 824785e469f47aa9a8a2f4a6f4757dfedd6ec940
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Sep 25 11:11:05 2017 +0100
Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"
This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
1bd39738a5a34f529a610fb275cc83ee5ac7547a.
The following patches (post XSA-243 fixes) requires init_guest_l4_table()
being common code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Release-acked-by: Julien Grall <julien.gral@linaro.org>
commit 4ed00f57f086c589a95fdd17ace43e02fee2be34
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Oct 17 17:52:02 2017 +0100
tools: libxendevicemodel: Restore symbol versions for 1.0
In 1462f9ea8f4219d520a530787b80c986e050aa98
"tools: libxendevicemodel: Provide xendevicemodel_shutdown"
we added a new version 1.1 to the symbol map and simply abolished
the old one. That is quite wrong.
Instead, we should have left the 1.0 map alone and added a new version
which simply adds the new symbol.
Fix this.
Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit c4efa25058d3f45bf725d6ebe6429db9adf94b62
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Oct 17 11:23:53 2017 +0100
mm/shadow: fix declaration of fetch_type_names
fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
SHADOW_DEBUG, fix the declaration so it's also guarded by
SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
Observed while building with clang and ubsan enabled.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
commit 0075bc1f02c389c5bb84cbffdc27dc9b53699bca
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Oct 16 13:20:00 2017 +0000
xen/dom0: Fix latent dom0 construction bugs on all architectures
* x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
all state is actually set up. As it currently stands, d0v0 is eligible for
scheduling before its registers have been set. This is latent as we also
hold a systemcontroller pause reference at the time which prevents d0 from
being scheduled.
* x86 PVH previously was not setting v->is_initialised for d0v0, despite
setting the vcpu running eventually. Therefore, a later VCPUOP_initialise
hypercall will modify state under the feet of the running vcpu. This is
latent as PVH dom0 construction don't yet function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Julien Grall <julien.grall@linaro.org>
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-22 23:49 [xen-unstable test] 115037: regressions - FAIL osstest service owner
@ 2017-10-23 8:40 ` Jan Beulich
2017-10-23 13:58 ` Julien Grall
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2017-10-23 8:40 UTC (permalink / raw)
To: osstest-admin; +Cc: xen-devel
>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
> flight 115037 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115037/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
I'm puzzled by these recurring failures: Until flight 114525 all three
(plus the fourth sibling, which is in "guest-stop fail never pass" state)
were fail-never-pass on windows-install (the 64-bit host ones) or
guest-saverestore (the 32-bit host ones). Then flights 114540 and
114644 were successes, and since then guest-stop has been failing.
The guest console doesn't show any indication that the guest may
have received a shutdown signal.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 8:40 ` Jan Beulich
@ 2017-10-23 13:58 ` Julien Grall
2017-10-23 14:18 ` Ian Jackson
2017-10-23 14:34 ` Jan Beulich
0 siblings, 2 replies; 8+ messages in thread
From: Julien Grall @ 2017-10-23 13:58 UTC (permalink / raw)
To: Jan Beulich, osstest-admin; +Cc: xen-devel, Andrew Cooper
+ Andrew
Hi,
On 23/10/17 09:40, Jan Beulich wrote:
>>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
>> flight 115037 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/115037/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>
> I'm puzzled by these recurring failures: Until flight 114525 all three
> (plus the fourth sibling, which is in "guest-stop fail never pass" state)
> were fail-never-pass on windows-install (the 64-bit host ones) or
> guest-saverestore (the 32-bit host ones). Then flights 114540 and
> 114644 were successes, and since then guest-stop has been failing.
> The guest console doesn't show any indication that the guest may
> have received a shutdown signal.
Would it be possible of a platform specific bug? The last two flights
are failing on merlot1.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 13:58 ` Julien Grall
@ 2017-10-23 14:18 ` Ian Jackson
2017-10-23 14:34 ` Jan Beulich
1 sibling, 0 replies; 8+ messages in thread
From: Ian Jackson @ 2017-10-23 14:18 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, osstest-admin, Jan Beulich, Andrew Cooper
Julien Grall writes ("Re: [Xen-devel] [xen-unstable test] 115037: regressions - FAIL"):
> Would it be possible of a platform specific bug? The last two flights
> are failing on merlot1.
The merlots are a highly unusual AMD machines which have NUMA nodes
with no memory and seem to sometimes have performance problems...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 13:58 ` Julien Grall
2017-10-23 14:18 ` Ian Jackson
@ 2017-10-23 14:34 ` Jan Beulich
2017-10-23 14:38 ` Andrew Cooper
1 sibling, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2017-10-23 14:34 UTC (permalink / raw)
To: Julien Grall; +Cc: Andrew Cooper, osstest-admin, xen-devel
>>> On 23.10.17 at 15:58, <julien.grall@linaro.org> wrote:
> On 23/10/17 09:40, Jan Beulich wrote:
>>>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
>>> flight 115037 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/115037/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>
>> I'm puzzled by these recurring failures: Until flight 114525 all three
>> (plus the fourth sibling, which is in "guest-stop fail never pass" state)
>> were fail-never-pass on windows-install (the 64-bit host ones) or
>> guest-saverestore (the 32-bit host ones). Then flights 114540 and
>> 114644 were successes, and since then guest-stop has been failing.
>> The guest console doesn't show any indication that the guest may
>> have received a shutdown signal.
>
> Would it be possible of a platform specific bug? The last two flights
> are failing on merlot1.
Not very likely here, I would say.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 14:34 ` Jan Beulich
@ 2017-10-23 14:38 ` Andrew Cooper
2017-10-23 15:57 ` Wei Liu
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cooper @ 2017-10-23 14:38 UTC (permalink / raw)
To: Jan Beulich, Julien Grall; +Cc: xen-devel, osstest-admin
On 23/10/17 15:34, Jan Beulich wrote:
>>>> On 23.10.17 at 15:58, <julien.grall@linaro.org> wrote:
>> On 23/10/17 09:40, Jan Beulich wrote:
>>>>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
>>>> flight 115037 xen-unstable real [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/115037/
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>>> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>>> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>> I'm puzzled by these recurring failures: Until flight 114525 all three
>>> (plus the fourth sibling, which is in "guest-stop fail never pass" state)
>>> were fail-never-pass on windows-install (the 64-bit host ones) or
>>> guest-saverestore (the 32-bit host ones). Then flights 114540 and
>>> 114644 were successes, and since then guest-stop has been failing.
>>> The guest console doesn't show any indication that the guest may
>>> have received a shutdown signal.
>> Would it be possible of a platform specific bug? The last two flights
>> are failing on merlot1.
> Not very likely here, I would say.
These tests have reliably never passed before, and there are no changes
recently (I'm aware of) which would cause them to start passing.
The windows VMs aren't running PV drivers, so have no clue about the
xenstore control key, or what a setting of shutdown is supposed to mean.
The bug is why there are two spurious passes.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 14:38 ` Andrew Cooper
@ 2017-10-23 15:57 ` Wei Liu
2017-10-24 9:59 ` Julien Grall
0 siblings, 1 reply; 8+ messages in thread
From: Wei Liu @ 2017-10-23 15:57 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel, Julien Grall, Wei Liu, osstest-admin, Jan Beulich
On Mon, Oct 23, 2017 at 03:38:33PM +0100, Andrew Cooper wrote:
> On 23/10/17 15:34, Jan Beulich wrote:
> >>>> On 23.10.17 at 15:58, <julien.grall@linaro.org> wrote:
> >> On 23/10/17 09:40, Jan Beulich wrote:
> >>>>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
> >>>> flight 115037 xen-unstable real [real]
> >>>> http://logs.test-lab.xenproject.org/osstest/logs/115037/
> >>>>
> >>>> Regressions :-(
> >>>>
> >>>> Tests which did not succeed and are blocking,
> >>>> including tests which could not be run:
> >>>> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
> >>>> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
> >>>> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
> >>> I'm puzzled by these recurring failures: Until flight 114525 all three
> >>> (plus the fourth sibling, which is in "guest-stop fail never pass" state)
> >>> were fail-never-pass on windows-install (the 64-bit host ones) or
> >>> guest-saverestore (the 32-bit host ones). Then flights 114540 and
> >>> 114644 were successes, and since then guest-stop has been failing.
> >>> The guest console doesn't show any indication that the guest may
> >>> have received a shutdown signal.
> >> Would it be possible of a platform specific bug? The last two flights
> >> are failing on merlot1.
> > Not very likely here, I would say.
>
> These tests have reliably never passed before, and there are no changes
> recently (I'm aware of) which would cause them to start passing.
There is on osstest side -- we bumped the disk from 10G to 20G.
Previously the tests failed due to there was insufficient space to store
this iso and the guest image.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 115037: regressions - FAIL
2017-10-23 15:57 ` Wei Liu
@ 2017-10-24 9:59 ` Julien Grall
0 siblings, 0 replies; 8+ messages in thread
From: Julien Grall @ 2017-10-24 9:59 UTC (permalink / raw)
To: Wei Liu, Andrew Cooper; +Cc: xen-devel, xen.org, osstest-admin, Jan Beulich
Hi,
On 23/10/2017 16:57, Wei Liu wrote:
> On Mon, Oct 23, 2017 at 03:38:33PM +0100, Andrew Cooper wrote:
>> On 23/10/17 15:34, Jan Beulich wrote:
>>>>>> On 23.10.17 at 15:58, <julien.grall@linaro.org> wrote:
>>>> On 23/10/17 09:40, Jan Beulich wrote:
>>>>>>>> On 23.10.17 at 01:49, <osstest-admin@xenproject.org> wrote:
>>>>>> flight 115037 xen-unstable real [real]
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/115037/
>>>>>>
>>>>>> Regressions :-(
>>>>>>
>>>>>> Tests which did not succeed and are blocking,
>>>>>> including tests which could not be run:
>>>>>> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>>>>> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>>>>> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
>>>>> I'm puzzled by these recurring failures: Until flight 114525 all three
>>>>> (plus the fourth sibling, which is in "guest-stop fail never pass" state)
>>>>> were fail-never-pass on windows-install (the 64-bit host ones) or
>>>>> guest-saverestore (the 32-bit host ones). Then flights 114540 and
>>>>> 114644 were successes, and since then guest-stop has been failing.
>>>>> The guest console doesn't show any indication that the guest may
>>>>> have received a shutdown signal.
>>>> Would it be possible of a platform specific bug? The last two flights
>>>> are failing on merlot1.
>>> Not very likely here, I would say.
>>
>> These tests have reliably never passed before, and there are no changes
>> recently (I'm aware of) which would cause them to start passing.
>
> There is on osstest side -- we bumped the disk from 10G to 20G.
>
> Previously the tests failed due to there was insufficient space to store
> this iso and the guest image.
They seemed to have passed twice on two separate machine and then failed
reliably again on merlot1/pinot0.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-10-24 9:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-22 23:49 [xen-unstable test] 115037: regressions - FAIL osstest service owner
2017-10-23 8:40 ` Jan Beulich
2017-10-23 13:58 ` Julien Grall
2017-10-23 14:18 ` Ian Jackson
2017-10-23 14:34 ` Jan Beulich
2017-10-23 14:38 ` Andrew Cooper
2017-10-23 15:57 ` Wei Liu
2017-10-24 9:59 ` Julien Grall
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.