[qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[xen.org]

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>

Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[Jan Beulich]

>>> 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?

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

Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[Ian Jackson]

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.

Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[Jan Beulich]

>>> 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

Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[Ian Jackson]

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.

Re: [qemu-upstream-4.2-testing test] 16774: regressions - FAIL

[Jan Beulich]

>>> 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