* [xen-unstable test] 18528: regressions - FAIL
@ 2013-07-20 21:12 xen.org
0 siblings, 0 replies; only message in thread
From: xen.org @ 2013-07-20 21:12 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 18528 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/18528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-pv 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-pair 6 xen-install/dst_host fail REGR. vs. 18466
test-amd64-amd64-pair 5 xen-install/src_host fail REGR. vs. 18466
test-amd64-amd64-xl-qemut-win7-amd64 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-qemuu-winxpsp3 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-qemuu-win7-amd64 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-win7-amd64 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-winxpsp3 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-qemut-winxpsp3 4 xen-install fail REGR. vs. 18466
build-i386-pvops 4 kernel-build fail REGR. vs. 18466
build-i386-oldkern 4 xen-build fail REGR. vs. 18466
build-i386 4 xen-build fail REGR. vs. 18466
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-pcipt-intel 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-sedf-pin 4 xen-install fail REGR. vs. 18466
test-amd64-amd64-xl-sedf 4 xen-install fail REGR. vs. 18466
Tests which did not succeed, but are not blocking:
test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemut-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-xend-qemut-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen 2a6327bf2bfaf5de5e07aed583d2c337c9d368c0
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 fail
build-amd64-oldkern pass
build-i386-oldkern fail
build-amd64-pvops pass
build-i386-pvops fail
test-amd64-amd64-xl fail
test-amd64-i386-xl blocked
test-amd64-i386-rhel6hvm-amd blocked
test-amd64-i386-qemut-rhel6hvm-amd blocked
test-amd64-i386-qemuu-rhel6hvm-amd blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 blocked
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 blocked
test-amd64-i386-xl-credit2 blocked
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel blocked
test-amd64-i386-qemut-rhel6hvm-intel blocked
test-amd64-i386-qemuu-rhel6hvm-intel blocked
test-amd64-i386-xl-multivcpu blocked
test-amd64-amd64-pair fail
test-amd64-i386-pair blocked
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv fail
test-amd64-i386-pv blocked
test-amd64-amd64-xl-sedf fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked
test-amd64-i386-xl-winxpsp3-vcpus1 blocked
test-amd64-i386-xend-qemut-winxpsp3 blocked
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 blocked
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
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 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)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2013-07-20 21:12 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-20 21:12 [xen-unstable test] 18528: regressions - FAIL xen.org
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).