flight 16774 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-oldkern 4 xen-build fail REGR. vs. 15122
test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 15122
Tests which did not succeed, but are not blocking:
build-armhf 4 xen-build fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win 13 guest-stop fail never pass
test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check fail never pass
test-i386-i386-qemuu-win 16 leak-check/check fail never pass
test-amd64-i386-qemuu-win 16 leak-check/check fail never pass
test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop fail never pass
test-i386-i386-xl-qemuu-win 12 guest-localmigrate/x10 fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-qemuu-win 16 leak-check/check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
qemuu eccc68722696864fc4823f048c7be58d11281b97
baseline version:
qemuu 70454385eeee6f0b3f7a9eddca9f7340b5060824
------------------------------------------------------------
People who touched revisions under test:
Alex Bligh <alex@alex.org.uk>
Anthony PERARD <anthony.perard@citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf fail
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern fail
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-qemuu-win-vcpus1 fail
test-amd64-i386-xl-qemuu-win-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-amd64-qemuu-win fail
test-amd64-i386-qemuu-win fail
test-i386-i386-qemuu-win fail
test-amd64-amd64-xl-qemuu-win fail
test-i386-i386-xl-qemuu-win fail
test-amd64-i386-xend-qemuu-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-i386-i386-xl-qemuu-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 eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu Feb 21 12:16:42 2013 +0000
xen: Set the vram dirty when an error occurs.
If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all
the
video ram. This case happens during migration.
Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
This backport is less clean that it might be because there is no
memory_region_set_dirty that copes with more than one page in 4.2,
and the case where the call to xc_hvm_track_dirty_vram is
successful also needs to ensure xen_modified_memory is
called (which would on unstable have been done within
memory_region_set_dirty).
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Jan Beulich
2013-Mar-01 09:47 UTC
Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL
>>> On 01.03.13 at 00:02, xen.org <ian.jackson@eu.citrix.com> wrote: > test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 15122So this has now been failing for almost a week, and I don''t think I''ve seen anything being done about it. With 4.2.2-rc1 planned for (hopefully) early next week, may I ask that the patch set causing the regression be either reverted or fixed soonish? What strikes me odd looking at the logs is that vCPU1 of the guest is still in real mode, i.e. the guest either has a problem bringing up its second CPU or dies very early. I didn''t look at the patches in any detail, but the sort of problem (reproducible and apparently ending in a consistently bad state) doesn''t look that hard to analyze... Thanks, Jan
Ian Jackson
2013-Mar-01 12:02 UTC
Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL
Jan Beulich writes ("Re: [Xen-devel] [qemu-upstream-4.2-testing test]
16774: regressions - FAIL"):> >>> On 01.03.13 at 00:02, xen.org
<ian.jackson@eu.citrix.com> wrote:
> > test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR.
vs. 15122
>
> So this has now been failing for almost a week, and I don''t think
> I''ve seen anything being done about it. With 4.2.2-rc1 planned
> for (hopefully) early next week, may I ask that the patch set
> causing the regression be either reverted or fixed soonish?
I think as the person in charge of the stable trees that is your
decision to make. But I agree that it should be reverted. Do you
know exactly which commits are involved ?
Ian.
Jan Beulich
2013-Mar-01 12:11 UTC
Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL
>>> On 01.03.13 at 13:02, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] [qemu-upstream-4.2-testing test] 16774: > regressions - FAIL"): >> >>> On 01.03.13 at 00:02, xen.org <ian.jackson@eu.citrix.com> wrote: >> > test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 15122 >> >> So this has now been failing for almost a week, and I don''t think >> I''ve seen anything being done about it. With 4.2.2-rc1 planned >> for (hopefully) early next week, may I ask that the patch set >> causing the regression be either reverted or fixed soonish? > > I think as the person in charge of the stable trees that is your > decision to make. But I agree that it should be reverted. Do you > know exactly which commits are involved ?There was a batch of 6 patches committed about a week ago. Which of them is causing the problem I don''t know (and don''t care much, as I believe the patch set is of use only if all of them are there). As to reverting or fixing - I wanted to give Stefano and Anthony a chance to fix if that''s doable, and fall back to reverting otherwise. But of course that first of all requires that at least one of them responds... And then I wouldn''t want to be messing with the qemu tree when Stefano is in charge of it, so I would still expect him to do the revert if needed. Jan
Ian Jackson
2013-Mar-01 12:16 UTC
Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL
Jan Beulich writes ("Re: [Xen-devel] [qemu-upstream-4.2-testing test]
16774: regressions - FAIL"):> There was a batch of 6 patches committed about a week ago.
> Which of them is causing the problem I don''t know (and
don''t
> care much, as I believe the patch set is of use only if all of them
> are there).
>
> As to reverting or fixing - I wanted to give Stefano and Anthony
> a chance to fix if that''s doable, and fall back to reverting
> otherwise. But of course that first of all requires that at least
> one of them responds...
I think we should time out now. The correct approach is that if
problems are not fixed quickly, the problematic changesets should be
reverted.
> And then I wouldn''t want to be messing with the qemu tree when
> Stefano is in charge of it, so I would still expect him to do the
> revert if needed.
We can revert the change to QEMU_UPSTREAM_REVISION in xen.git,
effectively rewinding to a previous revision, without disturbing
Stefano''s work.
Ian.
Jan Beulich
2013-Mar-01 12:32 UTC
Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL
>>> On 01.03.13 at 13:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] [qemu-upstream-4.2-testing test] 16774: > regressions - FAIL"): >> And then I wouldn''t want to be messing with the qemu tree when >> Stefano is in charge of it, so I would still expect him to do the >> revert if needed. > > We can revert the change to QEMU_UPSTREAM_REVISION in xen.git, > effectively rewinding to a previous revision, without disturbing > Stefano''s work.But wouldn''t that merely fix tests run on the main tree (and there, for whatever reason, the change actually got pushed), keeping the qemu-upstream-4.2-testing ones to fail? Plus, the QEMU_UPSTREAM_REVISION revision change having got pushed could indicate that the problem is a different one, not related to those changes? I guess I''ll give Stefano/Anthony a little more time before trying the revert (and if the revert doesn''t fix the failure, then we know we need to look elsewhere). Jan