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

[xen-4.4-testing test] 61782: regressions - FAIL

flight 61782 xen-4.4-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qcow2      9 debian-di-install         fail REGR. vs. 60727
 test-amd64-i386-xl-raw        9 debian-di-install         fail REGR. vs. 60727
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-vhd   9 debian-di-install         fail REGR. vs. 60727
 test-amd64-amd64-libvirt-raw  9 debian-di-install         fail REGR. vs. 60727
 test-amd64-amd64-libvirt-vhd  9 debian-di-install         fail REGR. vs. 60727
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat    fail  like 60696
 test-amd64-i386-xl-vhd        9 debian-di-install            fail   like 60727
 test-amd64-i386-libvirt-qcow2  9 debian-di-install            fail  like 60727
 test-amd64-amd64-xl-vhd       9 debian-di-install            fail   like 60727
 test-amd64-i386-libvirt      11 guest-start                  fail   like 60727
 test-amd64-amd64-libvirt     11 guest-start                  fail   like 60727
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop             fail like 60727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)               blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install            fail never pass
 test-armhf-armhf-xl-qcow2     9 debian-di-install            fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-amd64-xl-qcow2     9 debian-di-install            fail   never pass
 build-amd64-prev              5 xen-build                    fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-install            fail   never pass
 test-armhf-armhf-xl-vhd       9 debian-di-install            fail   never pass
 build-i386-prev               5 xen-build                    fail   never pass
 test-armhf-armhf-xl-raw       9 debian-di-install            fail   never pass
 test-armhf-armhf-libvirt     11 guest-start                  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-check    fail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
 test-amd64-i386-libvirt-raw  11 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check    fail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check        fail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-check        fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check    fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/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
 test-armhf-armhf-libvirt-vhd  9 debian-di-install            fail   never pass

version targeted for testing:
 xen                  dbded5568e3978360bd044b13891fb81471945b7
baseline version:
 xen                  3646b134c1673f09c0a239de10b0da4c9265c8e8

Last test of basis    60727  2015-08-16 16:15:09 Z   27 days
Failing since         60802  2015-08-20 14:41:37 Z   23 days   11 attempts
Testing same since    61782  2015-09-11 07:48:50 Z    2 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Anshul Makkar <anshul.makkar@xxxxxxxxxx>
  Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Jim Fehlig <jfehlig@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

 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-prev                                             fail
 build-i386-prev                                              fail
 build-amd64-pvops                                            pass
 build-armhf-pvops                                            pass
 build-i386-pvops                                             pass
 build-amd64-rumpuserxen                                      fail
 build-i386-rumpuserxen                                       fail
 test-amd64-amd64-xl                                          pass
 test-armhf-armhf-xl                                          pass
 test-amd64-i386-xl                                           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                    pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass
 test-amd64-i386-freebsd10-amd64                              pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass
 test-amd64-amd64-rumpuserxen-amd64                           blocked
 test-amd64-amd64-xl-qemut-win7-amd64                         fail
 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-armhf-armhf-xl-arndale                                  pass
 test-amd64-amd64-xl-credit2                                  pass
 test-armhf-armhf-xl-credit2                                  pass
 test-armhf-armhf-xl-cubietruck                               pass
 test-amd64-i386-freebsd10-i386                               pass
 test-amd64-i386-rumpuserxen-i386                             blocked
 test-amd64-i386-qemut-rhel6hvm-intel                         pass
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass
 test-amd64-amd64-libvirt                                     fail
 test-armhf-armhf-libvirt                                     fail
 test-amd64-i386-libvirt                                      fail
 test-amd64-amd64-migrupgrade                                 blocked
 test-amd64-i386-migrupgrade                                  blocked
 test-amd64-amd64-xl-multivcpu                                pass
 test-armhf-armhf-xl-multivcpu                                fail
 test-amd64-amd64-pair                                        pass
 test-amd64-i386-pair                                         pass
 test-amd64-amd64-libvirt-pair                                fail
 test-amd64-i386-libvirt-pair                                 fail
 test-amd64-amd64-pv                                          pass
 test-amd64-i386-pv                                           pass
 test-amd64-amd64-amd64-pvgrub                                pass
 test-amd64-amd64-i386-pvgrub                                 pass
 test-amd64-amd64-pygrub                                      pass
 test-amd64-amd64-libvirt-qcow2                               pass
 test-armhf-armhf-libvirt-qcow2                               fail
 test-amd64-i386-libvirt-qcow2                                fail
 test-amd64-amd64-xl-qcow2                                    fail
 test-armhf-armhf-xl-qcow2                                    fail
 test-amd64-i386-xl-qcow2                                     fail
 test-amd64-amd64-libvirt-raw                                 fail
 test-armhf-armhf-libvirt-raw                                 fail
 test-amd64-i386-libvirt-raw                                  pass
 test-amd64-amd64-xl-raw                                      pass
 test-armhf-armhf-xl-raw                                      fail
 test-amd64-i386-xl-raw                                       fail
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass
 test-amd64-amd64-libvirt-vhd                                 fail
 test-armhf-armhf-libvirt-vhd                                 fail
 test-amd64-i386-libvirt-vhd                                  fail
 test-amd64-amd64-xl-vhd                                      fail
 test-armhf-armhf-xl-vhd                                      fail
 test-amd64-i386-xl-vhd                                       fail
 test-amd64-i386-xend-qemut-winxpsp3                          fail
 test-amd64-amd64-xl-qemut-winxpsp3                           pass
 test-amd64-amd64-xl-qemuu-winxpsp3                           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 dbded5568e3978360bd044b13891fb81471945b7
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Sep 10 15:58:41 2015 +0200

    x86/NUMA: make init_node_heap() respect Xen heap limit

    On NUMA systems, where we try to use node local memory for the basic
    control structures of the buddy allocator, this special case needs to
    take into consideration a possible address width limit placed on the
    Xen heap. In turn this (but also other, more abstract considerations)
    requires that xenheap_max_mfn() not be called more than once (at most
    we might permit it to be called a second time with a larger value than
    was passed the first time), and be called only before calling

    While inspecting all the involved code, a couple of off-by-one issues
    were found (and are being corrected here at once):
    - arch_init_memory() cleared one too many page table slots
    - the highmem_start based invocation of xenheap_max_mfn() passed too
      big a value
    - xenheap_max_mfn() calculated the wrong bit count in edge cases

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

    xen/arm64: do not (incorrectly) limit size of xenheap

    The commit 88e3ed61642bb393458acc7a9bd2f96edc337190 "x86/NUMA: make
    init_node_heap() respect Xen heap limit" breaks boot on the arm64 board

    The xenheap bits variable is used to know the last RAM MFN always mapped
    in Xen virtual memory. If the value is 0, it means that all the memory is
    always mapped in Xen virtual memory.

    On X-gene the RAM bank resides above 128GB and last xenheap MFN is
    0x4400000. With the new way to calculate the number of bits, xenheap_bits
    will be equal to 38 bits. This will result to hide all the RAM and the
    impossibility to allocate xenheap memory.

    Given that aarch64 have always all the memory mapped in Xen virtual
    memory, it's not necessary to call xenheap_max_mfn which set the number
    of bits.

    Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 88e3ed61642bb393458acc7a9bd2f96edc337190
    master date: 2015-09-01 14:02:57 +0200
    master commit: 0a7167d9b20cdc48e6ea320fbbb920b3267c9757
    master date: 2015-09-04 14:58:07 +0100

commit e554ae491d780435713381e43deb8356083be3ee
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Thu Sep 10 15:56:03 2015 +0200

    mm: populate_physmap: validate correctly the gfn for direct mapped domain

    Direct mapped domain has already the memory allocated 1:1, so we are
    directly using the gfn as mfn to map the RAM in the guest.

    While we are validating that the page associated to the first mfn belongs to
    the domain, the subsequent MFN are not validated when the extent_order
    is > 0.

    This may result to map memory region (MMIO, RAM) which doesn't belong to the

    Although, only DOM0 on ARM is using a direct memory mapped. So it
    doesn't affect any guest (at least on the upstream version) or even x86.

    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 9503ab0e9c6a41a1ee7a70c8ea9313d08ebaa8c5
    master date: 2015-08-13 14:41:09 +0200

commit e19042ffbdf07e217c827eb0f722be5fe1623ea3
Author: Anshul Makkar <anshul.makkar@xxxxxxxxxx>
Date:   Thu Sep 10 15:55:23 2015 +0200

    x86/mm: Make {hap, shadow}_teardown() preemptible

    A domain with sufficient shadow allocation can cause a watchdog timeout
    during domain destruction.  Expand the existing -EAGAIN logic in
    paging_teardown() to allow {hap/sh}_set_allocation() to become
    restartable during the DOMCTL_destroydomain hypercall.

    Signed-off-by: Anshul Makkar <anshul.makkar@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    master commit: 0174da5b79752e2d5d6ca0faed89536e8f3d91c7
    master date: 2015-08-06 10:04:43 +0100

commit cfb5d2001784dfdec638ba335fd9252f5833ee2d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Sep 10 15:54:13 2015 +0200

    x86/NUMA: don't account hotplug regions

    ... except in cases where they really matter: node_memblk_range[] now
    is the only place all regions get stored. nodes[] and NODE_DATA() track
    present memory only. This improves the reporting when nodes have
    disjoint "normal" and hotplug regions, with the hotplug region sitting
    above the highest populated page. In such cases a node's spanned-pages
    value (visible in both XEN_SYSCTL_numainfo and 'u' debug key output)
    covered all the way up to top of populated memory, giving quite
    different a picture from what an otherwise identically configured
    system without and hotplug regions would report. Note, however, that
    the actual hotplug case (as well as cases of nodes with multiple
    disjoint present regions) is still not being handled such that the
    reported values would represent how much memory a node really has (but
    that can be considered intentional).

    Reported-by: Jim Fehlig <jfehlig@xxxxxxxx>

    This at once makes nodes_cover_memory() no longer consider E820_RAM
    regions covered by SRAT hotplug regions.

    Also reject self-overlaps with mismatching hotplug flags.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Tested-by: Jim Fehlig <jfehlig@xxxxxxxx>
    master commit: c011f470e6e79208f5baa071b4d072b78c88e2ba
    master date: 2015-08-31 13:52:24 +0200

