[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-unstable test] 34484: regressions - FAIL



flight 34484 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34484/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt     13 guest-destroy             fail REGR. vs. 34341

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 34341

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-sedf     10 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-midway   10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 10 migrate-support-check        fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt     10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-armhf-armhf-xl-credit2  10 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  d40cbb98a3eb447b8055ec4e70e93a6f22850ac5
baseline version:
 xen                  001324547356af86875fad5003f679571a6b8f1c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 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-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           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-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      pass    
 test-armhf-armhf-xl-midway                                   pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-armhf-armhf-xl-sedf-pin                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-armhf-armhf-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.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 d40cbb98a3eb447b8055ec4e70e93a6f22850ac5
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 10 13:32:03 2015 +0100

    x86: re-order struct arch_domain fields
    
    ... to reduce padding holes.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit afb2f2ffb72e38268bdd0c26ce7f3df90eea76bb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 10 13:31:16 2015 +0100

    x86/HVM: also separate kernel/user vTSC statistics
    
    It is unclear why this got done for PV only originally.
    
    While at it, limit this statistics collection to debug or performance
    counter enabled builds.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 70f691130081324a8efb97b23c504d8abc5421db
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Tue Feb 10 13:29:51 2015 +0100

    x86/hvm: explicitly mark ioreq server pages dirty
    
    ...when they are added back into the guest physmap, when an ioreq
    server is disabled. If this is not done then the pages are missed
    during migration, causing ioreq server creation to fail on the remote end.
    
    This problem only manifests if the ioreq server is non-default because in
    the default case the pages are never removed from the guest physmap.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

commit dd748d128d86996592afafea02e578cc7d4e6d42
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Tue Feb 10 13:28:40 2015 +0100

    x86/hvm: wait for at least one ioreq server to be enabled
    
    In the case where a stub domain is providing emulation for an HVM
    guest, there is no interlock in the toolstack to make sure that
    the stub domain is up and running before the guest is unpaused.
    
    Prior to the introduction of ioreq servers this was not a problem,
    since there was only ever one emulator so ioreqs were simply
    created anyway and the vcpu remained blocked until the stub domain
    started and picked up the ioreq.
    
    Since ioreq servers allow for multiple emulators for a single guest
    it's not possible to know a priori which emulator will handle a
    particular ioreq, so emulators must attach to a guest before the
    guest runs.
    
    This patch works around the lack of interlock in the toolstack for
    stub domains by keeping the domain paused until at least one ioreq
    server is created and enabled, which in practice means the stub
    domain is indeed up and running.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

commit 8bc64413be51c91b8f5e790b71e0d94727f9f004
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 9 15:34:40 2015 +0000

    libxl: More probably detect reentry of destroyed ctx
    
    In libxl_ctx_free:
    
    1. Move the GC_INIT earlier, so that we can:
    
    2. Take the lock around most of the work.  This is technically
       unnecessary since calling any other libxl entrypoint on a ctx being
       passed to libxl_ctx_free risks undefined behaviour.  But, taking
       the lock allows us to much more usually spot this.
    
    3. Increment osevent_in_hook by 1000.  If we are reentered after
       destroy, this will trip some of our entrypoints' asserts.  It also
       means that if we crash for some other reason relating to reentering
       a destroyed ctx, the cause will be more obviously visible by
       examining ctx->osevent_in_hook (assuming that the memory previously
       used for the ctx hasn't been reused and overwritten).
    
    4. Free the lock again.  (pthread_mutex_destroy requires that the
       mutex be unlocked.)
    
    With this patch, I find that an occasional race previously reported
    as:
      libvirtd: libxl_internal.h:3265: libxl__ctx_unlock: Assertion `!r' failed.
    is now reported as:
      libvirtd: libxl_event.c:1236: libxl_osevent_occurred_fd: Assertion 
`!libxl__gc_owner(gc)->osevent_in_hook' failed.
    
    Examining the call trace with gdb shows this:
      (gdb) bt
      #0  0xb773f424 in __kernel_vsyscall ()
      #1  0xb7022871 in raise () from 
/lib/i386-linux-gnu/i686/nosegneg/libc.so.6
      #2  0xb7025d62 in abort () from 
/lib/i386-linux-gnu/i686/nosegneg/libc.so.6
      #3  0xb701b958 in __assert_fail () from 
/lib/i386-linux-gnu/i686/nosegneg/libc.so.6
      #4  0xb6f00390 in libxl_osevent_occurred_fd (ctx=0xb84813a8, 
for_libxl=0xb84d6848, fd=31, events_ign=0, revents_ign=1) at libxl_event.c:1236
      #5  0xb1b70464 in libxlDomainObjFDEventCallback () from 
