|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.5-testing test] 59792: regressions - FAIL
flight 59792 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/59792/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59527 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 59527 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59527 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail blocked in 59527 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59508 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59527 test-armhf-armhf-xl-rtds 11 guest-start fail like 59527 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start 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-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass version targeted for testing: xen 666b80f239c566283cb1b3435180d99a329d0156 baseline version: xen 36a7c54a698db7d087873b312087cfa64de33175 Last test of basis 59527 2015-07-14 01:40:53 Z 7 days Testing same since 59792 2015-07-21 09:35:47 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Liang Li <liang.z.li@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-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 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 fail test-amd64-amd64-rumpuserxen-amd64 fail 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-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 pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass 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-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 666b80f239c566283cb1b3435180d99a329d0156 Author: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx> Date: Tue Jul 21 11:13:03 2015 +0200 dmar: device scope mem leak fix Release memory allocated for scope.devices dmar units on various failure paths and when disabling dmar. Set device count after sucessfull memory allocation, not before, in device scope parsing function. Signed-off-by: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> # Commit 132231d10343608faf5892785a08acc500326d04 # Date 2015-07-16 15:23:37 +0200 # Author Andrew Cooper <andrew.cooper3@xxxxxxxxxx> # Committer Jan Beulich <jbeulich@xxxxxxxx> dmar: fix double free in error paths following c/s a8bc99b Several error paths would end up freeing scope->devices twice. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: a8bc99b981c5ad773bd646f5986e616d26fb94d7 master date: 2015-07-16 11:50:07 +0200 master commit: 132231d10343608faf5892785a08acc500326d04 master date: 2015-07-16 15:23:37 +0200 commit aa885a0c03ef8a2d26da0413de7d98382e496096 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jul 21 11:12:35 2015 +0200 make rangeset_report_ranges() report all ranges find_range() returns NULL when s is below the lowest range, so we have to use first_range() here (which is as good performance wise), or else no range gets reported at all in that case. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: b1c780cd315eb4db06be3bbb5c6d80b1cabd27a9 master date: 2015-07-15 16:11:42 +0200 commit cf423e947a9324801475956a4c3d7cc259f72e03 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Tue Jul 21 11:11:49 2015 +0200 xen: earlycpio: Pull in latest linux earlycpio.[ch] AFAICT our current version does not correspond to any version in the Linux history. This commit resynchronised to the state in Linux commit 598bae70c2a8e35c8d39b610cca2b32afcf047af. Differences from upstream: find_cpio_data is __init, printk instead of pr_*. This appears to fix Debian bug #785187. "Appears" because my test box happens to be AMD and the issue is that the (valid) cpio generated by the Intel ucode is not liked by the old Xen code. I've tested by hacking the hypervisor to look for the Intel path. Reported-by: Stephan Seitz <stse+debianbugs@xxxxxxxxxxxxxxxxxxx> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Cc: Jan Beulich <jbeulich@xxxxxxxx> Cc: Stephan Seitz <stse+debianbugs@xxxxxxxxxxxxxxxxxxx> Cc: 785187@xxxxxxxxxxxxxxx Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 39c6664a0e6e1b4ed80660d545dff34ce41bee31 master date: 2015-07-07 15:10:45 +0100 commit 8c166421b0af090813ad2cc691fad24784feaf1e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jul 21 11:11:19 2015 +0200 x86/hvmloader: avoid data corruption with xenstore reads/writes The functions ring_read and ring_write() have logic to try and deal with partial reads and writes. However, in all cases where the "while (len)" loop executed twice, data corruption would occur as the second memcpy() starts from the beginning of "data" again, rather than from where it got to. This bug manifested itself as protocol corruption when a reply header crossed the first wrap of the response ring. However, similar corruption would also occur if hvmloader observed xenstored performing partial writes of the block in question, or if hvmloader had to wait for xenstored to make space in either ring. Reported-by: Adam Kucia <djexit@xxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: bbbe7e7157a964c485fb861765be291734676932 master date: 2015-07-07 14:39:27 +0200 commit 7b1a3be78e2a0b61f28adf8579f23e71855fe676 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Tue Jul 21 11:10:11 2015 +0200 credit1: properly deal with pCPUs not in any cpupool Ideally, the pCPUs that are 'free', i.e., not assigned to any cpupool, should not be considred by the scheduler for load balancing or anything. In Credit1, we fail at this, because of how we use cpupool_scheduler_cpumask(). In fact, for a free pCPU, cpupool_scheduler_cpumask() returns a pointer to cpupool_free_cpus, and hence, near the top of csched_load_balance(): if ( unlikely(!cpumask_test_cpu(cpu, online)) ) goto out; is false (the pCPU _is_ free!), and we therefore do not jump to the end right away, as we should. This, causes the following splat when resuming from ACPI S3 with pCPUs not assigned to any pool: (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Tainted: C ]---- (XEN) ... ... ... (XEN) Xen call trace: (XEN) [<ffff82d080122eaa>] csched_load_balance+0x213/0x794 (XEN) [<ffff82d08012374c>] csched_schedule+0x321/0x452 (XEN) [<ffff82d08012c85e>] schedule+0x12a/0x63c (XEN) [<ffff82d08012fa09>] __do_softirq+0x82/0x8d (XEN) [<ffff82d08012fa61>] do_softirq+0x13/0x15 (XEN) [<ffff82d080164780>] idle_loop+0x5b/0x6b (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 8: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** The cure is: * use cpupool_online_cpumask(), as a better guard to the case when the cpu is being offlined; * explicitly check whether the cpu is free. SEDF is in a similar situation, so fix it too. Still in Credit1, we must make sure that free (or offline) CPUs are not considered "ticklable". Not doing so would impair the load balancing algorithm, making the scheduler think that it is possible to 'ask' the pCPU to pick up some work, while in reallity, that will never happen! Evidence of such behavior is shown in this trace: Name CPU list Pool-0 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 0.112998198 | ||.|| -|x||-|- d0v0 runstate_change d0v4 offline->runnable ] 0.112998198 | ||.|| -|x||-|- d0v0 22006(2:2:6) 1 [ f ] ] 0.112999612 | ||.|| -|x||-|- d0v0 28004(2:8:4) 2 [ 0 4 ] 0.113003387 | ||.|| -||||-|x d32767v15 runstate_continue d32767v15 running->running where "22006(2:2:6) 1 [ f ]" means that pCPU 15, which is free from any pool, is tickled. The cure, in this case, is to filter out the free pCPUs, within __runq_tickle(). Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> master commit: 02ea5031825d984d52eb9a982b8457e3434137f0 master date: 2015-07-07 14:30:06 +0200 commit de8b55032455a4b591f6a853fae24e474cd3835d Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Tue Jul 21 11:09:39 2015 +0200 x86 / cpupool: clear the proper cpu_valid bit on pCPU teardown In fact, when a pCPU goes down, we want to clear its bit in the correct cpupool's valid mask, rather than always in cpupool0's one. Before this commit, all the pCPUs in the non-default pool(s) will be considered immediately valid, during system resume, even the one that have not been brought up yet. As a result, the (Credit1) scheduler will attempt to run its load balancing logic on them, causing the following Oops: # xl cpupool-cpu-remove Pool-0 8-15 # xl cpupool-create name=\"Pool-1\" # xl cpupool-cpu-add Pool-1 8-15 --> suspend --> resume (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Tainted: C ]---- (XEN) CPU: 8 (XEN) RIP: e008:[<ffff82d080123078>] csched_schedule+0x4be/0xb97 (XEN) RFLAGS: 0000000000010087 CONTEXT: hypervisor (XEN) rax: 80007d2f7fccb780 rbx: 0000000000000009 rcx: 0000000000000000 (XEN) rdx: ffff82d08031ed40 rsi: ffff82d080334980 rdi: 0000000000000000 (XEN) rbp: ffff83010000fe20 rsp: ffff83010000fd40 r8: 0000000000000004 (XEN) r9: 0000ffff0000ffff r10: 00ff00ff00ff00ff r11: 0f0f0f0f0f0f0f0f (XEN) r12: ffff8303191ea870 r13: ffff8303226aadf0 r14: 0000000000000009 (XEN) r15: 0000000000000008 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 00000000dba9d000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) ... ... ... (XEN) Xen call trace: (XEN) [<ffff82d080123078>] csched_schedule+0x4be/0xb97 (XEN) [<ffff82d08012c732>] schedule+0x12a/0x63c (XEN) [<ffff82d08012f8c8>] __do_softirq+0x82/0x8d (XEN) [<ffff82d08012f920>] do_softirq+0x13/0x15 (XEN) [<ffff82d080164791>] idle_loop+0x5b/0x6b (XEN) (XEN) **************************************** (XEN) Panic on CPU 8: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** The reason why the error is a #GP fault is that, without this commit, we try to access the per-cpu area of a not yet allocated and initialized pCPU. In fact, %rax, which is what is used as pointer, is 80007d2f7fccb780, and we also have this: #define INVALID_PERCPU_AREA (0x8000000000000000L - (long)__per_cpu_start) Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Juergen Gross <jgross@xxxxxxxx> master commit: 8022b05284dea80e24813d03180788ec7277a0bd master date: 2015-07-07 14:29:39 +0200 commit 4b0782fe0b3aa53ca21517af1ce06bf186c24081 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jul 21 11:08:57 2015 +0200 x86/p2m-ept: don't unmap the EPT pagetable while it is still in use The call to iommu_pte_flush() between the two hunks uses &ept_entry->epte which is a pointer into the mapped page. It is eventually passed to `clflush` instruction which will suffer a pagefault if the virtual mapping has fallen out of the TLB. (XEN) ----[ Xen-4.5.0-xs102594-d x86_64 debug=y Not tainted ]---- (XEN) CPU: 7 (XEN) RIP: e008:[<ffff82d0801572f0>] cacheline_flush+0x4/0x9 <snip> (XEN) Xen call trace: (XEN) [<ffff82d0801572f0>] cacheline_flush+0x4/0x9 (XEN) [<ffff82d08014ffff>] __iommu_flush_cache+0x4a/0x6a (XEN) [<ffff82d0801532e2>] iommu_pte_flush+0x2b/0xd5 (XEN) [<ffff82d0801f909a>] ept_set_entry+0x4bc/0x61f (XEN) [<ffff82d0801f0c25>] p2m_set_entry+0xd1/0x112 (XEN) [<ffff82d0801f25b1>] clear_mmio_p2m_entry+0x1a0/0x200 (XEN) [<ffff82d0801f4aac>] unmap_mmio_regions+0x49/0x73 (XEN) [<ffff82d080106292>] do_domctl+0x15bd/0x1edb (XEN) [<ffff82d080234fcb>] syscall_enter+0xeb/0x145 (XEN) (XEN) Pagetable walk from ffff820040004ae0: (XEN) L4[0x104] = 00000008668a5063 ffffffffffffffff (XEN) L3[0x001] = 00000008668a3063 ffffffffffffffff (XEN) L2[0x000] = 000000086689c063 ffffffffffffffff (XEN) L1[0x004] = 000000056f078063 000000000007f678 (XEN) (XEN) **************************************** (XEN) Panic on CPU 7: (XEN) FATAL PAGE FAULT (XEN) [error_code=0000] (XEN) Faulting linear address: ffff820040004ae0 (XEN) **************************************** Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: e4e9d2d4e76bd8fe229c124bd57fc6ba824271b3 master date: 2015-07-07 11:37:26 +0200 commit 96289ee3250773011a1c3dcb1f5544c93fac7820 Author: Liang Li <liang.z.li@xxxxxxxxx> Date: Tue Jul 21 11:08:05 2015 +0200 nested EPT: fix the handling of nested EPT If the host EPT entry is changed, the nested EPT should be updated. the current code does not do this, and it's wrong. I have tested this patch, the L2 guest can boot and run as normal. Signed-off-by: Liang Li <liang.z.li@xxxxxxxxx> Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> Reported-by: Tim Deegan <tim@xxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 master date: 2015-06-30 15:00:54 +0100 (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 |