* [xen-unstable-smoke test] 85819: regressions - FAIL
@ 2016-03-09 17:29 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2016-03-09 17:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 7536 bytes --]
flight 85819 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85819/
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 1 days
Testing same since 85819 2016-03-09 16:02:00 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Dario Faggioli <dario.faggioli@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
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@citrix.com>
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@cardoe.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 8979888d2d67ea6976438d392420dbc84f3868e4
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit cd29140ef0e65a33d62e7f5ee843077e51913f01
Author: Jan Beulich <jbeulich@suse.com>
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@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 882b186d56f1b294b57ea95dd1d83bc25def3c60
Author: Juergen Gross <jgross@suse.com>
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@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 8fa0fca9f3fdaac1aead9cf61d678a0d8cce02e2
Author: Juergen Gross <jgross@suse.com>
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@suse.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit d62ead2eb23491de50cf65f548d66c2e433de455
Author: Juergen Gross <jgross@suse.com>
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@suse.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-03-09 17:29 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-09 17:29 [xen-unstable-smoke test] 85819: regressions - FAIL osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).