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

[Xen-devel] [xen-4.4-testing test] 25554: regressions - FAIL



flight 25554 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/25554/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xend              4 xen-build        fail in 25550 REGR. vs. 25410

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 10 guest-saverestore        fail pass in 25550
 test-amd64-amd64-xl-winxpsp3 11 guest-saverestore.2 fail in 25550 pass in 25554

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-pv            1 xen-build-check(1)        blocked in 25550 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 25550 n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1) blocked in 25550 n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)       blocked in 25550 n/a

version targeted for testing:
 xen                  67fda497099b7451fb2dec826af120bf6333bc67
baseline version:
 xen                  8c2bc5d6796324aa93e2847fafb6fe1feeb11647

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  David Vrabel <david.vrabel@xxxxxxxxxx>
  Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
  Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
  Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
  Yang Zhang <yang.z.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-i386-freebsd10-amd64                              fail    
 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-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


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


Not pushing.

------------------------------------------------------------
commit 67fda497099b7451fb2dec826af120bf6333bc67
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Fri Mar 14 17:29:54 2014 +0100

    xmalloc: handle correctly page allocation when align > size
    
    When align is superior to size, we need to retrieve the order from
    align during multiple page allocation. I guess it was the goal of the commit
    fb034f42 "xmalloc: make close-to-PAGE_SIZE allocations more efficient".
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: ac2cba2901779f66bbfab298faa15c956e91393a
    master date: 2014-03-10 14:40:50 +0100

commit f81f1c6c45c3a7b3b99ee56e71d5374186fe6c37
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 14 17:29:03 2014 +0100

    kexec: identify which cpu the kexec image is being executed on
    
    A patch to this effect has been in XenServer for a little while, and has
    proved to be a useful debugging point for servers which have different
    behaviours depending when crashing on the non-bootstrap processor.
    
    Moving the printk() from kexec_panic() to one_cpu_only() means that it will
    only be printed for the cpu which wins the race along the kexec path.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    master commit: 4509ada6ba1f09cc8f4fa23e009e7e5a963b6086
    master date: 2014-03-10 11:11:28 +0100

commit 9337cb937d80953f08b10d45a9e75f005a855477
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:28:20 2014 +0100

    x86/HVM: consolidate passthrough handling in epte_get_entry_emt()
    
    It is inconsistent to depend on iommu_enabled alone: For a guest
    without devices passed through to it, it is of no concern whether the
    IOMMU is enabled.
    
    There's one rather special case to take care of: VMX code marks the
    LAPIC access page as MMIO. The added assertion needs to take this into
    consideration, and the subsequent handling of the direct MMIO case was
    inconsistent too: That page would have been WB in the absence of an
    IOMMU, but UC in the presence of it, while in fact the cachabilty of
    this page is entirely unrelated to an IOMMU being in use.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 3089a6d82bdf3112ccb1dd074ce34a8cbdc4ccd8
    master date: 2014-03-10 11:04:36 +0100

commit 6fc747461edc2dc920d07a247acda9552c7bbfb9
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:27:42 2014 +0100

    x86/HVM: fix memory type merging in epte_get_entry_emt()
    
    Using the minimum numeric value of guest and host specified memory
    types is too simplistic - it works only correctly for a subset of
    types. It is in particular the WT/WP combination that needs conversion
    to UC if the two types conflict.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: b99113b9d5fac5149de8496f55afa00e285b1ff3
    master date: 2014-03-10 11:03:53 +0100

commit 85fc087ebf722abef3198bc644fc723cb9a0ab95
Author: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
Date:   Fri Mar 14 17:27:01 2014 +0100

    x86/hvm: refine the judgment on IDENT_PT for EMT
    
    When trying to get the EPT EMT type, the judgment on
    HVM_PARAM_IDENT_PT is not correct which always returns WB type if
    the parameter is not set. Remove the related code.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
    
    We can't fully drop the dependency yet, but we should certainly avoid
    overriding cases already properly handled. The reason for this is that
    the guest setting up its MTRRs happens _after_ the EPT tables got
    already constructed, and no code is in place to propagate this to the
    EPT code. Without this check we're forcing the guest to run with all of
    its memory uncachable until something happens to re-write every single
    EPT entry. But of course this has to be just a temporary solution.
    
    In the same spirit we should defer the "very early" (when the guest is
    still being constructed and has no vCPU yet) override to the last
    possible point.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: cadfd7bca999c0a795dc27be72d43c92e8943a0b
    master date: 2014-03-10 11:02:25 +0100

