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

[Xen-devel] [xen-4.2-testing test] 25500: regressions - FAIL



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 25152

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-i386-xl-qemuu-winxpsp3 14 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  ea3db636df531428320e6ab61479731be283ac23
baseline version:
 xen                  0620cc886eef9018d2b2a5fcdc641be70b5ac54b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
  Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
  Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-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-qemuu-freebsd10-amd64                        pass    
 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-qemuu-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-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-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-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-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 ea3db636df531428320e6ab61479731be283ac23
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:52:27 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 1df316f038151cb23350337b6e1ee1a94fb4f9d8
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:51:39 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 999d56f527282399b68592635e55625fbf9b94d7
Author: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
Date:   Fri Mar 14 17:51:07 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 83a20cab51bbedf48d45ca662cbde0a63f57fbb7
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:50:03 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 d404af9ba05389a43de8cf56e6c174bfb86db62e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 14 17:45:52 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 f4c6912c95ed5d5bb08e1b07b9588876595ecdbd
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Mar 14 17:45:14 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 ea3ec32f7956917eb0339b2b0df24e8f658a05ed
Author: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
Date:   Fri Mar 14 17:44:19 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 fa669779b4a9d07d35a9708ac97d2c98063c29b1
Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Date:   Fri Mar 14 17:43:15 2014 +0100

    x86/pci: Store VF's memory space displacement in a 64-bit value
    
    VF's memory space offset can be greater than 4GB and therefore needs
    to be stored in a 64-bit variable.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    master commit: 001bdcee7bc19be3e047d227b4d940c04972eb02
    master date: 2014-02-13 10:49:55 +0100

commit 50d989262d136b7a5a602c80681705ac6cfe95a8
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Jan 7 10:04:23 2014 +0000

    tools/libxc: Correct read_exact() error messages
    
    The errors have been incorrectly identifying their function since c/s
    861aef6e1558bebad8fc60c1c723f0706fd3ed87 which did a lot of error handling
    cleanup.
    
    Use __func__ to ensure the name remains correct in the future.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 1671cdeac7da663fb2963f3e587fa279dcd0238b)
(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®.