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

[Xen-devel] [xen-4.4-testing test] 28810: regressions - trouble: broken/fail/pass



flight 28810 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/28810/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 27490
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 27490
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 27490
 test-amd64-i386-freebsd10-amd64  3 host-install(3)      broken REGR. vs. 27490
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 27490
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 27490
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 27490
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 27490
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 27490
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 27490
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate.2 fail REGR. vs. 
27490
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 27490
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
27490
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 27490
 test-armhf-armhf-libvirt      3 host-install(3)         broken REGR. vs. 27490
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)  broken REGR. vs. 27490
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 27490

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 27490
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 27490
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 27490

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ee81dda7c3767bd9af7ae84a86d1be56d8fad343
baseline version:
 xen                  7aedb244ed6ca3180849fe4a04136a2b10151327

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Julien Grall <julien.grall@xxxxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           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                                           broken  
 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                    broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 test-amd64-amd64-rumpuserxen-amd64                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         broken  
 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                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 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-i386-xend-qemut-winxpsp3                          broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 ee81dda7c3767bd9af7ae84a86d1be56d8fad343
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Thu Jul 3 13:58:23 2014 +0100

    QEMU_TAG update - FIX!
    
    My qemu push and tag update script had transposed a revision number
    from qemu-xen-4.3-testing into xen-4.4-testing's Config.mk!
    
    The script is now fixed, but we also need to fix the tree.
    
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

commit 9fc0c44a691c5166908cf1015c4a73d65c711d04
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Wed Jul 2 16:06:31 2014 +0100

    QEMU_TAG update

commit 34a314265f43113fc3e7f68ca04370541ea1e7c5
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu May 22 10:46:37 2014 +0100

    tools: arm: report an error if the guest RAM is too large
    
    Due to the layout of the guest physical address space we cannot support more
    than 768M of RAM before overrunning the area set aside for the grant table. 
Due
    to the presence of the magic pages at the end of the RAM region guests are
    actually limited to 767M.
    
    Catch this case during domain build and fail gracefully instead of obscurely
    later on.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 5a959f44ed03398870b6ec0dfebb59dcd5981f94)

commit d40bed867d9550afe3d6e7c369647905109ce831
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jun 18 19:04:14 2014 +0100

    tools/libxl: Fix free() of wild pointer in libxl__initiate_device_remove()
    
    libxl__initiate_device_remove() had a preexisting error path issue where
    libxl_dominfo_dispose() could be called on a libxl_dominfo object before it
    had been initialised with libxl_dominfo_init().
    
    This was safe until c/s ab44401 added the pointer ssid_label, which point
    libxl_dominfo_dispose() free()s.
    
    Unconditionally initialise info in libxl__initiate_device_remove() before
    taking an error path which will free it.
    
    Coverity-ID: 1223212
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    CC: Wei Liu <wei.liu2@xxxxxxxxxx>
    CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    (cherry picked from commit ddb4aa5dfa13781e8f31ba20923c14c1a083ce83)

commit 5e39eb05aa2a6d9bfa6c3b3e299b071422498625
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Fri Jun 20 16:09:00 2014 +0200

    blktap2: Fix two 'maybe uninitialized' variables
    
    for which gcc 4.9.0 complains about, like this:
    
    block-qcow.c: In function `get_cluster_offset':
    block-qcow.c:431:3: error: `tmp_ptr' may be used uninitialized in this 