commit 8bea7194a645d5ecb27ad2874eeff7a5734510ce
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Sep 10 15:53:37 2015 +0200

    x86/NUMA: fix setup_node()

    The function referenced an __initdata object (nodes_found). Since this
    being a node mask was more complicated than needed, the variable gets
    replaced by a simple counter. Check at once that the count of nodes
    doesn't go beyond MAX_NUMNODES.

    Also consolidate three printk()s related to the function's use into just

    Finally (quite the opposite of the above issue) __init-annotate

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 8f945d36d9bddd5b589ba23c7322b30d623dd084
    master date: 2015-08-31 13:51:52 +0200

commit 181ebad4a0e9f140054208b17e4936f85c4ee39c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Sep 10 15:52:28 2015 +0200

    IOMMU: skip domains without page tables when dumping

    Reported-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    master commit: 5f335544cf5b716b0af51223e33373c4a7d65e8c
    master date: 2015-08-27 17:40:38 +0200

commit 9a00f96bb09ff8642bef2a3edde855a924093614
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Sep 10 15:51:56 2015 +0200

    x86/IO-APIC: don't create pIRQ mapping from masked RTE

    While moving our XenoLinux patches to 4.2-rc I noticed bogus "already
    mapped" messages resulting from Linux (legitimately) writing RTEs with
    only the mask bit set. Clearly we shouldn't even attempt to create a
    pIRQ <-> IRQ mapping from such RTEs.

    In the course of this I also found that the respective message isn't
    really useful without also printing the pre-existing mapping. And I
    noticed that map_domain_pirq() allowed IRQ0 to get through, despite us
    never allowing a domain to control that interrupt.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 669d4b85c433674ab3b52ef707af0d3a551c941f
    master date: 2015-08-25 16:18:31 +0200

commit 6657f1b596c046c676d280ae6d57ae59de17804e
Author: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
Date:   Thu Sep 10 15:51:02 2015 +0200

    x86, amd_ucode: skip microcode updates for final levels

    Some of older[Fam10h] systems require that certain number of
    applied microcode patch levels should not be overwritten by
    the microcode loader. Otherwise, system hangs are known to occur.

    The 'final_levels' of patch ids have been obtained empirically.
    Refer bug https://bugzilla.suse.com/show_bug.cgi?id=913996
    for details of the issue.

    The short version is that people have predominantly noticed
    system hang issues when trying to update microcode levels
    beyond the patch IDs below.
    [0x01000098, 0x0100009f, 0x010000af]

    From internal discussions, we gathered that OS/hypervisor
    cannot reliably perform microcode updates beyond these levels
    due to hardware issues. Therefore, we need to abort microcode
    update process if we hit any of these levels.

    In this patch, we check for those microcode versions and abort
    if the current core has one of those final patch levels applied
    by the BIOS

    A linux version of the patch has already made it into tip-

    Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    master commit: 22c5675877c8209adcfdb6bceddb561320374529
    master date: 2015-08-25 16:17:13 +0200

commit 23c132291d62931be5cc58a67aaa757ebba83ddc
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Sep 10 15:49:59 2015 +0200

    x86/gdt: Drop write-only, xalloc()'d array from set_gdt()

    It is not used, and can cause a spurious failure of the set_gdt() hypercall 
    low memory situations.

    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    master commit: a7bd9b1661304500cd18b7d216d616ecf053ebdb
    master date: 2015-08-05 10:32:45 +0100

commit ff9758b54ffe27ce2961de5412c0dc5af9c6abef
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Wed Sep 9 16:14:16 2015 +0200

    Config.mk: update in-tree OVMF changeset

    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 28e5d9a9ad8e7e1a50503ec97ce9d20cd451a5d1
    master date: 2015-06-30 16:16:47 +0100

commit 339f5743e84a28dd01ffa7498372e410301cd0b4
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Thu Aug 13 12:03:43 2015 +0100

    xen/arm: mm: Do not dump the p2m when mapping a foreign gfn

    The physmap operation XENMAPSPACE_gfmn_foreign is dumping the p2m when
    an error occured by calling dump_p2m_lookup. But this function is not
    using ratelimited printk.

    Any domain able to map foreign gfmn would be able to flood the Xen

    The information wasn't not useful so drop it.

    This is XSA-141.

    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    (cherry picked from commit afc13fe5e21d18c09e44f8ae6f7f4484e9f1de7f)

commit 5b6f36000c40654491ab84a0c55af37129ec4793
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 2 14:47:25 2015 +0200

    update Xen version to 4.4.4-pre

commit 27b82b08b17f589f638f3d5be8dcea42b5e73330
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Aug 20 16:19:38 2015 +0200

    update Xen version to 4.4.3
(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®.