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

[Xen-devel] [libvirt test] 112310: regressions - trouble: blocked/broken/fail/pass



flight 112310 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112310/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops             4 host-install(4)        broken REGR. vs. 112276
 build-arm64                   4 host-install(4)        broken REGR. vs. 112276
 build-arm64-xsm               4 host-install(4)        broken REGR. vs. 112276
 build-i386-pvops              6 kernel-build             fail REGR. vs. 112276

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-arm64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 112276
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check    fail  like 112276
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 112276
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              cc1329b62759e7fc6a5a34ca18b5c072693aa3eb
baseline version:
 libvirt              f7237d63e8f02f3689f9b63b413fae7d4221faa9

Last test of basis   112276  2017-07-25 04:21:09 Z    1 days
Testing same since   112310  2017-07-26 04:21:38 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@xxxxxxxxxx>
  John Ferlan <jferlan@xxxxxxxxxx>
  Martin Kletzander <mkletzan@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  Pavel Hrdina <phrdina@xxxxxxxxxx>
  Scott Garfinkle <seg@xxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              broken  
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  broken  
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            broken  
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            blocked 
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-libvirt                                     pass    
 test-arm64-arm64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 blocked 
 test-arm64-arm64-libvirt-qcow2                               blocked 
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-step build-arm64-pvops host-install(4)
broken-step build-arm64 host-install(4)
broken-step build-arm64-xsm host-install(4)

Not pushing.

------------------------------------------------------------
commit cc1329b62759e7fc6a5a34ca18b5c072693aa3eb
Author: Pavel Hrdina <phrdina@xxxxxxxxxx>
Date:   Tue Jul 25 23:10:00 2017 +0200

    qemu: we prefer C89 comment styles over C99
    
    Introduced by commit 'a7bc2c8cfd6f'.
    
    Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>

commit a7bc2c8cfd6f13f7b3f8fcb793fee04b39473788
Author: Scott Garfinkle <seg@xxxxxxxxxx>
Date:   Tue Jul 25 09:33:50 2017 -0500

    Generate unique socket file
    
    It's possible to have more than one unnamed virtio-serial unix channel.
    We need to generate a unique name for each channel. Currently, we use
    ".../unknown.sock" for all of them. Better practice would be to specify
    an explicit target path name; however, in the absence of that, we need
    uniqueness in the names we generate internally.
    
    Before the changes we'd get 
/var/lib/libvirt/qemu/channel/target/unknown.sock
    for each instance of
        <channel type='unix'>
            <source mode='bind'/>
            <target type='virtio'/>
        </channel>
    
    Now, we get vioser-00-00-01.sock, vioser-00-00-02.sock, etc.
    
    Signed-off-by: Scott Garfinkle <seg@xxxxxxxxxx>

commit eaf2c9f89107b9f60cf8db2c919f78b987ff7177
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Fri Jul 21 15:51:03 2017 +0200

    Move machineName generation from virsystemd into domain_conf
    
    It is more related to a domain as we might use it even when there is
    no systemd and it does not use any dbus/systemd functions.  In order
    not to use code from conf/ in util/ pass machineName in cgroups code
    as a parameter.  That also fixes a leak of machineName in the lxc
    driver and cleans up and de-duplicates some code.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit aa0dfb91d547e4020018e77fd3211e35c6311de9
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Fri Jul 21 15:56:46 2017 +0200

    lxc: Make lxcProcessStop callable even without PID being available
    
    This way the function can work as a central point of clean-up code and
    we don't have to duplicate code.  And it works similarly to the qemu
    driver.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 2e6ecba1bcac898e1714db423cf3549c0d5f1ce0
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Fri Jul 21 15:46:56 2017 +0200

    qemu: Save qemu driver in qemuDomainObjPrivateData
    
    This way we can finally make it static and not use any externs anywhere.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 6e6faf6d627d5ea291d9ff2378f7d1eb59e1d14e
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Fri Jul 21 15:29:00 2017 +0200

    conf: Pass config.priv to xmlopt->privateData.alloc
    
    This will help us to get to some data more easily.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 867bcc9c783cc07fc73413028a13ebf449cfb9d1
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Jun 1 12:43:06 2017 -0400

    secret: Handle object list removal and deletion properly
    
    Rather than rely on virSecretObjEndAPI to make the final virObjectUnref
    after the call to virSecretObjListRemove, be more explicit by calling
    virObjectUnref and setting @obj to NULL for secretUndefine and in
    the error path of secretDefineXML. Calling EndAPI will end up calling
    Unlock on an already unlocked object which has indeteriminate results
    (usually an ignored error).
    
    The virSecretObjEndAPI will both Unref and Unlock the object; however,
    the virSecretObjListRemove would have already Unlock'd the object so
    calling Unlock again is incorrect. Once the virSecretObjListRemove
    is called all that's left is to Unref our interest since that's the
    corrollary to the virSecretObjListAdd which returned our ref interest
    plus references for each hash table in which the object resides. In math
    terms, after an Add there's 2 refs on the object (1 for the object and
    1 for the list). After calling Remove there's just 1 ref on the object.
    For the Add callers, calling EndAPI removes the ref for the object and
    unlocks it, but since it's in a list the other 1 remains.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit d04bc0278d25f41272318ba72f11011874472481
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Tue Jul 25 09:02:09 2017 -0400

    secret: Fix memory leak in virSecretLoad
    
    If the virSecretLoadValue fails, the code jumped to cleanup without
    setting @ret = obj, thus calling virSecretObjListRemove which only
    accounts for the object reference related to adding the object to
    the list during virSecretObjListAdd, but does not account for the
    reference to the object itself as the return of @ret would be NULL
    so the caller wouldn't call virSecretObjEndAPI on the object recently
    added thus reducing the refcnt to zero.
    
    This patch will perform the ObjListRemove in the failure path of
    virSecretLoadValue and Unref @obj in order to perform clean up
    and return @obj as NULL. The @def will be freed as part of the
    virObjectUnref.

commit e4c0aff21514230f2f15aa5c7083219e1033f048
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Jun 1 08:17:52 2017 -0400

    secret: Properly handle @def after virSecretObjAdd in driver
    
    Since the virSecretObjListAdd technically consumes @def on success,
    the secretDefineXML should set @def = NULL immediately and process
    the remaining calls using a new @objDef variable. We can use use
    VIR_STEAL_PTR since we know the Add function just stores @def in
    obj->def.
    
    Because we steal @def into @objDef, if we jump to restore_backup:
    and @backup is set, then we need to ensure the @def would be
    free'd properly, so we'll steal it back from @objDef. For the other
    condition this fixes a double free of @def if the code had jumped to
    @backup == NULL thus calling virSecretObjListRemove without setting
    @def = NULL. In this case, the subsequent call to DefFree would
    succeed and free @def; however, the call to EndAPI would also
    call DefFree because the Unref done would be the last one for
    the @obj meaning the obj->def would be used to call DefFree,
    but it's already been free'd because @def wasn't managed right
    within this error path.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 7ca17da9f2f645398ea1315ce41b0a005651a02d
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Wed May 31 15:11:28 2017 -0400

    secret: Remove need for local configFile and base64File in ObjectAdd
    
    Rather than assign to a local variable, let's just assign directly to the
    object using the error path for cleanup.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 2d3c7122c88626d8f27fc72d77819469369016cc
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Jul 25 10:31:54 2017 +0200

    Revert "virthread: Introduce virRWLockInitPreferWriter"
    
    This reverts commit 328bd24443d2a345a5832ee48ebba0208f8036ea.
    
    As it turns out, this is not portable and very Linux & glibc
    specific. Worse, this may lead to not starving writers on Linux
    but everywhere else. Revert this and if the starvation occurs
    resolve it.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit bbda2883c43306874ea22fb48534091ecb6faf7b
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Mon Jul 24 13:26:57 2017 +0200

    conf: Rename virDomainControllerIsPCIHostBridge() to IsPSeriesPHB()
    
    The original name didn't hint at the fact that PHBs are
    a pSeries-specific concept.
    
    Suggested-by: Peter Krempa <pkrempa@xxxxxxxxxx>
    Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>

commit 9b45cd8fab1c7d7d07dd3ae64970b3c93b78e04c
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jul 19 10:37:04 2017 +0200

    conf: Fix backwards migration of pSeries guests
    
    Recent commits made it so that pci-root controllers for
    pSeries guests are automatically assigned the
    spapr-pci-host-bridge model name; however, that prevents
    guests to migrate to older versions of libvirt which don't
    know about that model name at all, which at the moment is
    all of them :)
    
    To avoid the issue, just strip the model name from PHBs
    when formatting the migratable XML; guests that use more
    than one PHB are not going to be migratable anyway.
    
    Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>

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

 


Rackspace

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