|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.6-testing baseline-only test] 67667: tolerable FAIL
This run is configured for baseline tests only. flight 67667 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67667/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-i386-pvgrub 10 guest-start fail like 67599 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67599 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 67599 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67599 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 67599 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail like 67599 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 build-i386-rumprun 5 rumprun-build fail never pass build-amd64-rumprun 5 rumprun-build 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-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-xl-midway 12 migrate-support-check fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-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-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore 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-libvirt 14 guest-saverestore 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-amd64-amd64-libvirt-xsm 12 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-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 4627e5e5f10bf8cdebaf45b66a476c4adb104f6d baseline version: xen a00a0f9139c4b3a9db8e74aca0ac0808e6f7d65b Last test of basis 67599 2016-08-26 20:44:22 Z 12 days Testing same since 67667 2016-09-07 15:46:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm 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 fail build-i386-rumprun fail 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 fail 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 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 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-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 blocked test-amd64-amd64-qemuu-nested-intel fail 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-armhf-armhf-xl-midway 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 fail 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 pass test-amd64-amd64-xl-rtds pass 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 fail 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ------------------------------------------------------------ commit 4627e5e5f10bf8cdebaf45b66a476c4adb104f6d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 6 11:52:22 2016 +0200 memory: fix compat handling of XENMEM_access_op Within compat_memory_op() this needs to be placed in the first switch() statement, or it ends up being dead code (as that first switch() has a default case chaining to compat_arch_memory_op()). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 8d6af808a7e9d9ae1d129e1e5a0def7f8b2333ee master date: 2016-09-02 14:19:51 +0200 commit 1663655cd05bc4db1344907b7404217453b79b66 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 6 11:51:59 2016 +0200 x86/PV: make PMU MSR handling consistent So far accesses to Intel MSRs on an AMD system fall through to the default case, while accesses to AMD MSRs on an Intel system bail (in the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on Intel" case match the "Intel MSR on AMD" one. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: bea64b3ed25864b90a41e1ca6eeb5a58895bb751 master date: 2016-09-02 14:19:29 +0200 commit 5bb458bec9199785eda4f47cf98eb1fde7921515 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Tue Sep 6 11:51:34 2016 +0200 credit1: fix a race when picking initial pCPU for a vCPU In the Credit1 hunk of 9f358ddd69463 ("xen: Have schedulers revise initial placement") csched_cpu_pick() is called without taking the runqueue lock of the (temporary) pCPU that the vCPU has been assigned to (e.g., in XEN_DOMCTL_max_vcpus). However, although 'hidden' in the IS_RUNQ_IDLE() macro, that function does access the runq (for doing load balancing calculations). Two scenarios are possible: 1) we are on cpu X, and IS_RUNQ_IDLE() peeks at cpu's X own runq; 2) we are on cpu X, but IS_RUNQ_IDLE() peeks at some other cpu's runq. Scenario 2) absolutely requies that the appropriate runq lock is taken. Scenario 1) works even without taking the cpu's own runq lock. That is actually what happens when when _csched_pick_cpu() is called from csched_vcpu_acct() (in turn, called by csched_tick()). Races have been observed and reported (by both XenServer own testing and OSSTest [1]), in the form of IS_RUNQ_IDLE() falling over LIST_POISON, because we're not currently holding the proper lock, in csched_vcpu_insert(), when scenario 1) occurs. However, for better robustness, from now on we always ask for the proper runq lock to be held when calling IS_RUNQ_IDLE() (which is also becoming a static inline function instead of macro). In order to comply with that, we take the lock around the call to _csched_cpu_pick() in csched_vcpu_acct(). [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02144.html Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 9109bf55084398c4547b8956906410c158eb9a17 master date: 2016-09-02 14:17:55 +0200 commit 40592ed5717c772eb4e4757f4a8792fac6cfa361 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Sep 6 11:51:05 2016 +0200 x86/32on64: misc adjustments to call gate emulation - There's no 32-bit displacement in 16-bit addressing mode. - It is wrong to ASSERT() anything on parts of an instruction fetched from guest memory. - The two scaling bits of a SIB byte don't affect whether there is a scaled index register or not. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: ee1cc4bfdca84d526805c4c72302c026f5e9cd94 master date: 2016-09-01 15:23:46 +0200 commit 0d9c05d8146e4e72ed6029102c19eb68e829c4f0 Author: George Dunlap <george.dunlap@xxxxxxxxxx> Date: Tue Sep 6 11:49:37 2016 +0200 xen: Remove buggy initial placement algorithm The initial placement algorithm sometimes picks cpus outside of the mask it's given, does a lot of unnecessary bitmasking, does its own separate load calculation, and completely ignores vcpu hard and soft affinities. Just get rid of it and rely on the schedulers to do initial placement. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: d5438accceecc8172db2d37d98b695eb8bc43afc master date: 2016-07-26 10:44:06 +0100 commit a149a6e7c45eaa368956ed3197761c25437e12cd Author: George Dunlap <george.dunlap@xxxxxxxxxx> Date: Tue Sep 6 11:49:13 2016 +0200 xen: Have schedulers revise initial placement The generic domain creation logic in xen/common/domctl.c:default_vcpu0_location() attempts to try to do initial placement load-balancing by placing vcpu 0 on the least-busy non-primary hyperthread available. Unfortunately, the logic can end up picking a pcpu that's not in the online mask. When this is passed to a scheduler such which assumes that the initial assignment is valid, it causes a null pointer dereference looking up the runqueue. Furthermore, this initial placement doesn't take into account hard or soft affinity, or any scheduler-specific knowledge (such as historic runqueue load, as in credit2). To solve this, when inserting a vcpu, always call the per-scheduler "pick" function to revise the initial placement. This will automatically take all knowledge the scheduler has into account. csched2_cpu_pick ASSERTs that the vcpu's pcpu scheduler lock has been taken. Grab and release the lock to minimize time spend with irqs disabled. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx> Reviewed-by: Meng Xu <mengxu@xxxxxxxxxxxxx> Reviwed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> master commit: 9f358ddd69463fa8fb65cf67beb5f6f0d3350e32 master date: 2016-07-26 10:42:49 +0100 commit 4260eefcd882df503ead27781bb51433dfa4137b Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Tue Sep 6 11:48:07 2016 +0200 sched: better handle (not) inserting idle vCPUs in runqueues Idle vCPUs are set to run immediately, as a part of their own initialization, so we shouldn't even try to put them in a runqueue. In fact, no scheduler does that, even when asked to (that is rather explicit in Credit2 and RTDS, a bit less evident in Credit1). Let's make things look as follows: - in generic code, explicitly avoid even trying to insert idle vCPUs in runqueues; - in specific schedulers' code, enforce that. Note that, as csched_vcpu_insert() is no longer being called, during boot (from sched_init_vcpu()) we can safely avoid saving the flags when taking the runqueue lock. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> master commit: 6b53bb4ab3c9bd5eccde88a5175cf72589ba6d52 master date: 2015-11-24 14:49:47 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |