flight 13383 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379
Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13376
Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
version targeted for testing:
 xen                  52f1b8a4f9a4
baseline version:
 xen                  4f92bdf3370c
------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
 build-amd64                                                  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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           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                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-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.
------------------------------------------------------------
changeset:   25521:52f1b8a4f9a4
tag:         tip
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Jun 27 17:50:10 2012 +0100
    
    xen,pod: Cosmetic code motion
    
    No point in doing the assignment if we''re just going to crash
anyway.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    
    
changeset:   25520:2d9f3b010901
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jun 28 12:45:09 2012 +0100
    
    x86/mm: Clean up unshare path for foreign mappings
    
    In its current shape, if Xen unshares a foreign gfn successfully while
building
    a foreign writable map, it is left with a reference to the old shared page
in
    the "target" var.
    
    Instead, push unsharing request down on the initial get_page_from_gfn call,
    which will DTRT.
    
    This allows for greatly simplifying the unshare related condition handling,
    removing ugly comments and s86_64 ifdef-ery.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   25519:fdc1f16d382c
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jun 28 13:36:08 2012 +0200
    
    x86/hvm: increase struct hvm_vcpu_io''s mmio_large_read[]
    
    Since the emulator now supports a few 256-bit memory operations, this
    array needs to follow (and the comments should, too).
    
    To limit growth, re-order the mmio_large_write_* fields so that the
    two mmio_large_*_bytes fields end up adjacent to each other.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25518:4f92bdf3370c
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Jun 27 09:36:43 2012 +0200
    
    docs/xen-headers: allow headers to be symlinks
    
    There''s no apparent reason not to permit this, and since we
don''t
    support out-of-source-tree builds, the least overhead way of doing
    multiple, differently configured (perhaps different architecture)
    builds from a single source tree is to create symlinked build trees.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
