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

[Xen-devel] [libvirt test] 60006: regressions - FAIL

flight 60006 libvirt real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 59907
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 59907
 build-i386-pvops              5 kernel-build              fail REGR. vs. 59907
 build-armhf-pvops             5 kernel-build              fail REGR. vs. 59907

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              2094d01e2f54e5774c0d0d380e83154b42ea65be
baseline version:
 libvirt              be6c35e4acdff92c9f9a875de28474a84367f742

Last test of basis    59907  2015-07-25 10:30:59 Z    2 days
Failing since         59948  2015-07-26 04:19:54 Z    1 days    2 attempts
Testing same since    60006  2015-07-27 04:20:16 Z    0 days    1 attempts

People who touched revisions under test:
  Daniel Veillard <veillard@xxxxxxxxxx>
  Laine Stump <laine@xxxxxxxxx>

 build-amd64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            fail    
 build-armhf-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-libvirt-xsm                                 blocked 
 test-armhf-armhf-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 

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

Logs, config files, etc. are available at

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit 2094d01e2f54e5774c0d0d380e83154b42ea65be
Author: Daniel Veillard <veillard@xxxxxxxxxx>
Date:   Mon Jul 27 10:17:05 2015 +0800

    Renamed deconfigured-cpus to allow make dist
    Simplest was just to rename that extra long name and move files in git

commit e14310724071d5853ae5ca612756dfc6b156642e
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Thu Jun 25 12:55:12 2015 -0400

    conf: add virDomainControllerDefNew()
    There are some non-0 default values in virDomainControllerDef (and
    will soon be more) that are easier to not forget if the remembering is
    done by a single initializer function (rather than inline code after
    allocating the obejct with generic VIR_ALLOC().

commit 0726878297c75da15052df3b16d76c7abfd76013
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Thu Jun 25 12:02:32 2015 -0400

    qemu: reorganize loop in qemuDomainAssignPCIAddresses
    This loop occurs just after we've assured that all devices that
    require a PCI device have been assigned and all necessary PCI
    controllers have been added. It is the perfect place to add other
    potentially auto-generated PCI controller attributes that are
    dependent on the controller's PCI address (upcoming patch).
    There is a convenient loop through all controllers at the end of the
    function, but the patch to add new functionality will be cleaner if we
    first rearrange that loop a bit.
    Note that the loop originally was accessing info.addr.pci.bus prior to
    determining that the pci part of the object was valid. This isn't
    dangerous in any way, but seemed a bit ugly, so I fixed it.

commit d4cf72af175dec9ee09b171605409df7000f8356
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Thu Jul 16 16:28:47 2015 -0400

    conf: pay attention to bus minSlot/maxSlot when autoassigning PCI addresses
    The function that auto-assigns PCI addresses was written with the
    hardcoded assumptions that any PCI bus would have slots available
    starting at 1 and ending at 31. This isn't true for many types of
    controllers (some have a single slot/port at 0, some have slots/ports
    from 0 to 31). This patch updates that function to remove the
    hardcoded assumptions. It will properly find/assign addresses for
    devices that can only connect to pcie-(root|downstream)-port (which
    have minSlot/maxSlot of 0/0) or a pcie-switch-upstream-port (0/31).
    It still will not auto-create a new bus of the proper kind for these
    connections when one doesn't exist, that task is for another day.

Xen-devel mailing list



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