flight 17327 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 17324
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-qemuu-win7-amd64 13 guest-stop 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-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen 2d8a2823f3d6d2e5fba832e0afe1fab8fbcb3694
baseline version:
xen f91c9f4254c926c92815da881fdff2a14ce72acf
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Wei Wang <wawei@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 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 pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair broken
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
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 2d8a2823f3d6d2e5fba832e0afe1fab8fbcb3694
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Mar 18 17:13:32 2013 +0100
x86/HPET: mask interrupt while changing affinity
While being unable to reproduce the "No irq handler for vector
..."
messages observed on other systems, the change done by 5dc3fd2
(''x86:
extend diagnostics for "No irq handler for vector"
messages'') appears
to point at the lack of masking - at least I can''t see what else
might
be wrong with the HPET MSI code that could trigger these warnings.
While at it, also adjust the message printed by aforementioned commit
to not pointlessly insert spaces - we don''t need aligned tabular
output
here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
commit e9f3de0b9c06cc8449be04f655b2dd0e71420e17
Author: Wei Wang <wawei@amazon.com>
Date: Mon Mar 18 11:57:54 2013 +0100
MAINTAINERS: Remove myself from AMD IOMMU maintainer
Signed-off-by: Wei Wang <wawei@amazon.com>
(qemu changes not included)
Jan Beulich
2013-Mar-19 09:55 UTC
Re: [xen-unstable test] 17327: trouble: broken/fail/pass
>>> On 19.03.13 at 03:36, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 17327 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/Ian, looking through the logs of this run for the effect of 2d8a282, I''m having trouble identifying the code bases for the individual builds. In particular, there is (XEN) Xen version 4.3-unstable (osstest@cam.xci-test.com) (gcc (Debian 4.4.5-8) 4.4.5) debug=y Mon Mar 18 21:51:30 GMT 2013 still showing the "No irq handler for vector ..." messages, but four later runs of the apparently earlier build (XEN) Xen version 4.3-unstable (osstest@cam.xci-test.com) (gcc (Debian 4.4.5-8) 4.4.5) debug=y Mon Mar 18 21:08:37 GMT 2013 have not a single instance of those messages. Hence I would guess that the earlier runs of the later builds somehow used a tree at e9f3de0 (or earlier), but with (XEN) Latest ChangeSet: unavailable I don''t see how I could prove that. Is there any other way to associate the log of a particular run with the top level commit of the originating source tree? Jan
Ian Jackson
2013-Mar-25 12:44 UTC
Re: [xen-unstable test] 17327: trouble: broken/fail/pass
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 17327: trouble:
broken/fail/pass"):> >>> On 19.03.13 at 03:36, xen.org
<ian.jackson@eu.citrix.com> wrote:
> > flight 17327 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/
...> I don''t see how I could prove that. Is there any other way to
> associate the log of a particular run with the top level commit of
> the originating source tree?
If you look at one of the build-* columns (click on the column
heading) you see a table of "Test control variables". Here, for
example:
http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/build-amd64/info.html
There you can see the revisions of the various trees used. It also
does a check afterwards (using "git-rev-parse HEAD", for example) and
records the result as built_revision_...
So did indeed use xen.git 2d8a2823f3d6d2e5fba832e0afe1fab8fbcb3694.
(Bisection jobs may reuse other builds so you may need to check the
test column variables for the "xenbuildjob" etc. variables.)
Ian.
Jan Beulich
2013-Mar-25 13:01 UTC
Re: [xen-unstable test] 17327: trouble: broken/fail/pass
>>> On 25.03.13 at 13:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 17327: trouble: > broken/fail/pass"): >> >>> On 19.03.13 at 03:36, xen.org <ian.jackson@eu.citrix.com> wrote: >> > flight 17327 xen-unstable real [real] >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/ > ... >> I don''t see how I could prove that. Is there any other way to >> associate the log of a particular run with the top level commit of >> the originating source tree? > > If you look at one of the build-* columns (click on the column > heading) you see a table of "Test control variables". Here, for > example: > > http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/build-amd64/info.html > > There you can see the revisions of the various trees used. It also > does a check afterwards (using "git-rev-parse HEAD", for example) and > records the result as built_revision_...Not exactly, I''m afraid - what a particular test job uses apparently isn''t tied to just a single build, or else I don''t understand how an older build''s output could turn out to be visible in the serial log. And it''s those older builds that leave traces in the serial log that I''ve been looking at here (in particular to spot whether the "No irq handler for vector ..." and the platform timer wrapped messages still appear after the two HPET related changes). Furthermore, those test results, iirc, get purged from the server after a while, so if I store local copies of some of the logs and fail to note down the underlying commit ID(s), then I won''t be able to associate the logs back. With hg, the information was readily available at the top of the hypervisor log, and I think we really ought to bring this back for git. Jan