[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [qemu-mainline test] 112844: regressions - trouble: blocked/broken/fail/pass
flight 112844 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112844/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 5 host-build-prep fail REGR. vs. 112676 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112676 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-install fail REGR. vs. 112676 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 112676 build-arm64-xsm 2 hosts-allocate broken like 112676 build-arm64-pvops 3 capture-logs broken like 112676 build-arm64 2 hosts-allocate broken like 112676 build-arm64-xsm 3 capture-logs broken like 112676 build-arm64 3 capture-logs broken like 112676 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 112676 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 112676 test-amd64-amd64-xl-rtds 10 debian-install fail like 112676 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install 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-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 12 migrate-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-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu 56d7305db6d7c9b98c2bb44c53e67f1ec8336daa baseline version: qemuu 1f296733876434118fd766cfef5eb6f29ecab6a8 Last test of basis 112676 2017-08-17 03:18:45 Z 7 days Testing same since 112844 2017-08-23 11:41:51 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bharata B Rao <bharata@xxxxxxxxxxxxxxxxxx> Cornelia Huck <cohuck@xxxxxxxxxx> Daniel Henrique Barboza <danielhb@xxxxxxxxxxxxxxxxxx> David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> Greg Kurz <groug@xxxxxxxx> Peter Maydell <peter.maydell@xxxxxxxxxx> Thomas Huth <thuth@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm broken build-armhf-xsm broken build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops broken build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl 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-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-armhf-armhf-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvh-amd pass test-amd64-i386-qemuu-rhel6hvm-amd 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-xl-qemuu-win7-amd64 pass test-amd64-i386-xl-qemuu-win7-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-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass 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-pvh-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-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-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail 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 broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-xsm hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64-xsm capture-logs broken-step build-arm64 capture-logs Not pushing. ------------------------------------------------------------ commit 56d7305db6d7c9b98c2bb44c53e67f1ec8336daa Merge: 1f29673 1f98e55 Author: Peter Maydell <peter.maydell@xxxxxxxxxx> Date: Wed Aug 23 09:04:20 2017 +0100 Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170823' into staging ppc patch queue 2017-08-23 This is identical to the pull request from yesterday (20180822), except that a bug in one patch is fixed so that it doesn't break TCG on a ppc host. Last minute ppc related fixes for qemu-2.10. I'm not sure if these are critical enough to prompt another rc, but I'm submitting them for consideration. First, is Cornelia's fix for 480bc11e6 which meant "make check" would always fail on a ppc host. Tracking that down delayed submission of the rest of these patches, sorry. The rest are all fairly important bugfixes for qemu crashes or guest behaviour regression on ppc. Patches 2-4 specifically are fixes for regressions from qemu-2.9, caused by the compatibility mode and hotplug handling cleanups for the pseries machine type. # gpg: Signature made Wed 23 Aug 2017 01:31:47 BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>" # gpg: aka "David Gibson (Red Hat) <dgibson@xxxxxxxxxx>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@xxxxxxxxxx>" # gpg: aka "David Gibson (kernel.org) <dwg@xxxxxxxxxx>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.10-20170823: hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev' spapr: Allow configure-connector to be called multiple times ppc: fix ppc_set_compat() with KVM PR target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround boot-serial-test: prefer tcg accelerator Signed-off-by: Peter Maydell <peter.maydell@xxxxxxxxxx> commit 1f98e55385d11da1dc0de6440e66f19d191d2a1b Author: Thomas Huth <thuth@xxxxxxxxxx> Date: Thu Aug 17 16:19:16 2017 +0200 hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device QEMU currently aborts unexpectedly when the user tries to add and remove a "spapr-tce-table" device: $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio QEMU 2.9.92 monitor - type 'help' for more information (qemu) device_add spapr-tce-table,id=x (qemu) device_del x ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped) The device should not be accessable for the users at all, it's just used internally, so mark it with user_creatable = false. Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx> Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit 8ccccff9dd7ba24c7a78861172e8dc6b07f1c392 Author: Thomas Huth <thuth@xxxxxxxxxx> Date: Thu Aug 17 07:15:10 2017 +0200 hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false QEMU currently aborts unexpectedly when a user tries to do something like this: $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio QEMU 2.9.92 monitor - type 'help' for more information (qemu) device_add spapr-rtc,id=spapr-rtc (qemu) device_del spapr-rtc ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped) The RTC device is not meant to be hot-pluggable - it's an internal device only and it even should not be possible to create it a second time with the "-device" parameter, so let's mark this with "user_creatable = false". Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx> Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit 0479097859372a760843ad1b9c6ed3705c6423ca Author: Thomas Huth <thuth@xxxxxxxxxx> Date: Mon Aug 21 08:30:29 2017 +0200 hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev' QEMU currently crashes when trying to use a 'pc-dimm' on the pseries machine without specifying its 'memdev' property. This happens because pc_dimm_get_memory_region() does not check whether the 'memdev' property has properly been set by the user. Looking closer at this function, it's also obvious that it is using &error_abort to call another function - and this is bad in a function that is used in the hot-plugging calling chain since this can also cause QEMU to exit unexpectedly. So let's fix these issues in a proper way now: Add a "Error **errp" parameter to pc_dimm_get_memory_region() which we use in case the 'memdev' property has not been set by the user, and which we can use instead of the &error_abort, and change the callers of get_memory_region() to make use of this "errp" parameter for proper error checking. Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx> Reviewed-by: Igor Mammedov <imammedo@xxxxxxxxxx> Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit 188bfe1b00360657c701cda2f97ce276add7e255 Author: Bharata B Rao <bharata@xxxxxxxxxxxxxxxxxx> Date: Thu Aug 17 10:46:42 2017 +0530 spapr: Allow configure-connector to be called multiple times In case of in-kernel memory hot unplug, when the guest is not able to remove all the LMBs that are requested for removal, it will add back any LMBs that have been successfully removed. The DR Connectors of these LMBs wouldn't have been unconfigured and hence the addition of these LMBs will result in configure-connector call being issued on LMB DR connectors that are already in configured state. Such configure-connector calls will fail resulting in a DIMM which is partially unplugged. This however worked till recently before we overhauled the DRC implementation in QEMU. Commit 9d4c0f4f0a71e: "spapr: Consolidate DRC state variables" is the first commit where this problem shows up as per git bisect. Ideally guest shouldn't be issuing configure-connector call on an already configured DR connector. However for now, work around this in QEMU by allowing configure-connector to be called multiple times for all types of DR connectors. Signed-off-by: Bharata B Rao <bharata@xxxxxxxxxxxxxxxxxx> [dwg: Corrected buglet that would have initialized fdt pointers ready for reading on a device not present at reset] Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit 5dfaa532e0010c2dea50385c87683b0d756aa12f Author: Greg Kurz <groug@xxxxxxxx> Date: Mon Aug 14 19:49:16 2017 +0200 ppc: fix ppc_set_compat() with KVM PR When running in KVM PR mode, kvmppc_set_compat() always fail because the current PR implementation doesn't handle KVM_REG_PPC_ARCH_COMPAT. Now that the machine code inconditionally calls ppc_set_compat_all() at reset time to restore the compat mode default value (commit 66d5c492dd3a9), it is impossible to start a guest with PR: qemu-system-ppc64: Unable to set CPU compatibility mode in KVM: Invalid argument A tentative patch [1] was recently sent by Suraj to address the issue, but it would prevent the compat mode to be turned off on reset. And we really don't want to explicitely check for KVM PR. During the patch's review, David suggested that we should only call the KVM ioctl() if the compat PVR changes. This allows at least to run with KVM PR, provided no compat mode is requested from the command line (which should be the case when running PR nested). This is what this patch does. While here, we also fix the side effect where KVM would fail but we would change the CPU state in QEMU anyway. [1] http://patchwork.ozlabs.org/patch/782039/ Signed-off-by: Greg Kurz <groug@xxxxxxxx> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@xxxxxxxxx> Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit c363a37a450f925df76b88a87dc733bad75cc452 Author: Daniel Henrique Barboza <danielhb@xxxxxxxxxxxxxxxxxx> Date: Wed Aug 9 17:43:46 2017 -0300 target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround Commit d5fc133eed ("ppc: Rework CPU compatibility testing across migration") changed the way cpu_post_load behaves with the PVR setting, causing an unexpected bug in KVM-HV migrations between hosts that are compatible (POWER8 and POWER8E, for example). Even with pvr_match() returning true, the guest freezes right after cpu_post_load. The reason is that the guest kernel can't handle a different PVR value other that the running host in KVM_SET_SREGS. In [1] it was discussed the possibility of a new KVM capability that would indicate that the guest kernel can handle a different PVR in KVM_SET_SREGS. Even if such feature is implemented, there is still the problem with older kernels that will not have this capability and will fail to migrate. This patch implements a workaround for that scenario. If running with KVM, check if the guest kernel does not have the capability (named here as 'cap_ppc_pvr_compat'). If it doesn't, calls kvmppc_is_pr() to see if the guest is running in KVM-HV. If all this happens, set env->spr[SPR_PVR] to the same value as the current host PVR. This ensures that we allow migrations with 'close enough' PVRs to still work in KVM-HV but also makes the code ready for this new KVM capability when it is done. A new function called 'kvmppc_pvr_workaround_required' was created to encapsulate the conditions said above and to avoid calling too many kvm.c internals inside cpu_post_load. [1] https://lists.gnu.org/archive/html/qemu-ppc/2017-06/msg00503.html Signed-off-by: Daniel Henrique Barboza <danielhb@xxxxxxxxxxxxxxxxxx> [dwg: Fix for the case of using TCG on a PPC host] Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> commit b96919d765a65f5e0f140479f7da0b94521263c6 Author: Cornelia Huck <cohuck@xxxxxxxxxx> Date: Wed Aug 16 10:26:50 2017 +0200 boot-serial-test: prefer tcg accelerator Prefer to use the tcg accelarator if it is available: This is our only real smoke test for tcg, and fast enough to use it for that. Fixes: 480bc11e6 ("boot-serial-test: fallback to kvm accelerator") Reported-by: Richard Henderson <richard.henderson@xxxxxxxxxx> Signed-off-by: Cornelia Huck <cohuck@xxxxxxxxxx> Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |