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

[xen-unstable-smoke test] 110402: regressions - trouble: broken/fail/pass

flight 110402 xen-unstable-smoke real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl          18 leak-check/check         fail REGR. vs. 110375

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  5ec164fd61bd8fc7adfb1ca2907d9159eeb1e37b
baseline version:
 xen                  75dfe7c566c36e0af4714557a666827f49b69191

Last test of basis   110375  2017-06-12 14:01:23 Z    0 days
Testing same since   110402  2017-06-13 09:04:13 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-arm64-arm64-xl-xsm                                      broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     pass    
 test-amd64-amd64-libvirt                                     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

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

Test harness code can be found at

Not pushing.

commit 5ec164fd61bd8fc7adfb1ca2907d9159eeb1e37b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 13 10:41:10 2017 +0200

    x86/boot: re-arrange how/when we do disk I/O
    We place the trampoline no lower than at 256k, so we have ample space
    to read the MBRs of BIOS disks into an aligned buffer right below the
    trampoline (not doing so has been found to be a problem on a buggy BIOS
    coming with a Skull Canyon NUC). To facilitate that move MBR reading
    past EDD info retrieval.
    Also add a wrap check to the EDD info retrieval loop, to match that in
    the MBR reading one.
    Reported-by: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 7f679c4fedb5ca0712c88ac32ba1f62f91a3d10e
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 13 10:39:52 2017 +0200

    domctl: improve device assignment structure layout and use
    Avoid needless gaps. Make flags field mandatory for all three
    operations (and rename it to fit the intended future purpose of
    possibly holding more than just one flag).
    Also correct a typo in a related domctl.h comment.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 1ae4be859b819c147e2034137f519e7fdc2973da
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 13 10:38:51 2017 +0200

    x86: limit page type width
    There's no reason to burn 4 bits on page type when we only have 7 types
    (plus "none") at present. This requires changing one use of
    PGT_shared_page, which so far assumed that the type is both a power of
    2 and the only type with the high bit set.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit c9ec0d34e462151d39e0e901b50501db4f6ae78d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 13 10:38:02 2017 +0200

    x86/HAP: avoid using bogus/misleading locking
    hap_teardown() unconditionally releases the paging lock and is always
    being called without the lock held: Lock acquire should then be
    unconditional too.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)

osstest-output mailing list



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