=======================================commit
50c553be472c9f4b05a0526c0aae98709ca9ffff
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Jun 7 19:44:01 2012 +0100
    qemu-xen-trad: fix sys-queue.h usage on BSD systems
    
    BSD systems already have a sys/queue.h file, which has more macros
    than the one Qemu uses, and some header files depend on having that
    macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
    systems and include the native one.
    
    This is not a backport because the original patch is too dificult to
    backport, it''s commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
    
    Doing a diff -bB shows that the Qemu version is just a stripped
    version of the original NetBSD header, with many macros removed, but
    no new ones added.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:> flight 13383 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-pair 16 guest-start fail REGR. vs. 13379This run was before the migration series went in. I don''t see much of interest in the logs, seems like the guest did actually start. The new commits which went into this flight seem fairly benign, at least from the PoV of starting a PV guest: [...]> changeset: 25521:52f1b8a4f9a4 > tag: tip > user: George Dunlap <george.dunlap@eu.citrix.com> > date: Wed Jun 27 17:50:10 2012 +0100 > > xen,pod: Cosmetic code motion > > No point in doing the assignment if we''re just going to crash anyway. > > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> > > > changeset: 25520:2d9f3b010901 > user: Andres Lagar-Cavilla <andres@lagarcavilla.org> > date: Thu Jun 28 12:45:09 2012 +0100 > > x86/mm: Clean up unshare path for foreign mappings > > In its current shape, if Xen unshares a foreign gfn successfully while building > a foreign writable map, it is left with a reference to the old shared page in > the "target" var. > > Instead, push unsharing request down on the initial get_page_from_gfn call, > which will DTRT. > > This allows for greatly simplifying the unshare related condition handling, > removing ugly comments and s86_64 ifdef-ery. > > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> > Acked-by: Tim Deegan <tim@xen.org> > Committed-by: Tim Deegan <tim@xen.org> > > > changeset: 25519:fdc1f16d382c > user: Jan Beulich <jbeulich@suse.com> > date: Thu Jun 28 13:36:08 2012 +0200 > > x86/hvm: increase struct hvm_vcpu_io''s mmio_large_read[] > > Since the emulator now supports a few 256-bit memory operations, this > array needs to follow (and the comments should, too). > > To limit growth, re-order the mmio_large_write_* fields so that the > two mmio_large_*_bytes fields end up adjacent to each other. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Keir Fraser <keir@xen.org> > > > changeset: 25518:4f92bdf3370c > user: Jan Beulich <jbeulich@suse.com> > date: Wed Jun 27 09:36:43 2012 +0200 > > docs/xen-headers: allow headers to be symlinks > > There''s no apparent reason not to permit this, and since we don''t > support out-of-source-tree builds, the least overhead way of doing > multiple, differently configured (perhaps different architecture) > builds from a single source tree is to create symlinked build trees. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > > =======================================> commit 50c553be472c9f4b05a0526c0aae98709ca9ffff > Author: Roger Pau Monne <roger.pau@citrix.com> > Date: Thu Jun 7 19:44:01 2012 +0100 > > qemu-xen-trad: fix sys-queue.h usage on BSD systems > > BSD systems already have a sys/queue.h file, which has more macros > than the one Qemu uses, and some header files depend on having that > macros defined (sys/disk.h for example). Disable sys-queue.h on BSD > systems and include the native one. > > This is not a backport because the original patch is too dificult to > backport, it''s commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e. > > Doing a diff -bB shows that the Qemu version is just a stripped > version of the original NetBSD header, with many macros removed, but > no new ones added. > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Fri, 2012-06-29 at 07:56 +0100, Ian Campbell wrote:> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote: > > flight 13383 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-pair 16 guest-start fail REGR. vs. 13379 > > This run was before the migration series went in. > > I don''t see much of interest in the logs, seems like the guest did > actually start.http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/16.ts-guest-start.log has: 2012-06-28 15:21:47 Z executing ssh ... root@10.80.249.56 xm list 2012-06-28 15:21:48 Z guest debian.guest.osstest state is r 2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: waiting 40s... 2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: no active lease (waiting) ... 2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of data. | | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0 received, 100% packet loss, time XXXms | | (waiting) ... ... but http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease contains: lease 10.80.251.54 { starts 3 2012/06/27 14:10:01; ends 3 2012/06/27 14:40:01; tstp 3 2012/06/27 14:40:01; cltt 3 2012/06/27 14:10:01; binding state free; hardware ethernet 00:00:1a:1b:01:a1; uid "\001\000\000\032\033\001\241"; } Which has a mismatched mac address? dhcpleases-debian.new seems to have the same.> The new commits which went into this flight seem fairly benign, at least > from the PoV of starting a PV guest: > > [...] > > changeset: 25521:52f1b8a4f9a4 > > tag: tip > > user: George Dunlap <george.dunlap@eu.citrix.com> > > date: Wed Jun 27 17:50:10 2012 +0100 > > > > xen,pod: Cosmetic code motion > > > > No point in doing the assignment if we''re just going to crash anyway. > > > > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> > > > > > > changeset: 25520:2d9f3b010901 > > user: Andres Lagar-Cavilla <andres@lagarcavilla.org> > > date: Thu Jun 28 12:45:09 2012 +0100 > > > > x86/mm: Clean up unshare path for foreign mappings > > > > In its current shape, if Xen unshares a foreign gfn successfully while building > > a foreign writable map, it is left with a reference to the old shared page in > > the "target" var. > > > > Instead, push unsharing request down on the initial get_page_from_gfn call, > > which will DTRT. > > > > This allows for greatly simplifying the unshare related condition handling, > > removing ugly comments and s86_64 ifdef-ery. > > > > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> > > Acked-by: Tim Deegan <tim@xen.org> > > Committed-by: Tim Deegan <tim@xen.org> > > > > > > changeset: 25519:fdc1f16d382c > > user: Jan Beulich <jbeulich@suse.com> > > date: Thu Jun 28 13:36:08 2012 +0200 > > > > x86/hvm: increase struct hvm_vcpu_io''s mmio_large_read[] > > > > Since the emulator now supports a few 256-bit memory operations, this > > array needs to follow (and the comments should, too). > > > > To limit growth, re-order the mmio_large_write_* fields so that the > > two mmio_large_*_bytes fields end up adjacent to each other. > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Acked-by: Keir Fraser <keir@xen.org> > > > > > > changeset: 25518:4f92bdf3370c > > user: Jan Beulich <jbeulich@suse.com> > > date: Wed Jun 27 09:36:43 2012 +0200 > > > > docs/xen-headers: allow headers to be symlinks > > > > There''s no apparent reason not to permit this, and since we don''t > > support out-of-source-tree builds, the least overhead way of doing > > multiple, differently configured (perhaps different architecture) > > builds from a single source tree is to create symlinked build trees. > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Acked-by: Ian Campbell <ian.campbell@citrix.com> > > > > > > =======================================> > commit 50c553be472c9f4b05a0526c0aae98709ca9ffff > > Author: Roger Pau Monne <roger.pau@citrix.com> > > Date: Thu Jun 7 19:44:01 2012 +0100 > > > > qemu-xen-trad: fix sys-queue.h usage on BSD systems > > > > BSD systems already have a sys/queue.h file, which has more macros > > than the one Qemu uses, and some header files depend on having that > > macros defined (sys/disk.h for example). Disable sys-queue.h on BSD > > systems and include the native one. > > > > This is not a backport because the original patch is too dificult to > > backport, it''s commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e. > > > > Doing a diff -bB shows that the Qemu version is just a stripped > > version of the original NetBSD header, with many macros removed, but > > no new ones added. > > > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com> > > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13383:
