[Xen-devel] [libvirt test] 31305: trouble: broken/fail/pass

[xen.org <Ian.Jackson@xxxxxxxxxxxxx>]

flight 31305 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31305/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       3 host-install(3)         broken REGR. vs. 31284

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              d91c8e640bf016a359124c8b34aee59774631aa9
baseline version:
 libvirt              720be2eb5f0216564d158dca99c466fac2c16a53

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@xxxxxxxxxx>
  Ján Tomko <jtomko@xxxxxxxxxx>
  Pavel Hrdina <phrdina@xxxxxxxxxx>
  Weiwei Li <nuonuoli@xxxxxxxxxxx>
  weiwei li <weiweili821@xxxxxxxxx>
------------------------------------------------------------

jobs:
 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
 test-amd64-amd64-libvirt                                     fail
 test-armhf-armhf-libvirt                                     fail
 test-amd64-i386-libvirt                                      broken


------------------------------------------------------------
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

broken-step test-amd64-i386-libvirt host-install(3)

Not pushing.

------------------------------------------------------------
commit d91c8e640bf016a359124c8b34aee59774631aa9
Author: Pavel Hrdina <phrdina@xxxxxxxxxx>
Date:   Fri Oct 31 19:00:19 2014 +0100

    mingw: fix build failure

    This macro seems to be defined only on linux/unix and it fails during
    mingw build. Its value is '16' (taken from net/if.h) so define it if
    it's not defined.

    Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>

commit 9998a657fdb7e32317e1e725ebf85146e901416c
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Thu Oct 30 13:42:44 2014 -0600

    domain: fix parsing of memory tunables on 32-bit machines

    Commit 6c9a8a4 (Oct 2014) exposed a long-standing issue on 32-bit
    machines: code related to virDomainSetMemoryParameters has always
    been documented as using a 64-bit limit, but it was implemented by
    calling virDomainParseMemory which enforced an 'unsigned long'
    limit.  Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a
    long is -1, but virDomainParseScaledValue no longer accepts
    negative values, an attempt to use 2^53-1 as a hard memory limit
    started failing the testsuite.  However, the problem with capping
    things artificially low has existed for much longer - ever since
    commits 4888f0fb and 2e22f23 (Mar 2012) switched internal tracking
    from 'unsigned long' to 'unsigned long long' (prior to that time,
    the cap was a side-effect of the choice of types).  We _have_ to
    cap the balloon memory values, (no thanks to baked in 'unsigned long'
    of API such as virDomainSetMaxMemory or virDomainGetInfo with no
    counterpart API that guarantees 64-bit access to those numbers)
    but memory parameters have never needed the artificial limit.

    At any rate, the solution is to make the parser function gain a
    parameter, and only do the reduced 32-bit cap for the values that
    are constrained due to API.

    * src/conf/domain_conf.h (_virDomainMemtune): Add comments.
    * src/conf/domain_conf.c (virDomainParseMemory): Add parameter.
    (virDomainDefParseXML): Adjust callers.

    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit be598c5ff84656d3498b950d473fafe5b86f87b4
Author: weiwei li <weiweili821@xxxxxxxxx>
Date:   Fri Oct 31 16:16:22 2014 +0800

    qemu: Release nbd port from migrationPorts instead of remotePorts

    commit 3e1e16aa8d4238241a1806cb9bdb3b9ad60db777 (Use a port from the
    migration range for NBD as well) changed ndb port allocation from
    remotePorts to migrationPorts, but did not change the port releasing
    process, which makes an error when migrating several times (above 64):
    error: internal error: Unable to find an unused port in range
    'migration' (49152-49215)

    https://bugzilla.redhat.com/show_bug.cgi?id=1159245

    Signed-off-by: Weiwei Li <nuonuoli@xxxxxxxxxxx>
    Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx>

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