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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 18283

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  30c091a4b9911eb608b2de604652d02aeaadb806
baseline version:
 xen                  78748fe8846627ddf3cccdaa3a1ff907a6132568

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 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-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-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-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-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 woking.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 30c091a4b9911eb608b2de604652d02aeaadb806
Author: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
Date:   Thu Jul 11 14:23:27 2013 +0200

    iommu/amd: Workaround for erratum 787
    
    The IOMMU interrupt handling in bottom half must clear the PPR log interrupt
    and event log interrupt bits to re-enable the interrupt. This is done by
    writing 1 to the memory mapped register to clear the bit. Due to hardware 
bug,
    if the driver tries to clear this bit while the IOMMU hardware also setting
    this bit, the conflict will result with the bit being set. If the interrupt
    handling code does not make sure to clear this bit, subsequent changes in 
the
    event/PPR logs will no longer generating interrupts, and would result if
    buffer overflow. After clearing the bits, the driver must read back
    the register to verify.
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    
    Adjust to apply on top of heavily modified patch 1. Adjust flow to get away
    with a single readl() in each instance of the status register checks.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    master commit: 9eabb0735400e2b6059dfa3f0b47a426f61f570a
    master date: 2013-07-02 08:50:41 +0200

commit 5c33c9ce22fe3c03242cdd465feb518bb614f7c7
Author: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
Date:   Thu Jul 11 14:22:44 2013 +0200

    iommu/amd: Fix logic for clearing the IOMMU interrupt bits
    
    The IOMMU interrupt bits in the IOMMU status registers are
    "read-only, and write-1-to-clear (RW1C).  Therefore, the existing
    logic which reads the register, set the bit, and then writing back
    the values could accidentally clear certain bits if it has been set.
    
    The correct logic would just be writing only the value which only
    set the interrupt bits, and leave the rest to zeros.
    
    This patch also, clean up #define masks as Jan has suggested.
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    
    With iommu_interrupt_handler() properly having got switched its readl()
    from status to control register, the subsequent writel() needed to be
    switched too (and the RW1C comment there was bogus).
    
    Some of the cleanup went too far - undone.
    
    Further, with iommu_interrupt_handler() now actually disabling the
    interrupt sources, they also need to get re-enabled by the tasklet once
    it finished processing the respective log. This also implies re-running
    the tasklet so that log entries added between reading the log and re-
    enabling the interrupt will get handled in a timely manner.
    
    Finally, guest write emulation to the status register needs to be done
    with the RW1C (and RO for all other bits) semantics in mind too.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    master commit: 2823a0c7dfc979db316787e1dd42a8845e5825c0
    master date: 2013-07-02 08:49:43 +0200

commit 094c1cb9757a3456ea63491a1c0d6016bdfa2711
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Jul 11 14:21:48 2013 +0200

    x86: don't pass negative time to gtime_to_gtsc() (try 2)
    
    This mostly reverts commit eb60be3d ("x86: don't pass negative time to
    gtime_to_gtsc()") and instead corrects __update_vcpu_system_time()'s
    handling of this_cpu(cpu_time).stime_local_stamp dating back before the
    start of a HVM guest (which would otherwise lead to a negative value
    getting passed to gtime_to_gtsc(), causing scale_delta() to produce
    meaningless output).
    
    Flushing the value to zero was wrong, and printing a message for
    something that can validly happen wasn't very useful either.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 5ad914bc867c5a6a4957869c89918f4e1f9dd9c4
    master date: 2013-07-02 08:48:03 +0200

commit 8109c123702e2387b0781f3feaa4b53744464009
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jul 11 14:18:57 2013 +0200

    AMD/intremap: Prevent use of per-device vector maps until irq logic is fixed
    
    XSA-36 changed the default vector map mode from global to per-device.  This 
is
    because a global vector map does not prevent one PCI device from 
impersonating
    another and launching a DoS on the system.
    
    However, the per-device vector map logic is broken for devices with multiple
    MSI-X vectors, which can either result in a failed ASSERT() or 
misprogramming
    of a guests interrupt remapping tables.  The core problem is not trivial to
    fix.
    
    In an effort to get AMD systems back to a non-regressed state, introduce a 
new
    type of vector map called per-device-global.  This uses per-device vector 
maps
    in the IOMMU, but uses a single used_vector map for the core IRQ logic.
    
    This patch is intended to be removed as soon as the per-device logic is 
fixed
    correctly.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    master commit: f0fe8227624d5c02715ed086867d12cd24f6ff47
    master date: 2013-06-27 14:01:18 +0200

commit 7f6b1086489c0382c3f8c6a2026a6d0eaa53ea97
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Jul 11 13:41:54 2013 +0200

    libelf: fix printing of pointers
    
    Printing them as decimal number, the more with 0x prefix, is confusing
    and presumably relatively useless to most of us.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 59912eb06fda88af6c5ec16a2a382619d3829a7b
    master date: 2013-06-26 14:43:52 +0100
(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®.