regressions - FAIL"):> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
...> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair         16 guest-start               fail REGR.
vs. 13379
> 
> This run was before the migration series went in.
This is a rather worrying probably-nondeterministic failure, since the
same kind of guest is started in the same way in other
non-(non-localhost-migration) tests.  It''s an ordinary Debian PV
guest.  I''ll go and look at the logs and see if I see anything.
Ian.
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13383:
regressions - FAIL"):>
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease
contains:
>         lease 10.80.251.54 {
>           starts 3 2012/06/27 14:10:01;
>           ends 3 2012/06/27 14:40:01;
>           tstp 3 2012/06/27 14:40:01;
>           cltt 3 2012/06/27 14:10:01;
>           binding state free;
>           hardware ethernet 00:00:1a:1b:01:a1;
>           uid "\001\000\000\032\033\001\241";
>         }
> 
> Which has a mismatched mac address? dhcpleases-debian.new seems to have
> the same.
Note "binding state free".  Ie that''s an old lease.  Later we
see:
          lease 10.80.251.54 {
            starts 4 2012/06/28 15:21:52;
            ends 4 2012/06/28 15:51:52;
            cltt 4 2012/06/28 15:21:52;
            binding state active;
            next binding state free;
            hardware ethernet 5a:36:0e:47:00:09;
          }
The guest console log says:
    Listening on LPF/eth0/5a:36:0e:47:00:09
    Sending on   LPF/eth0/5a:36:0e:47:00:09
    Sending on   Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    DHCPOFFER from 10.80.248.4
    DHCPREQUEST on eth0 to 255.255.255.255 port 67
    DHCPACK from 10.80.248.4
    bound to 10.80.251.54 -- renewal in 854 seconds.
    done.
So that all does seem consistent.
But even so:
    2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22
link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of
data. |  | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0
received, 100% packet loss, time XXXms |  |  (waiting) ...
The same happens at at least 15:22:34 and perhaps a few times in
between.
It would seem that either something broke in the guest or host between
the successful dhcp negotiation, or there was a transient network
problem of some kind.
Ian.