[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable test] 101810: regressions - FAIL
flight 101810 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 101673 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 10 guest-start fail in 101792 pass in 101810 test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail in 101792 pass in 101810 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 101792 pass in 101810 test-armhf-armhf-libvirt 7 host-ping-check-xen fail pass in 101792 test-amd64-i386-xl-raw 10 guest-start fail pass in 101792 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-start/debianhvm.repeat fail pass in 101792 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail pass in 101792 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat fail pass in 101792 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail pass in 101792 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail pass in 101792 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101792 blocked in 101673 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 101792 like 101673 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101673 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101673 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 101673 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 101673 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 101673 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 101673 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 101673 test-amd64-amd64-xl-rtds 9 debian-install fail like 101673 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 12 migrate-support-check fail in 101792 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass build-i386-rumprun 7 xen-build fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass build-amd64-rumprun 7 xen-build fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass version targeted for testing: xen 35ac0c08178ac15565b32ca56b00fa5414f1d3b1 baseline version: xen 6f9b62ca57322197e26d3b22ff11b629697142bd Last test of basis 101673 2016-10-26 02:01:16 Z 4 days Failing since 101698 2016-10-26 19:50:48 Z 4 days 6 attempts Testing same since 101780 2016-10-29 06:33:52 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> David Scott <dave@xxxxxxxxxx> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Meng Xu <mengxu@xxxxxxxxxxxxx> Roger Pau Monne <roger.pau@xxxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> 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-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumprun fail build-i386-rumprun fail 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 fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail 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 fail 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-pvh-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 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumprun-amd64 blocked 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-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-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 blocked test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-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 fail test-amd64-i386-libvirt 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-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 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 35ac0c08178ac15565b32ca56b00fa5414f1d3b1 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Aug 4 18:01:15 2016 +0000 x86/hvm: Don't truncate the hvm hypercall index before range checking it c/s 5eeca68f introduced the 64bit ABI for HVM guests, and chose to explicitly truncate the index, despite the fact that the `mov $imm32, %eax` in the hypercall page already provides the expected truncation. The truncation isn't very obvious, and is counterintuitive, seeing as all other 64bit parameters are passed without truncation. It is also different to the PV ABI, which is otherwise identical. As the hypercall page has always been present for HVM guests (and indeed, is basically mandatory to abstract away vendor differences), it is exceedingly unlikely that any code exists which enters hvm_do_hypercall() with upper bits set in %rax. Therefore, take the opportunity to fix the ABI before it becomes impossible to fix. While tweaking this area, fix one piece of trailing whitespace. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit a418ec07cf2668197548c6503924139a2098e41d Author: Meng Xu <mengxu@xxxxxxxxxxxxx> Date: Wed Oct 26 15:06:29 2016 -0400 xen: rtds: Update last_start whenever cur_budget is updated Make budget accounting code more consistent by making sure the values used to compute how much budget has been consumed are updated together. This makes code resilient to calling burn_budget() from more than just one place -- in case we will need to do that -- without risking subtle bugs. No functional changes are intended. Signed-off-by: Meng Xu <mengxu@xxxxxxxxxxxxx> Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 514e5eb015cb2c7714a3a3320e4f49c55324c76a Author: Meng Xu <mengxu@xxxxxxxxxxxxx> Date: Wed Oct 26 15:06:06 2016 -0400 xen:rtds: Fix bug in budget accounting Bug scenario: repl_timer_handler() may be called before rt_schedule() for a VCPU. This situation may happen in two scenarios: (1) The VCPU misses deadline due to the system is oversubscribed. For example, the sum of VCPUs utilization on a core is larger than one. (2) The VCPU has budget = period, which causes the timers for rt_schedule() and repl_timer_handler() are fired at the same time. When the situation happens, it causes the following incorrect behavior: repl_timer_handler() will update the VCPU period and deadline. If the VCPU is still the highest priority one, even with the new deadline, it will continue to run, but with new period and deadline. Since the budget enforcement timer for the previous period is still armed, rt_schedule() will still be called in the new period and enforce the budget for the previous period. The current burn_budget() will deduct the time spent in previous period from the budget in current period, which is incorrect. Fix: We keeps last_start always within the current period for a VCPU, so that we only deduct the time spent in the current period from the VCPU budget. We always update last_start whenever we update cur_deadline for a VCPU. Signed-off-by: Meng Xu <mengxu@xxxxxxxxxxxxx> Reported-by: Dagaen Golomb <dgolomb@xxxxxxxxxxxxx> Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit e26722422764d3ddfe59e76f5efbd330f8f9288f Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Oct 26 16:13:21 2016 +0200 Revert "keyhandler: rework process of nonirq keyhandler" This reverts commit 610b4eda2ce2b87cccbc8f61bdec01052e54fc66. It's not useful without ed7e33747d, which got reverted already. commit 9f47f3d69f4dcb2b33ccb8fb20057152302ea1ad Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Oct 26 12:06:44 2016 +0100 x86/emul: Move CPUID Faulting fault generation into the emulator In hindsight, this is a better position for it, as it avoids opencoding hvmemul_inject_hw_exception() in hvmemul_cpuid(), and reduces the requirements on other ops->cpuid() hooks wanting to implement cpuid faulting in the future. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 0888d36bb23f7365ce12b03127fd0fb2661ec90e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 23 14:48:27 2016 +0100 x86/emul: Correct the decoding of SReg3 operands REX.R is ignored when considering segment register operands, and needs masking out first. While fixing this, reorder the user segments in x86_segment to match SReg3 encoding. This avoids needing a translation table between hardware ordering and Xen's ordering. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 22bc820abb5200729dc387e6a0653c31daecfef3 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 25 18:46:39 2016 +0100 x86/emul: Use explicit __attribute__((__packed__)) rather than __packed x86_emulate.h is included by the userspace test harness. Avoid using constructs which don't come from standard header files. Reposition the test harnesses inclusion of x86_emulate.h to avoid relying on any definitions intended for use by x86_emulate.c alone. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 1b843b2097e89d0fae18123cde88da9d167d9a0c Author: Meng Xu <mengxu@xxxxxxxxxxxxx> Date: Fri Oct 21 22:12:02 2016 -0400 xen: rtds: always clear the flag when replenishing a depleted vcpu We should clear the __RTDS_depleted bit once a VCPU budget is replenished. Because repl_timer_handler may be called after rt_schedule but before rt_context_saved, the VCPU may be not on CPU or on queue when the VCPU is the middle of context switch Signed-off-by: Meng Xu <mengxu@xxxxxxxxxxxxx> Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 1307f8d3d46fe34f6eb739894008e8af3c168818 Author: Juergen Gross <jgross@xxxxxxxx> Date: Mon Oct 24 13:27:17 2016 +0200 docs: remove wrong statement about bug in xenstore docs/misc/xenstore.txt states that xenstored will use "0" as a valid transaction id after 2^32 transactions. This is not true. Remove that statement. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 0897514b4b376a167f968f79c6ea0dee1061458e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Oct 26 10:34:21 2016 +0100 tools/oxenstored: Avoid allocating invalid transaction ids The transaction id of 0 is reserved, meaning "not in a transaction". It is up to the xenstored server to allocate transaction ids. While oxenstored starts its ids at 1, but insufficient care is taken with truncation cases. A 32bit oxenstored has an int with 31 bits of width, meaning that the transaction id will wrap around to 0 after 2 billion transactions. A 64bit oxenstored has an int with 63 bits of width, meaning that once 4 billion transactions are used, the allocated id will be truncated when written into the uin32_t field in the ring. This causes the client to reply with the truncated id, breaking any further attempt to use any transactions. Limit all transaction ids to the range between 1 and 0x7ffffffe. This is the best which can be done without making oxenstored depend on Stdint or Cstruct, yet still work for 32bit builds. Also check that the proposed new transaction id isn't currently in use. For the first 2 billion transactions there is no chance of a collision, and after that, the chance is at most 20 (the default open transaction quota) in 2 billion. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: David Scott <dave@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 4000a7c7d7b0e01837abd3918e393f289c07d68c Author: Roger Pau Monne <roger.pau@xxxxxxxxxx> Date: Tue Oct 25 11:53:28 2016 +0200 tools/configure: fix pkg-config install path for FreeBSD pkg-config from FreeBSD ports doesn't have ${prefix}/share/pkgconfig in the default search path, fix this by having a PKG_INSTALLDIR variable that can be changed on a per-OS basis. It would be best to use PKG_INSTALLDIR as defined by the pkg.m4 macro, but sadly this also reports a wrong value on FreeBSD (${libdir}/pkgconfig, which expands to /usr/local/lib/pkgconfig by default, and is also _not_ part of the default pkg-config search path). This patch should not change the behavior for Linux installs. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reported-by: Alexander Nusov <alexander.nusov@xxxxxxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 0d250b69eae5d1e8039270c763b05acc84589a8c Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Oct 26 12:06:17 2016 +0100 Update QEMU_UPSTREAM_REVISION Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |