* [xen-unstable-smoke test] 100733: regressions - trouble: blocked/broken/pass
@ 2016-09-02 15:03 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2016-09-02 15:03 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 100733 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail REGR. vs. 100732
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
version targeted for testing:
xen 158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
xen f59174d7e5fb8bb530246003d373345b5b433ea0
Last test of basis 100732 2016-09-02 12:01:43 Z 0 days
Testing same since 100733 2016-09-02 14:01:51 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Dario Faggioli <dario.faggioli@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Razvan Cojocaru <rcojocaru@bitdefender.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64 pass
build-armhf broken
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
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 158dd1bdca161a6456ee6be293969f87ecde3922
Author: Wei Liu <wei.liu2@citrix.com>
Date: Mon Aug 15 16:27:27 2016 +0100
tools: delete gtraceview and gtracestat
There has not been any substantial update to them since 2011. My quick
check shows that they don't work.
Just delete them. It would be easy to resurrect them from git log should
people still need them.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit 341e8c0b7a13fa5e23337e77b6df202c79e088da
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 2 14:22:28 2016 +0200
x86/mm: drop pointless use of __FUNCTION__
Non-debugging message text should be (and is here) distinguishable
without also logging function names.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
commit 6dc9ac9f52b8651b5700e24567fadd5b2b61786d
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 2 14:20:23 2016 +0200
x86emul: check alignment of SSE and AVX memory operands
It only now occurred to me that there's no new hook needed to do so.
Eliminate the two work item comments.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 8d6af808a7e9d9ae1d129e1e5a0def7f8b2333ee
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 2 14:19:51 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@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit bea64b3ed25864b90a41e1ca6eeb5a58895bb751
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 2 14:19:29 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@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit f8f185dc4359a1cd8e7896dfbcacb54b473436c8
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 2 14:18:52 2016 +0200
x86: correct PT_NOTE file position
Program and section headers disagreed about the file offset at which
the build ID note lives.
Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 9109bf55084398c4547b8956906410c158eb9a17
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Sep 2 14:17:55 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@citrix.com>
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-09-02 15:03 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-02 15:03 [xen-unstable-smoke test] 100733: regressions - trouble: blocked/broken/pass 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).