|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.5-testing test] 62756: regressions - trouble: broken/fail/pass
flight 62756 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62756/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail in 62726 REGR. vs. 62552 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-raw 3 host-install(3) broken pass in 62726 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken pass in 62726 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken pass in 62726 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 62726 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 62726 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail in 62726 pass in 62756 test-amd64-i386-libvirt 15 guest-saverestore.2 fail pass in 62726 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-qcow2 13 guest-saverestore fail in 62726 REGR. vs. 62552 test-armhf-armhf-xl-rtds 11 guest-start fail like 62552 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 62552 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 62552 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-qcow2 9 debian-di-install fail in 62726 never pass test-armhf-armhf-libvirt-vhd 9 debian-di-install fail in 62726 never pass test-armhf-armhf-xl-raw 9 debian-di-install fail in 62726 never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-check fail in 62726 never pass test-amd64-amd64-libvirt-raw 11 migrate-support-check fail in 62726 never pass test-amd64-i386-libvirt-vhd 11 migrate-support-check fail in 62726 never pass test-amd64-i386-libvirt-raw 11 migrate-support-check fail in 62726 never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-check fail in 62726 never pass test-armhf-armhf-xl-vhd 9 debian-di-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-install fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-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-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-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-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen db0f474646878b0e91fd14f53eec6adcacc4b5ba baseline version: xen 0297baf5b5b6724e006e761249694444204dacfb Last test of basis 62552 2015-09-30 04:48:55 Z 10 days Testing same since 62726 2015-10-08 10:12:31 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Quan Xu <quan.xu@xxxxxxxxx> Yang Zhang <yang.z.zhang@xxxxxxxxx> jobs: 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-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass 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 broken test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 broken 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 broken 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-rumpuserxen-i386 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 fail 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 fail test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw broken test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail 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 fail test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 broken 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 broken-step test-amd64-i386-xl-raw host-install(3) broken-step test-amd64-i386-freebsd10-amd64 host-install(3) broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3) broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3) broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3) Not pushing. ------------------------------------------------------------ commit db0f474646878b0e91fd14f53eec6adcacc4b5ba Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 8 11:38:44 2015 +0200 x86/p2m-pt: tighten conditions of IOMMU mapping updates Whether the MFN changes does not depend on the new entry being valid (but solely on the old one), and the need to update or TLB-flush also depends on permission changes. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 660fd65d5578a95ec5eac522128bba23325179eb master date: 2015-10-02 13:40:36 +0200 commit 2b58d7b1bd95c8b7d7197f15b271c8bac8c41bca Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Thu Oct 8 11:38:05 2015 +0200 credit1: fix tickling when it happens from a remote pCPU especially if that is also from a different cpupool than the processor of the vCPU that triggered the tickling. In fact, it is possible that we get as far as calling vcpu_unblock()--> vcpu_wake()-->csched_vcpu_wake()-->__runq_tickle() for the vCPU 'vc', but all while running on a pCPU that is different from 'vc->processor'. For instance, this can happen when an HVM domain runs in a cpupool, with a different scheduler than the default one, and issues IOREQs to Dom0, running in Pool-0 with the default scheduler. In fact, right in this case, the following crash can be observed: (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]---- (XEN) CPU: 7 (XEN) RIP: e008:[<ffff82d0801230de>] __runq_tickle+0x18f/0x430 (XEN) RFLAGS: 0000000000010086 CONTEXT: hypervisor (d1v0) (XEN) rax: 0000000000000001 rbx: ffff8303184fee00 rcx: 0000000000000000 (XEN) ... ... ... (XEN) Xen stack trace from rsp=ffff83031fa57a08: (XEN) ffff82d0801fe664 ffff82d08033c820 0000000100000002 0000000a00000001 (XEN) 0000000000006831 0000000000000000 0000000000000000 0000000000000000 (XEN) ... ... ... (XEN) Xen call trace: (XEN) [<ffff82d0801230de>] __runq_tickle+0x18f/0x430 (XEN) [<ffff82d08012348a>] csched_vcpu_wake+0x10b/0x110 (XEN) [<ffff82d08012b421>] vcpu_wake+0x20a/0x3ce (XEN) [<ffff82d08012b91c>] vcpu_unblock+0x4b/0x4e (XEN) [<ffff82d080167bd0>] vcpu_kick+0x17/0x61 (XEN) [<ffff82d080167c46>] vcpu_mark_events_pending+0x2c/0x2f (XEN) [<ffff82d08010ac35>] evtchn_fifo_set_pending+0x381/0x3f6 (XEN) [<ffff82d08010a0f6>] notify_via_xen_event_channel+0xc9/0xd6 (XEN) [<ffff82d0801c29ed>] hvm_send_ioreq+0x3e9/0x441 (XEN) [<ffff82d0801bba7d>] hvmemul_do_io+0x23f/0x2d2 (XEN) [<ffff82d0801bbb43>] hvmemul_do_io_buffer+0x33/0x64 (XEN) [<ffff82d0801bc92b>] hvmemul_do_pio_buffer+0x35/0x37 (XEN) [<ffff82d0801cc49f>] handle_pio+0x58/0x14c (XEN) [<ffff82d0801eabcb>] vmx_vmexit_handler+0x16b3/0x1bea (XEN) [<ffff82d0801efd21>] vmx_asm_vmexit_handler+0x41/0xc0 In this case, pCPU 7 is not in Pool-0, while the (Dom0's) vCPU being woken is. pCPU's 7 pool has a different scheduler than credit, but it is, however, right from pCPU 7 that we are waking the Dom0's vCPUs. Therefore, the current code tries to access csched_balance_mask for pCPU 7, but that is not defined, and hence the Oops. (Note that, in case the two pools run the same scheduler we see no Oops, but things are still conceptually wrong.) Cure things by making the csched_balance_mask macro accept a parameter for fetching a specific pCPU's mask (instead than always using smp_processor_id()). Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: ea5637968a09a81a64fa5fd73ce49b4ea9789e12 master date: 2015-09-30 14:44:22 +0200 commit 887da2bb47573ea8784f6b2be5a8d9af14846aac Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 8 11:37:19 2015 +0200 x86/p2m-pt: ignore pt-share flag for shadow mode guests There is no page table sharing in shadow mode. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: c0a85795d864dd64c116af661bf676d66ddfd5fc master date: 2015-09-29 13:56:03 +0200 commit e4e18ecf958364c4fa3392355b7a67dff91704e8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 8 11:36:52 2015 +0200 x86/p2m-pt: delay freeing of intermediate page tables Old intermediate page tables must be freed only after IOMMU side updates/flushes have got carried out. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 960265fbd878cdc9841473b755e4ccc9eb1942d2 master date: 2015-09-29 13:55:34 +0200 commit dde24142b34c64a03316fdaceb9a81db417c0ea5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 8 11:35:55 2015 +0200 x86/EPT: tighten conditions of IOMMU mapping updates Permission changes should also result in updates or TLB flushes. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 6c0e4ad60850032c9bbd5d18b8446421c97e08e4 master date: 2015-09-29 10:25:29 +0200 commit b6e40c9d8853f9e555b4a18fa73c810852f723ba Author: Quan Xu <quan.xu@xxxxxxxxx> Date: Thu Oct 8 11:34:56 2015 +0200 vt-d: fix IM bit mask and unmask of Fault Event Control Register Bit 0:29 in Fault Event Control Register are 'Reserved and Preserved', software cannot write 0 to it unconditionally. Software must preserve the value read for writes. Signed-off-by: Quan Xu <quan.xu@xxxxxxxxx> Acked-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> vt-d: fix IM bit unmask of Fault Event Control Register in init_vtd_hw() Bit 0:29 in Fault Event Control Register are 'Reserved and Preserved', software cannot write 0 to it unconditionally. Software must preserve the value read for writes. Suggested-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: Quan Xu <quan.xu@xxxxxxxxx> master commit: 86f3ff9fc4cc3cb69b96c1de74bcc51f738fe2b9 master date: 2015-09-25 09:08:22 +0200 master commit: 26b300bd727ef00a8f60329212a83c3b027a48f7 master date: 2015-09-25 18:03:04 +0200 commit d3d476f505a124cd3d6ac7f5b2aedfe6c21fea86 Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Date: Thu Oct 8 11:33:28 2015 +0200 xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 warnings. policydb.c: In function â??user_readâ??: policydb.c:1443:26: error: â??buf[2]â?? may be used uninitialized in this function [-Werror=maybe-uninitialized] usrdatum->bounds = le32_to_cpu(buf[2]); ^ cc1: all warnings being treated as errors Which (as Andrew mentioned) is because GCC cannot assume that 'p->policyvers' has the same value between checks. We make it local, optimize the name to 'ver' and the warnings go away. We also update another call site with this modification to make it more inline with the rest of the functions. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> master commit: 6a2f81459e1455d65a9a6f78dd2a0d0278619680 master date: 2015-09-22 12:09:03 -0400 (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 |