flight 9292 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9292/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-amd64-xl-sedf 16 guest-start.2 fail REGR. vs. 9252
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
version targeted for testing:
xen a65693f9fb12
baseline version:
xen 4b0907c6a08c
------------------------------------------------------------
People who touched revisions under test:
Christoph Egger <Christoph.Egger@amd.com>
Guido Gunther <agx@sigxcpu.org>
Haitao Shan <maillists.shan@gmail.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
Roger Pau Monne <roger.pau@entel.upc.edu>
Shan Haitao <haitao.shan@intel.com>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win 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.
------------------------------------------------------------
changeset: 23956:a65693f9fb12
tag: tip
user: Keir Fraser <keir@xen.org>
date: Thu Oct 13 15:59:22 2011 +0100
x86: Simplify smpboot_alloc by merging x86-{32,64} code as far as
possible.
We still need one ifdef, as x86-32 does not have a compat_gdt_table.
On x86-32 there is 1/2-page wastage due to allocating a whole page for
the per-CPU IDT, however we expect very few users of the x86-32
hypervisor. Those that cannot move to the 64-bit hypervisor are likely
using old single-processor systems or new single-procesor netbooks. On
UP and small MP systems, the wastage is insignificant.
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
changeset: 23955:bbde1453cbd9
user: Shan Haitao <haitao.shan@intel.com>
date: Thu Oct 13 15:58:55 2011 +0100
x86: Further fixes for xsave leaf in pv_cpuid().
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
changeset: 23954:c1bd53fac3d5
user: Christoph Egger <Christoph.Egger@amd.com>
date: Thu Oct 13 12:21:10 2011 +0100
nestedsvm: fix checks of guest writes to HSAVE_PA MSR
Accessing HSAVE_PA MSR does not require SVM to be enabled nor any
special guest paging mode.
But accessing HSAVE_PA MSR requires the address to be 4k aligned.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 23953:eda18b27de6e
user: Olaf Hering <olaf@aepfle.de>
date: Thu Oct 13 12:21:10 2011 +0100
xenpaging: handle evict failures
Evict of a nominated gfn must fail if some other process mapped the
page without checking the p2mt of that gfn first.
Add a check to cancel eviction if the page usage count is not 1.
Handle the possible eviction failure in the page-in paths.
After nominate and before evict, something may check the p2mt and call
populate. Handle this case and let the gfn enter the page-in path. The
gfn may still be connected to a mfn, so there is no need to allocate a
new page in prep.
Adjust do_mmu_update to return -ENOENT only if the gfn has entered the
page-in path and if it is not yet connected to a mfn. Otherwise
linux_privcmd_map_foreign_bulk() may loop forever.
Add MEM_EVENT_FLAG_EVICT_FAIL to inform pager that a page-in request for
a possible not-evicted page was sent. xenpaging does currently not need
that flag because failure to evict a gfn will be caught.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 23952:1515484353c6
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 13 10:09:28 2011 +0200
VMX: extend last branch MSR info to cover newer CPU models
There are still a couple of family 6 models missing here: 37, 44, 46,
and 47 (according to SDM doc changes May 2011); presumably they would
all go into the Nehalem/Sandy Bridge group. Intel?
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Haitao Shan <maillists.shan@gmail.com>
changeset: 23951:8c1e7830112f
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 13 10:03:43 2011 +0200
xmalloc: return unused full pages on multi-page allocations
Certain (boot time) allocations are relatively large (particularly when
building with high NR_CPUS), but can also happen to be pretty far away
from a power-of-two size. Utilize the page allocator''s (other than
Linux''es) capability of allowing to return space from higher-order
allocations in smaller pieces to return the unused parts immediately.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23950:46ca8ea42d4c
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 13 10:02:34 2011 +0200
x86-64: don''t use xmalloc_array() for allocation of the (per-CPU)
IDTs
The IDTs being exactly a page in size, using xmalloc() here is rather
inefficient, as this requires double the amount to be allocated (with
almost an entire page wasted). For hot plugged CPUs, this at once
eliminates one more non-order-zero runtime allocation.
For x86-32, however, the IDT is exactly half a page, so allocating a
full page seems wasteful here, so it continues to use xmalloc() as
before.
With most of the affected functions'' bodies now being inside
#ifdef-s,
it might be reasonable to split those parts out into subarch-specific
code...
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23949:39df16923958
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 13 10:00:13 2011 +0200
constify vcpu_set_affinity()''s second parameter
None of the callers actually make use of the function''s returning
of
the old affinity through its second parameter, and eliminating this
capability allows some callers to no longer use a local variable here,
reducing their stack footprint significantly when building with large
NR_CPUS.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23948:dcb2bd283dca
user: Keir Fraser <keir@xen.org>
date: Wed Oct 12 17:11:28 2011 +0100
Revert part of 23811:f1349a968a5a "ns16550: Simplify UART..."
The change to poll LSR.THRE in a loop from __ns16550_poll is a bug.
We can loop indefinitely if there are no chars to transmit.
Thanks to Jan for spotting it.
Signed-off-by: Keir Fraser <keir@xen.org>
changeset: 23947:48aa733d0767
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Oct 12 16:21:32 2011 +0100
libxl: fixup incorrect indentation
Several places which were previsously indented using hard tabs are now
incorrectly indented. Fix them up.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23946:e65977f3fa86
user: Ian Campbell <ian.campbell@citrix.com>
date: Tue Oct 11 14:34:07 2011 +0100
libxl: fixup incorrect indentation
Several places which were previsously indented using hard tabs are now
incorrectly indented. Fix them up.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23945:c5f8c3597cae
user: Ian Campbell <ian.campbell@citrix.com>
date: Tue Oct 11 14:26:00 2011 +0100
libxl: expand hard tab stops
I ran the following and committed the result. ^I is an actual hard tab
for i in $(grep -l --exclude=*_[ly].\[ch\] ''^I''
tools/libxl/*.[ch]) ; do
cat $i | expand | sponge $i
done
There are some actually wrong indentations too, I''ll fix those up
manually.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23944:4b0907c6a08c
user: Guido Gunther <agx@sigxcpu.org>
date: Tue Oct 11 12:02:58 2011 +0100
pygrub: add debug flag
Debugging config file errors is tedious so help a bit by not silently
dropping parsing exceptions when --debug is given. Also intialize the
logging API at debug level in this case.
Signed-off-by: Guido Gunther <agx@sigxcpu.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
=======================================commit
25378e0a76b282127e9ab8933a4defbc91db3862
Author: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu Oct 6 18:38:08 2011 +0100
remove blktap when building for NetBSD
NetBSD has no blktap support, so remove the use of the blktap if the
OS is NetBSD.
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jan Beulich
2011-Oct-14 07:10 UTC
Re: [Xen-devel] [xen-unstable test] 9292: regressions - FAIL
>>> On 14.10.11 at 06:11, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 9292 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9292/ > > Regressions :-( > > Tests which did not succeed and are blocking: > test-amd64-amd64-xl-sedf 16 guest-start.2 fail REGR. vs. 9252This particular test appears to be failing every now and then, hinting at some further bit rot problem in sedf. Therefore I wonder whether sedf needs some more serious looking at or whether we should simply drop it (and with it the test). Jan> Tests which did not succeed, but are not blocking, > including regressions (tests previously passed) regarded as allowable: > test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass > test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass > test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass > test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass > test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass > test-amd64-i386-win 16 leak-check/check fail never pass > test-amd64-amd64-win 16 leak-check/check fail never pass > test-amd64-amd64-xl-win 13 guest-stop fail never pass > test-i386-i386-xl-win 13 guest-stop fail never pass > test-i386-i386-win 16 leak-check/check fail never pass > > version targeted for testing: > xen a65693f9fb12 > baseline version: > xen 4b0907c6a08c_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Oct-14 15:56 UTC
Re: [Xen-devel] [xen-unstable test] 9292: regressions - FAIL
On Fri, Oct 14, 2011 at 8:10 AM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 14.10.11 at 06:11, xen.org <ian.jackson@eu.citrix.com> wrote: >> flight 9292 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/9292/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking: >> test-amd64-amd64-xl-sedf 16 guest-start.2 fail REGR. vs. 9252 > > This particular test appears to be failing every now and then, hinting at > some further bit rot problem in sedf. Therefore I wonder whether > sedf needs some more serious looking at or whether we should simply > drop it (and with it the test).We do still occasionally get people using sedf, reporting bugs, and so on. I get the feeling people would miss it when it''s gone. But then again, I''m not sure I''ll have the time to look at it any time soon... -George> > Jan > >> Tests which did not succeed, but are not blocking, >> including regressions (tests previously passed) regarded as allowable: >> test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass >> test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass >> test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass >> test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass >> test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass >> test-amd64-i386-win 16 leak-check/check fail never pass >> test-amd64-amd64-win 16 leak-check/check fail never pass >> test-amd64-amd64-xl-win 13 guest-stop fail never pass >> test-i386-i386-xl-win 13 guest-stop fail never pass >> test-i386-i386-win 16 leak-check/check fail never pass >> >> version targeted for testing: >> xen a65693f9fb12 >> baseline version: >> xen 4b0907c6a08c > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel