xen.org
2013-Jul-22 19:39 UTC
[xen-unstable test] 18586: regressions - trouble: broken/fail/pass
flight 18586 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/18586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 18466
test-amd64-amd64-xl-winxpsp3 3 host-install(3) broken REGR. vs. 18466
test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 18466
test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail in 18582 REGR. vs.
18466
build-amd64-pvops 4 kernel-build fail in 18582 REGR. vs. 18466
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail pass in 18582
test-amd64-amd64-xl 16 guest-start.2 fail pass in 18585
test-amd64-i386-xl-multivcpu 9 guest-start fail pass in 18582
test-amd64-amd64-xl-sedf-pin 9 guest-start fail in 18585 pass in 18586
test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 18585 pass in 18586
test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 18585 pass in 18586
test-amd64-amd64-pv 9 guest-start fail in 18585 pass in 18586
test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 18585 pass in 18586
test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 18585 pass in
18586
test-amd64-i386-xl-multivcpu 3 host-install(3) broken in 18585 pass in 18586
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 18466
test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail in 18582 like 18466
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-pair 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-qemut-win7-amd64 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-winxpsp3 1 xen-build-check(1) blocked in 18582 n/a
test-amd64-amd64-xl-qemut-winxpsp3 1 xen-build-check(1) blocked in 18582 n/a
version targeted for testing:
xen 06132384118ece88b9d508b05cc5e42465a08502
baseline version:
xen d4435fe5e2f0dfadb41ef46c38f462f45d67762e
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Eric Trudeau <etrudeau@broadcom.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@linaro.org>
Keir Fraser <keir@xen.org>
Sander Eikelenboom <linux@eikelenboom.it>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tim Deegan <tim@xen.org>
Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl fail
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
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-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 broken
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 broken
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 06132384118ece88b9d508b05cc5e42465a08502
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Sun Jul 21 06:24:30 2013 +0100
xen: x86: put back .gz suffix on installed hypervisor binary.
This reverts the effect of 524b93def23b "xen: x86: drop the
".gz" suffix when
installing" which broke things in osstest (Debian Squeeze update-grub
apparently can''t cope). It is not a direct revert because of other
changes made
since. We continue to omit the suffix on ARM.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
commit 2a6327bf2bfaf5de5e07aed583d2c337c9d368c0
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Apr 26 11:58:47 2013 +0100
xen: arm: drop LDFLAGS_DIRECT emulation specification.
The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring
due
to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly
an Ubuntu gcc
bug, hwever when investigating I found that this option was not necessary at
all since we provide an explicit linker script when linking the hypervisor
(AFAICT all -m<foo> does is override the default linker script).
LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files
but
-m<emulatin> is not needed for this since it isn''t linking
the final image and
we are calling the linker with the correct, cross if necessary, name.
However it does appear to be potentially useful to supply -EL in both cases
to
ensure that we get little endian images. (I just happened to spot that Linux
does this, for both arm and arm64, although I expect we are unlikely to trip
over such toolchains these days).
Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
commit bbccf0d088d2041d95ede1d59fc195205f932f38
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Apr 25 15:45:50 2013 +0100
xen: arm: enable aborts on all physical processors.
I''m not sure how this ended up in construct dom0 where it only
affects the
boot cpu and doesn''t logically fit.
Enable aborts at the same time as we enable interrupts.
I''m not sure what the behaviour of an "abort worthy"
operation while aborts
are disable is, but it must surely be worse than calling do_unexpected_trap,
which is what happens from now on.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
commit c57c50c1de759583d5de629fec205254280da4f0
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Jul 17 12:18:51 2013 +0100
xen: arm: clear the exclusive monitor on exception return
Otherwise context switching between two vcpus which are contending the same
lock can result in a spurious success.
Our spinlock and atomics code (which we get from Linux) rely on this
behaviour
because they use non-exclusive stores for single instruction operations
(e.g.
spin_unlock or atomic_set).
This is not required on ARMv8 since eret implicitly clears the monitor.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
commit 47d1a51480ad0f602d747e460d619436c907deea
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Jul 12 12:54:42 2013 +0100
xen: arm: make zImage the default target which we install
The zImage compatible binary is the useful one on real hardware. The
relocated
ELF thing is only really useful when booting directly on Fast Models. The
customary suffix for that case is .axf so provide that as a target.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
commit 2f044a6a6e4cb0ea24c856c1615e3fb878af2cfb
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Jul 18 09:41:43 2013 +0100
xen: allow architecture to choose how/whether to compress installed xen
binary
This is a follow up to "xen: arm: make zImage the default target which
we
install".
On ARM the xen.gz binary installed into /boot is not immediately useful
because
bootloaders (e.g. u-boot) do not unconditionally support decompression
(except
via the uImage wrapper, which we currently do not support via our build
system)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 23e37f599e8bc220aca9abd097171ee17f5630ab
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Jul 18 09:41:42 2013 +0100
xen: Use $(T) and $(D) aliases in install target
This is consistent with the uninstall target and also shortens some longish
lines.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 524b93def23b9f75fd7851063f5291886e63d1ed
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Jul 18 09:41:41 2013 +0100
xen: x86: drop the ".gz" suffix when installing
As Jan says it is pretty meaningless under /boot anyway. However I am
slightly
concerned about breaking bootloaders (or more specifically their help
scripts
which automatically generate config files). By inspection at least grub
2''s
update-grub script (as present in Debian Wheezy) seems to cope (it matches
on
xen* not xen*.gz)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 09a08ef52a21d171cc48b54a975f13e7704c912f
Author: Julien Grall <julien.grall@linaro.org>
Date: Thu Jul 18 14:33:43 2013 +0100
xen/arm: Implement MPIDR per VCPU
Use different affinity for each VCPU and always expose an SMP systems to
the guest.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- s/AFFO/AFF0/ in a comment ]
commit 47193a4437f18cce75230e0fb1ca3b3c78fec7b0
Author: Eric Trudeau <etrudeau@broadcom.com>
Date: Fri Jul 12 13:30:48 2013 -0400
xen/arm: Clear the IRQ_GUEST bit in desc->status when releasing an IRQ
While adding support for guest domU IRQs, I noticed that release_irq did
not clear the IRQ_GUEST bit in the IRQ''s desc->status field.
This is probably not a big deal since not many situations are likely to
arise
where an IRQ is sometimes host and sometimes guest.
Signed-off-by: Eric Trudeau <etrudeau@broadcom.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
commit 3eb214917f45e567af87605c06c28cea4208faf4
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Jul 18 13:32:12 2013 +0200
VT-d: enable for multi-vector MSI
The main change being to make alloc_remap_entry() capable of allocating
a block of entries.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
commit e36e07bc9b0be0d899d4dd0ea675f6c225dafe5c
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Jul 18 10:05:14 2013 +0200
x86: fix cache flushing condition in map_pages_to_xen()
This fixes yet another shortcoming of the function (exposed by 8bfaa2c2
["x86: add locking to map_pages_to_xen()"]''s adjustment
to
msix_put_fixmap()): It must not flush caches when transitioning to a
non-present mapping. Doing so causes the CLFLUSH to fault, if used in
favor of WBINVD.
To help code readability, factor out the whole flush flags updating
in map_pages_to_xen() into a helper macro.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Keir Fraser <keir@xen.org>
commit 915a59f25c5eddd86bc2cae6389d0ed2ab87e69e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Jul 18 09:16:15 2013 +0200
x86/time: Update wallclock in shared info when altering domain time offset
domain_set_time_offset() udpates d->time_offset_seconds, but does not
correct
the wallclock in the shared info, meaning that it is incorrect until the
next
XENPF_settime hypercall from dom0 which resynchronises the wallclock for all
domains.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
(qemu changes not included)
Ian Campbell
2013-Jul-22 21:05 UTC
Re: [xen-unstable test] 18586: regressions - trouble: broken/fail/pass
On Mon, 2013-07-22 at 20:39 +0100, xen.org wrote:> flight 18586 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/18586/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 18466This guy failed 18585, 18586 and here. Looks like it may not be a random failure. Most stuff in the set of commits under test is ARM stuff, apart from: 3eb2149 VT-d: enable for multi-vector MSI e36e07b x86: fix cache flushing condition in map_pages_to_xen() 915a59f x86/time: Update wallclock in shared info when altering domain time offset I don''t see any guest logs or even a vnc screenshot though, unfortunately. There''s some wierdness, like http://www.chiark.greenend.org.uk/~xensrcts/logs/18586/test-amd64-i386-rhel6hvm-intel/bush-cricket---var-log-xen-xl-redhat.guest.osstest.log contains just: padding #padding #padding #padding #padding #padding #padding #paddi which is ... odd... I don''t see much evidence of anything else odd in the host logs.> test-amd64-amd64-xl-winxpsp3 3 host-install(3) broken REGR. vs. 18466 > test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 18466 > test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail in 18582 REGR. vs. 18466 > build-amd64-pvops 4 kernel-build fail in 18582 REGR. vs. 18466Not so sure about these ones, might be network infra issues?
Jan Beulich
2013-Aug-05 10:25 UTC
Re: [xen-unstable test] 18586: regressions - trouble: broken/fail/pass
>>> On 22.07.13 at 23:05, Ian Campbell <ian.campbell@citrix.com> wrote: > On Mon, 2013-07-22 at 20:39 +0100, xen.org wrote: >> flight 18586 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/18586/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 18466 > > This guy failed 18585, 18586 and here. Looks like it may not be a random > failure. Most stuff in the set of commits under test is ARM stuff, apart > from: > 3eb2149 VT-d: enable for multi-vector MSI > e36e07b x86: fix cache flushing condition in map_pages_to_xen() > 915a59f x86/time: Update wallclock in shared info when altering > domain time offsetI''m very certain that this is the problem fixed by the patch at http://lists.xenproject.org/archives/html/xen-devel/2013-07/msg01658.html; I had hoped that the patch would have got acked (and perhaps even applied) during my 2 week vacation, but neither of the two happened. As I''ll have to send out pings for pending patches anyway, I''ll include that one too. Jan