xen.org
2013-Aug-28 08:17 UTC
[xen-unstable test] 18784: regressions - trouble: broken/fail/pass
flight 18784 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/18784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 18778
test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 18778
test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 18778
test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 18778
test-amd64-i386-xend-winxpsp3 15 guest-destroy fail REGR. vs. 18778
test-amd64-i386-xend-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 18778
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 18778
test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 18778
test-amd64-amd64-pair 8 xen-boot/dst_host fail like 18770
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-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-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen 460dea6c817eada4f7d43097b1e71e975a7ba52b
baseline version:
xen 8a7769b4453168e23e8935a85e9a875ef5117253
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Campbell <ijc@hellion.org.uk>
Ian Jackson <ian.jackson@eu.citrix.com>
Jaeyong Yoo <jaeyong.yoo@samsung.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@linaro.org>
Keir Fraser <keir@xen.org>
Matt Wilson <msw@amazon.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 pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair fail
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv fail
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 broken
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
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 460dea6c817eada4f7d43097b1e71e975a7ba52b
Author: Jan Beulich <JBeulich@suse.com>
Date: Tue Aug 27 14:23:07 2013 +0100
tools: drop VT-i example
... as being another IA64 leftover.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
commit 7ac87d5e2096e4c33c0a5e24a1b4746b1a81a773
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Aug 22 16:24:46 2013 +0100
xen/arm: use defines for boot module indexes instead of open coded numbers
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
commit ca617a664aed71503695b6a9498963a5e9dddb24
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Aug 22 17:01:57 2013 +0100
xen: arm: indicate when we have early paniced
Otherwise the hypervisor simply appears to stop after a message which may or
may not look all that severe.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
commit 2050ad703c65ed997f1328af702054d1960fb168
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Aug 22 17:01:59 2013 +0100
pl011: early_panic if baud rate not set in hardware
Now that the driver defaults to BAUD_AUTO this can happen if the early uart
! console or if early printk isn''t in use.
The following division by zero causes a trap but that uses regular printk
and
not early_printk, so it is never seen.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
commit ceb93c72d2046bffecd57fcbebd04aa0801414a2
Author: Jaeyong Yoo <jaeyong.yoo@samsung.com>
Date: Fri Aug 23 18:08:41 2013 +0900
xen/arm: add lower-bound check in mfn_valid
mfn_valid only checks the upper-bound of mfn (max_page).
Add the lower-bound check of mfn (frametable_base_mfn).
Signed-off-by: Jaeyong Yoo <jaeyong.yoo@samsung.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
commit 604ab14cde7aef3bcdd7bc3bc398e7d1705dc631
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Aug 26 20:18:33 2013 +0100
xen/arm: Introduce and use GLOBAL() in asm code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 1c413bf7f2ff372e00d2d78a8904a0ade2420f0a
Author: Julien Grall <julien.grall@linaro.org>
Date: Tue Aug 27 13:13:35 2013 +0100
drivers/char: pl011: Enable receive timeout interrupt
The commit 874f76a "PL011: fix reverse logic for interrupt mask
register"
introduced regression on the Versatile Express. The board didn''t
receive
correctly input.
The timeout interrupt may be asserted when the FIFO is not empty, and no
futher
data is received over a 32-bit period.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit e15c09f90c6629ef36bf6b4d5534dfc3b0b3de01
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Aug 27 15:13:20 2013 +0200
Revert "x86/boot: Explicitly clean pcpu stacks in debug builds"
This reverts commit 8a3c4acc9907cfec9aae9f1bc251fbf50af6828e.
It''s reportedly broken.
commit 258d27a1d9fb33a490bef1381f52d522225c3dca
Author: Ian Campbell <ijc@hellion.org.uk>
Date: Fri Aug 16 15:21:05 2013 +0100
pygrub: add Debian extlinux.conf path
This is Debian bug #697407.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697407
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit 44db24103ff1c53a13afebf4d72ad853cee07786
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Aug 27 11:29:03 2013 +0200
fix gdbstub build c/s c8177e691f
That changeset moved the watchdog functions from nmi.h to their own
watchdog.h. I thought I had updated all relevant header files and the
compiler was happy as well. However, gdbstub is not even compiled by
default,
and I accidentally missed it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 8a3c4acc9907cfec9aae9f1bc251fbf50af6828e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Aug 27 11:28:26 2013 +0200
x86/boot: Explicitly clean pcpu stacks in debug builds
This reduces confusion when looking at a hexdump of the pcpu stacks and
wondering were on earth some of the junk was coming from. Also leave some
grep fodder for finding where the BSP switches stack (because it took me
far longer to find than I care to admit to).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 483814219bc4d47db8a56116290ec7878b794c09
Author: Matt Wilson <msw@amazon.com>
Date: Tue Aug 27 11:23:09 2013 +0200
x86/time: remove Cyclone as a platform timer
The Cyclone time source was part of IBM''s Summit chipset, which was
only used for 32-bit only ccNUMA and IA-64 machines. Neither of these
are supported by Xen anymore.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit c8e2fd7edced5ef28ff57524f8f744c042e57c59
Author: Matt Wilson <msw@amazon.com>
Date: Tue Aug 27 11:20:17 2013 +0200
x86/apic: remove Summit support
IBM''s Summit chipset was only used for 32-bit only Intel ccNUMA and
IA-64 machines, neither of which are supported by Xen anymore.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 3e787021fb2420851c7bdc3911ea53c728ba5ac0
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Aug 27 11:15:15 2013 +0200
x86/Intel: add support for Haswell CPU models
... according to their most recent public documentation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
commit 784ce3fd05476ffe46bf54579f3927c777eb2c3b
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Aug 27 11:13:50 2013 +0200
VMX: convert EOI exit bitmap to a proper bitmap
... allowing bitmap operations to be used on it, making things
consistent with struct pi_desc''s pir field, and shrinking overall
source code size.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
commit d838ac2539cf1987bea6e15662fd6a80a58fe26d
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Aug 27 11:12:12 2013 +0200
x86: don''t allow Dom0 access to the HT address range
In particular, MMIO assignments should not be done using this area.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
commit 850188e1278cecd1dfb9b936024bee2d8dfdcc18
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Aug 27 11:11:38 2013 +0200
x86: don''t allow Dom0 access to the MSI address range
In particular, MMIO assignments should not be done using this area.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>
(qemu changes not included)
Jan Beulich
2013-Aug-28 09:00 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
>>> On 28.08.13 at 10:17, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 18784 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/18784/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 18778 > test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 18778 > test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 18778 > test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 18778 > test-amd64-i386-xend-winxpsp3 15 guest-destroy fail REGR. vs. 18778 > test-amd64-i386-xend-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 18778 > > Regressions which are regarded as allowable (not blocking): > test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 18778 > test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 18778 > test-amd64-amd64-pair 8 xen-boot/dst_host fail like 18770At first I thought this ought to be a regression from either or both of 850188e1 and d838ac25 ("x86: don''t allow Dom0 access to the MSI/HT address range"; those at least seem the most likely candidates to cause an early Dom0 death), but checking test-amd64-amd64-xl-win7-amd64 the same kernel (afaict) boots fine there. The MSI change clearly isn''t machine specific; the HT one of course gets used on AMD systems only (and indeed the failures are all on either of the two frogs, which are AMD systems, but iirc they''re not the only ones - Ian?). Ian - I further wonder whether it wouldn''t be good to always have "earlyprintk=xen" on the kernel command lines of the test infrastructure, to have better chances of investigating issues like this. And in any case the question of course is whether a failure with this old a Dom0 kernel really counts as a regression. It needs to be considered whether re-opening the latent problem these two changes address (and the HT one much more so than the MSI one, where from the above it looks like the MSI one isn''t causing problems) is really better than rendering very old Dom0 kernels unusable. Jan
Jan Beulich
2013-Aug-28 14:10 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
>>> On 28.08.13 at 11:00, "Jan Beulich" <JBeulich@suse.com> wrote: > At first I thought this ought to be a regression from either or both > of 850188e1 and d838ac25 ("x86: don''t allow Dom0 access to the > MSI/HT address range"; those at least seem the most likely > candidates to cause an early Dom0 death), but checking > test-amd64-amd64-xl-win7-amd64 the same kernel (afaict) boots > fine there. The MSI change clearly isn''t machine specific; the HT > one of course gets used on AMD systems only (and indeed the > failures are all on either of the two frogs, which are AMD > systems, but iirc they''re not the only ones - Ian?). > [...] > And in any case the question of course is whether a failure with > this old a Dom0 kernel really counts as a regression. It needs to > be considered whether re-opening the latent problem these two > changes address (and the HT one much more so than the MSI > one, where from the above it looks like the MSI one isn''t causing > problems) is really better than rendering very old Dom0 kernels > unusable.So I want and booted the very kernel supposedly used there on one of my AMD boxes. Afaict it gets farther than on the frogs, but eventually crashes nevertheless, due to a very obvious bug: It tries to relocate the memory overlapping non-RAM regions in the machine memory map to physical addresses beyond the highest E820 entry (which with said patch is guaranteed to be no less than 1Tb), but at the same time its __set_phys_to_machine() BUG()s on any PFN beyond 512Gb. So - do we need to support this kind of a buggy kernel, and hence continue to rely on Dom0 to avoid the HT area when assigning MMIO regions (guaranteeing of which Linux, including when running native, up to now neglects altogether)? From all I can tell modern pv-ops relocates the overlapping memory into higher RAM regions mentioned in the machine E820, i.e. should not be susceptible to this change. Jan
Ian Jackson
2013-Aug-28 15:05 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 18784: regressions
- trouble: broken/fail/pass"):> So I want and booted the very kernel supposedly used there
Thanks for investigating.
> So - do we need to support this kind of a buggy kernel
No.
The test system has its own kernel branch which it subjects to a push
gate, to try to stop kernel regressions from causing the rest of our
tests to be blocked.
But, looking at it, the source branch for that push gate is still a
branch of Jeremy''s.
I would be happy to change it to something else. However, Linus''s
linux tip is probably not suitable as you can see that its own tests
in my system report regressions. (Also, is it a fast forward from
Jeremy''s branch?)
If you point me at something else to use as input to the push gate I
would be happy to use that.
Thanks,
Ian.
Ian Campbell
2013-Aug-28 15:12 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
Adding Konrad On Wed, 2013-08-28 at 16:05 +0100, Ian Jackson wrote:> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 18784: regressions - trouble: broken/fail/pass"): > > So I want and booted the very kernel supposedly used there > > Thanks for investigating. > > > So - do we need to support this kind of a buggy kernel > > No. > > The test system has its own kernel branch which it subjects to a push > gate, to try to stop kernel regressions from causing the rest of our > tests to be blocked. > > But, looking at it, the source branch for that push gate is still a > branch of Jeremy''s. > > I would be happy to change it to something else. However, Linus''s > linux tip is probably not suitable as you can see that its own tests > in my system report regressions. (Also, is it a fast forward from > Jeremy''s branch?)You aren''t going to find anything useful which is a ff from Jeremy''s branch. I hope it''s not a hard requirement.> If you point me at something else to use as input to the push gate I > would be happy to use that. > > Thanks, > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Ian Jackson
2013-Aug-28 15:15 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 18784:
regressions - trouble: broken/fail/pass"):> Adding Konrad
...> On Wed, 2013-08-28 at 16:05 +0100, Ian Jackson wrote:
...> > I would be happy to change it to something else. However,
Linus''s
> > linux tip is probably not suitable as you can see that its own tests
> > in my system report regressions. (Also, is it a fast forward from
> > Jeremy''s branch?)
>
> You aren''t going to find anything useful which is a ff from
Jeremy''s
> branch. I hope it''s not a hard requirement.
If it''s not a ff then I should change the "output" branch of
the
kernel push gate as well as the "input" branch, in which case
regressions from the change will show up as a failure of osstest''s own
push gate, which would be annoying but not a blocker.
Ian.
Jan Beulich
2013-Aug-28 15:21 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
>>> On 28.08.13 at 17:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > If you point me at something else to use as input to the push gate I > would be happy to use that.I guess the kernel maintainers are in a better position to point out the most stable tree/branch to follow for that purpose. Jan
Ian Jackson
2013-Aug-28 15:24 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 18784: regressions
- trouble: broken/fail/pass"):> On 28.08.13 at 17:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > If you point me at something else to use as input to the push gate I
> > would be happy to use that.
>
> I guess the kernel maintainers are in a better position to point out
> the most stable tree/branch to follow for that purpose.
Is there a single branch or tag that always corresponds to the
"current stable kernel" ? Or do we have to update this every n months
?
Ian.
David Vrabel
2013-Aug-28 15:33 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
On 28/08/13 16:24, Ian Jackson wrote:> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 18784: regressions - trouble: broken/fail/pass"): >> On 28.08.13 at 17:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >>> If you point me at something else to use as input to the push gate I >>> would be happy to use that. >> >> I guess the kernel maintainers are in a better position to point out >> the most stable tree/branch to follow for that purpose. > > Is there a single branch or tag that always corresponds to the > "current stable kernel" ? Or do we have to update this every n months ?No. Each stable series has its own branch. I would recommend using the 3.10.y stable tree which is the current longterm stable tree. git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git branch: linux-3.10.y David
Jan Beulich
2013-Aug-28 15:38 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
>>> On 28.08.13 at 17:24, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 18784: regressions - > trouble: broken/fail/pass"): >> On 28.08.13 at 17:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> > If you point me at something else to use as input to the push gate I >> > would be happy to use that. >> >> I guess the kernel maintainers are in a better position to point out >> the most stable tree/branch to follow for that purpose. > > Is there a single branch or tag that always corresponds to the > "current stable kernel" ? Or do we have to update this every n months ?I don''t think there is, but I''d be glad to be told differently. Jan
Ian Jackson
2013-Aug-28 15:53 UTC
Re: [xen-unstable test] 18784: regressions - trouble: broken/fail/pass
David Vrabel writes ("Re: [Xen-devel] [xen-unstable test] 18784:
regressions - trouble: broken/fail/pass"):> No. Each stable series has its own branch.
Oh well.
> I would recommend using the 3.10.y stable tree which is the current
> longterm stable tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>
> branch: linux-3.10.y
OK. I have made what I think are the relevant changes. Specifically,
I have:
* Created a push gate for linux-3.10.y -> our tested/linux-3.0 branch
(and pushed what is currently at 3.10.y to our branch)
* Dropped the tests of "linux" (Jeremy''s branch)
* Switched the baseline kernel version for all other tests to
our tested/3.10.
I expect to have some results from this tomorrow. If I''m lucky I
won''t have typoed one of the scripts...
Ian.