commit cdac89d18725608c655f211cc4d5a642dab1a047
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:25:27 2014 +0100

    IOMMU: generalize and correct softirq processing during Dom0 device setup
    
    c/s 21039:95f5a4ce8f24 ("VT-d: reduce default verbosity") having put a
    call to process_pending_softirqs() in VT-d's domain_context_mapping()
    was wrong in two ways: For one we shouldn't be doing this when setting
    up a device during DomU assignment. And then - I didn't check whether
    that was the case already back then - we shouldn't call that function
    with the pcidevs_lock (or in fact any spin lock) held.
    
    Move the "preemption" into generic code, at once dealing with further
    actual (too much output elsewhere - particularly on systems with very
    many host bridge like devices - having been observed to still cause the
    watchdog to trigger when enabled) and potential (other IOMMU code may
    also end up being too verbose) issues.
    
    Do the "preemption" once per device actually being set up when in
    verbose mode, and once per bus otherwise.
    
    Note that dropping pcidevs_lock around the process_pending_softirqs()
    invocation is specifically not a problem here: We're in an __init
    function and aren't racing with potential additions/removals of PCI
    devices. Not acquiring the lock in setup_dom0_pci_devices() otoh is not
    an option, as there are too many places that assert the lock being
    held.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
    master commit: 9ef5aa944a6a0df7f5938983043c7e46f158bbc6
    master date: 2014-03-04 10:52:20 +0100

commit dbe2cbc0180c43965b1e0aec7e33edf5b0863552
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 14 17:24:16 2014 +0100

    x86/mce: Reduce boot-time logspam
    
    When booting with "no-mce", the user does not need to be told that "MCE
    support [was] disabled by bootparam" for each cpu.  Furthermore, a file:line
    reference is unnecessary.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: a5ab9c9fa29cda7e1b18dbcaa69a5dbded96de32
    master date: 2014-02-25 09:30:59 +0100

commit 09f13cea2ca2da009026d05b7175558e84bc2f8a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:23:27 2014 +0100

    x86/MSI: don't risk division by zero
    
    The check in question is redundant with the one in the immediately
    following if(), where dividing by zero gets carefully avoided.
    
    Spotted-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    master commit: 5d160d913e03b581bdddde73535c18ac670cf0a9
    master date: 2014-02-24 12:11:01 +0100

commit 9d2a5fcf09f75b3fc1584375b71517b62c0be53f
Author: Yang Zhang <yang.z.zhang@xxxxxxxxx>
Date:   Fri Mar 14 17:22:30 2014 +0100

    Nested VMX: update nested paging mode on vmexit
    
    Since SVM and VMX use different mechanism to emulate the virtual-vmentry
    and virtual-vmexit, it's hard to update the nested paging mode correctly in
    common code. So we need to update the nested paging mode in their respective
    code path.
    SVM already updates the nested paging mode on vmexit. This patch adds the 
same
    logic in VMX side.
    
    Previous discussion is here:
    http://lists.xen.org/archives/html/xen-devel/2013-12/msg01759.html
    
    Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    Reviewed-by: Christoph Egger <chegger@xxxxxxxxx>
    master commit: fd1864f48d8914fb8eeb6841cd08c2c09b368909
    master date: 2014-02-24 12:09:52 +0100

commit 9bd7260131d65a1c378dd3dc1cf3bc20c40fadd2
Author: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
Date:   Fri Mar 14 17:18:32 2014 +0100

    x86/MCE: Fix race condition in mctelem_reserve
    
    These lines (in mctelem_reserve)
    
            newhead = oldhead->mcte_next;
            if (cmpxchgptr(freelp, oldhead, newhead) == oldhead) {
    
    are racy. After you read the newhead pointer it can happen that another
    flow (thread or recursive invocation) change all the list but set head
    with same value. So oldhead is the same as *freelp but you are setting
    a new head that could point to whatever element (even already used).
    
    This patch use instead a bit array and atomic bit operations.
    
    Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
    Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx>
    master commit: 60ea3a3ac3d2bcd8e85b250fdbfc46b3b9dc7085
    master date: 2014-02-24 12:07:41 +0100

commit c261a2e8dc37080c0195e5c34126a4a379229e1b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 16:09:49 2014 +0100

    update MAINTAINERS for stable branch

commit f69f1fb8e20a4fd04bfef50cbdddcf810c108277
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Fri Mar 14 14:27:47 2014 +0000

    update Xen version to 4.4.1-pre
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
(qemu changes not included)

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


 


Rackspace

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