/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so
      #6  0xb72163b1 in virEventPollDispatchHandles () from 
/usr/local/lib/libvirt.so.0
      #7  0xb7216be5 in virEventPollRunOnce () from /usr/local/lib/libvirt.so.0
      #8  0xb7214a7e in virEventRunDefaultImpl () from 
/usr/local/lib/libvirt.so.0
      #9  0xb77c7b98 in virNetServerRun ()
      #10 0xb7771c63 in main ()
      (gdb) print ctx->osevent_in_hook
      $2 = 1000
      (gdb)
    which IMO demonstrates that libxl_osevent_occurred_fd is being called
    on a destroyed ctx.
    
    This is probably a symptom of the bug in libvirt fixed by these
    patches:
       https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
    CC: Wei Liu <wei.liu2@xxxxxxxxxx>
    CC: Jim Fehlig <jfehlig@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit f1335f0d7b2402e94e0c6e8a905dc309edaafcfb
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 9 15:20:32 2015 +0000

    libxl: event handling: ao_inprogress does waits while reports outstanding
    
    libxl__ao_inprogress needs to check (like
    libxl__ao_complete_check_progress_reports) that there are no
    oustanding progress callbacks.
    
    Otherwise it might happen that we would destroy the ao while another
    thread has an outstanding callback its egc report queue.  The other
    thread would then, in its egc_run_callbacks, touch the destroyed ao.
    
    Instead, when this happens in libxl__ao_inprogress, simply run round
    the event loop again.  The thread which eventually makes the callback
    will spot our poller in the ao, and notify the poller, waking us up.
    
    This fixes an assertion failure race seen with libvirt:
      libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: 
Assertion `ao->in_initiator' failed.
    or (after "Add an assert to egc_run_callbacks")
      libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion 
`aop->ao->magic == 0xA0FACE00ul' failed.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
    CC: Wei Liu <wei.liu2@xxxxxxxxxx>
    CC: Jim Fehlig <jfehlig@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 93699882d98cce9736d6e871db303275df1138a2
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 9 15:18:30 2015 +0000

    libxl: event handling: Break out ao_work_outstanding
    
    Break out the test in libxl__ao_complete_check_progress_reports, into
    ao_work_outstanding, which reports false if either (i) the ao is still
    ongoing or (ii) there is a progress report (perhaps on a different
    thread's callback queue) which has yet to be reported to the
    application.
    
    No functional change.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
    CC: Wei Liu <wei.liu2@xxxxxxxxxx>
    CC: Jim Fehlig <jfehlig@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 6b5a5bba1a8025040947f39f1c80012373f35efe
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 9 15:10:11 2015 +0000

    libxl: event handling: Add an assert to egc_run_callbacks
    
    Check that the ao is still live when we are about to running some of
    its callbacks.
    
    This reveals an existing bug in libxl which is exercised by libvirt,
    converting
       libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: 
Assertion `ao->in_initiator' failed.
    into
       libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion 
`aop->ao->magic == 0xA0FACE00ul' failed.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
    CC: Wei Liu <wei.liu2@xxxxxxxxxx>
    CC: Jim Fehlig <jfehlig@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.