|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 85827: regressions - FAIL
flight 85827 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/85827/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85661 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-check fail never pass version targeted for testing: xen 6890e07e483673ec5f946b7c4654275707924d6d baseline version: xen 0aa1330aac92fd75f185c9b354396014178fe95d Last test of basis 85661 2016-03-07 18:02:23 Z 2 days Testing same since 85819 2016-03-09 16:02:00 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 6890e07e483673ec5f946b7c4654275707924d6d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Mar 9 16:52:31 2016 +0100 mm: fix page_list_* helpers to evaluate all their arguments If an architecture does not provide a custom page_list_entry, default page_list_* helpers are provided, wrapping list_head as an underlying type for page_list_head. The two declarations of the page_list_* helpers differ between defines and static inline functions, where the defines discard some of their parameters. This causes a compilation failure if CONFIG_BIGMEM and debug=n in p2m-pod.c: p2m-pod.c: In function Â?p2m_pod_cache_addÂ?: p2m-pod.c:72:20: error: unused variable Â?dÂ? [-Werror=unused-variable] struct domain *d = p2m->domain; ^ cc1: all warnings being treated as errors because the use of d outside of the !NDEBUG section doesn't get evaluated as a parameter by page_list_del(). Fix this by turning all #defines into static inline functions, so all parameters are evaluated even if they are not used. While editing this area, correct the return type of page_list_empty from int to bool_t. No functional change. Reported-by: Doug Goldstein <cardoe@xxxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Doug Goldstein <cardoe@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 8979888d2d67ea6976438d392420dbc84f3868e4 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Mar 9 16:51:50 2016 +0100 mm: introduce arch_free_heap_page() common/page_alloc.c references d->arch.relmem_list, which only exists on x86. This only compiles on ARM because page_list_del2() discards its second argument. Introduce a new common arch_free_heap_page() which only uses common lists in struct domain, and allow an architecture to override this with a custom alternative. x86 then provides a custom arch_free_heap_page() which takes care of managing d->arch.relmem_list. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit cd29140ef0e65a33d62e7f5ee843077e51913f01 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Mar 9 16:51:16 2016 +0100 x86/alternatives: correct near branch check Make sure the near JMP/CALL check doesn't consume uninitialized data, not even in a benign way. And relax the length check at once. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 882b186d56f1b294b57ea95dd1d83bc25def3c60 Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Mar 9 16:50:29 2016 +0100 domctl: add force flag to xen_domctl_vcpuaffinity for undoing pin override Add a XEN_VCPUAFFINITY_FORCE flag to xen_domctl_vcpuaffinity structure which will allow to undo a SCHEDOP_pin_override in case of a driver error of the hardware domain which didn't do the expected SCHEDOP_pin_override with cpu < 0 which would have done the undo operation. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 8fa0fca9f3fdaac1aead9cf61d678a0d8cce02e2 Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Mar 9 16:49:59 2016 +0100 sched: add hypercall option to override and restore vcpu affinity Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be called on physical cpu 0 only. Linux drivers like dcdbas or i8k try to achieve this by pinning the running thread to cpu 0, but in Dom0 this is not enough: the vcpu must be pinned to physical cpu 0 via Xen, too. Add a stable hypercall option SCHEDOP_pin_override to the sched_op hypercall to achieve this. It is taking a physical cpu number as parameter. If pinning is possible (the calling domain has the privilege to make the call and the cpu is available in the domain's cpupool) the calling vcpu is pinned to the specified cpu. The old cpu affinity is saved. To undo the override pinning a negative cpu value is specified. This will restore the original cpu affinity of the vcpu. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit d62ead2eb23491de50cf65f548d66c2e433de455 Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Mar 9 16:44:04 2016 +0100 cpupool: correct error handling when removing cpu from cpupool When schedule_cpu_switch() called from cpupool_unassign_cpu_helper() returns an error, the domlist_read_lock isn't released again. As cpu_disable_scheduler() might have changed affinity of some domains domain_update_node_affinity() must be called for all domains in the cpupool even in error case. Even if looking weird it is okay to let the to be removed cpu set in cpupool_free_cpus in case of an error returned by cpu_disable_scheduler(). Add a comment explaining the reason for this. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |