* [xen-unstable test] 17613: regressions - FAIL
@ 2013-04-10 23:41 xen.org
2013-04-11 7:54 ` Jan Beulich
0 siblings, 1 reply; 3+ messages in thread
From: xen.org @ 2013-04-10 23:41 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xen-unstable test] 17613: regressions - FAIL
2013-04-10 23:41 [xen-unstable test] 17613: regressions - FAIL xen.org
@ 2013-04-11 7:54 ` Jan Beulich
2013-04-11 8:03 ` Keir Fraser
0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2013-04-11 7:54 UTC (permalink / raw)
To: Stefano Stabellini, Keir Fraser; +Cc: xen-devel
>>> 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.
Stefano, Keir (21445:c1ed00d49534)?
Jan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xen-unstable test] 17613: regressions - FAIL
2013-04-11 7:54 ` Jan Beulich
@ 2013-04-11 8:03 ` Keir Fraser
0 siblings, 0 replies; 3+ messages in thread
From: Keir Fraser @ 2013-04-11 8:03 UTC (permalink / raw)
To: Jan Beulich, Stefano Stabellini; +Cc: xen-devel
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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-11 8:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-10 23:41 [xen-unstable test] 17613: regressions - FAIL xen.org
2013-04-11 7:54 ` Jan Beulich
2013-04-11 8:03 ` Keir Fraser
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.