function
    [-Werror=maybe-uninitialized]
       memcpy(tmp_ptr, l1_ptr, 4096);
       ^
    block-qcow.c:606:7: error: `tmp_ptr2' may be used uninitialized in this
    function [-Werror=maybe-uninitialized]
       if (write(s->fd, tmp_ptr2, 4096) != 4096) {
           ^
    cc1: all warnings being treated as errors
    
/home/dario/Sources/xen/xen/xen.git/tools/blktap2/drivers/../../../tools/Rules.mk:89:
     recipe for target 'block-qcow.o' failed
    make[5]: *** [block-qcow.o] Error 1
    
    The proper behavior is to return upon allocation failure.
    About what to return, 0 seems the best option, looking
    at both the function and the call sites.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 345e44a85d71a1a910385f33c7f1ba3683026d18)

commit d774a33b72b933ef425f52cb771dee60e809201e
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Jun 26 17:30:14 2014 +0100

    xen: arm: make sure gcc doesn't use floating-point registers on arm64
    
    By using -mgeneral-regs-only which is the Aarch64 equivalent to
    -msoft-float.
    
    Otherwise gcc will corrupt the d* registers, which we don't save/restore 
when
    trapping to/from the hypervisor.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    (cherry picked from commit c0726c18e8135f87a5a5793d993d6bea1e3fa925)

commit c2800a8f93c828671ee4b2517accea8c546eb883
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Fri Jun 13 13:15:04 2014 +0100

    xen: arm: Implement OSDLR_EL1 trap as RAZ/WO.
    
    I'm not sure why this wasn't added at the same time as the other
    debug registers.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    (cherry picked from commit 92b0b80f0d2d29d0e80bf35ea839ed6058b7f0fa)

commit 652fb44ffbc5f3ff576b6d2349a49910170e7d2b
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Jun 26 09:53:42 2014 +0100

    xen: arm: take FIQ exceptions to Xen not guest by setting HCR_EL2.FMO
    
    As with HCR_EL2.{IMO,AMO} we want to route FIQs to Xen not the guest. See 
ARM
    ARM DDI 0406C.b B1.8.4.
    
    So far none of the platforms which we support use FIQ for anything, but 
when we
    end up supporting one it would be far better to surprise Xen with them than
    whatever guest happens to be running...
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    (cherry picked from commit 4bb74e39987b428429c2aacad7f59356d4942e39)
    
    Conflicts:
        xen/arch/arm/traps.c

commit 3ca5033563bd736f5d153a59fae7c02ec3a5abce
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Thu Apr 24 23:45:55 2014 +0100

    xen/arm: Implement a dummy debug monitor for ARM32
    
    XSA-93 (commit 0b18220 "xen/arm: Don't let guess access to Debug and 
Performance
    Monitors registers") disable Debug Registers access.
    
    When CONFIG_PERF_EVENTS is enabled in the Linux Kernel, it will try to
    initialize the debug monitors. If an error occured Linux won't use this
    feature.
    
    The implementation made Xen expose a minimal set of registers which let 
think
    the guest (i.e.) thinks HW debug won't work.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    [ ijc -- s/DBGCR/DBGBCR/ to use correct register name ]
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    (cherry picked from commit 68c69978352adb5ab7c06598056f9eb88d7d6031)
    [ ijc -- s/is_32bit_domain/is_pv32_domain/ ]

commit d7b4272ae4c14560b90327808425a2c1304b84fc
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Thu Apr 24 23:45:54 2014 +0100

    xen/arm: Implement a dummy Performance Monitor for ARM32
    
    XSA-93 (commit 0b18220 "xen/arm: Don't let guess access to Debug and 
Performance
    Monitor registers") disable Performance Monitor.
    
    When CONFIG_PERF_EVENTS is enabled in the Linux Kernel, regardless the
    ID_DFR0 (which tell if Perfomance Monitors Extension is implemented) the
    kernel will try to access to PMCR.
    
    Therefore we tell the guest we have 0 counters. Unfortunately we must always
    support PMCCNTR (the cycle counter): we just RAZ/WI for all PM register,
    which doesn't crash the kernel at least.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    (cherry picked from commit aa0d443718372b46c432af7cb6274050cda32fc6)

commit 0424674f3fa98b7792c838725fbf5623258698b1
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Tue Jun 17 21:44:28 2014 +0100

    xen/arm: Panic when we receive an unexpected trap
    
    The current implementation of do_unexpected_trap make Xen spin forever
    on the current physical CPU. This may lead to stall guests VCPU and print
    unhelpful message (RCU stall...).
    
    Usually when Xen receives an unexpected trap, it means that something goes
    wrong either in the hypervisor or in the CPU. In this case we should
    directly panic to also stop the other CPUs.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    (cherry picked from commit 4f5ab681d208993f94553203f4be323b3c929070)
(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®.