flight 17613 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/17613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 9 guest-start.2 fail REGR. vs. 17610
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 13 guest-localmigrate.2 fail REGR. vs. 17610
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail REGR. vs. 17610
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
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-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-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 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-qemuu-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen d739470b9431406eb34a14a8feb9fa4a71330b5a
baseline version:
xen bd9be94eb2280e8e662e75f1e5fea7c12eb2589c
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.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 pass
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 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv pass
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 fail
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 d739470b9431406eb34a14a8feb9fa4a71330b5a
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Apr 10 18:27:32 2013 +0200
x86: show handler for Xen-internal interrupts
... in ''i'' debug key output.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
commit fe017c59c4c3ce189119954841a38ef0f1e415d0
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Apr 10 17:30:19 2013 +0200
x86/MSI: cleanup to prepare for multi-vector MSI
The major aspect being the removal of the overload of the MSI
entry''s
mask_base field for MSI purposes - a proper union is being installed
instead, tracking both the config space position needed and the number
of vectors used (which is going to be 1 until the actual multi-vector
MSI patches arrive).
It also corrects misleading information from debug key
''M'': When
msi_get_mask_bit() returns a negative value, there''s no mask bit,
and
hence output shouldn''t give the impression there is.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
commit 94d166c0106f158fa2c86496bfb0ca1fbb8627ec
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed Feb 20 18:16:37 2013 +0000
xen/arm: phys_timer fixes
Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.
Do not let the user set CNTx_CTL_PENDING directly.
Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.
Define offset and cval as uint64_t given that they can''t be
negative and
they are used as uint64_t arguments.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit c96513ff9d564b019ab8849d5bd8c4c81b19e871
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon Feb 18 16:02:29 2013 +0000
xen/arm: don''t set the internal Xen timer if virt_timer is masked
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 0648a3437e9adc2f297f16286b1d58d598c0b865
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon Feb 18 16:02:28 2013 +0000
xen/arm: dump gic debug info from arch_dump_domain_info
Print some useful GIC debug information when arch_dump_domain_info is
called (''q'' debug key).
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)
>>> On 11.04.13 at 01:41, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 17613 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/17613/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-qemut-rhel6hvm-intel 9 guest-start.2 fail REGR. vs. 17610So this is one of the BUG_ON()s added by bd9be94 triggering, and this is not a false positive. scale_delta() is simply not suitable for negative inputs, and the main question is why gtime_to_gtsc() caps its input to 0 only for PV domains, or whether (considering that this parameter is u64) __update_vcpu_system_time() should already cap it to zero. Not to speak of the question how the calculation there could end up negative in the first place. Stefano, Keir (21445:c1ed00d49534)? Jan
On 11/04/2013 08:54, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 11.04.13 at 01:41, xen.org <ian.jackson@eu.citrix.com> wrote: >> flight 17613 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/17613/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-i386-qemut-rhel6hvm-intel 9 guest-start.2 fail REGR. vs. >> 17610 > > So this is one of the BUG_ON()s added by bd9be94 triggering, > and this is not a false positive. scale_delta() is simply not suitable > for negative inputs, and the main question is why gtime_to_gtsc() > caps its input to 0 only for PV domains, or whether (considering > that this parameter is u64) __update_vcpu_system_time() should > already cap it to zero. Not to speak of the question how the > calculation there could end up negative in the first place.Yes, I think it should be capped where guest time gets set/updated. The time input to gtime_to_gtsc() should always be non-negative. -- Keir> Stefano, Keir (21445:c1ed00d49534)? > > Jan >