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

[Xen-devel] [linux-3.10 test] 25748: regressions - FAIL



flight 25748 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/25748/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel 10 guest-destroy           fail REGR. vs. 25710

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot            fail pass in 25744
 test-amd64-amd64-xl-qemut-win7-amd64 11 guest-saverestore.2 fail pass in 25744
 test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail in 25744 pass in 25748
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 25744 pass in 25748
 test-amd64-i386-xl-win7-amd64 13 guest-localmigrate/x10 fail in 25744 pass in 
25748

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail like 25697
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 25710
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 25710

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

version targeted for testing:
 linux                8f0c10ea2ec6e1086fbb73ff8bcbbf1ed8584b11
baseline version:
 linux                a2e124daef622d8745510ab24b023027dcdc9146

------------------------------------------------------------
People who touched revisions under test:
  "Theodore Ts'o" <tytso@xxxxxxx>
  Adam Williamson <awilliam@xxxxxxxxxx>
  Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
  Artem Fetishev <artem_fetishev@xxxxxxxx>
  Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
  Daniel Borkmann <dborkman@xxxxxxxxxx>
  David Rientjes <rientjes@xxxxxxxxxx>
  David S. Miller <davem@xxxxxxxxxxxxx>
  Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
  GiulioDP <depasquale.giulio@xxxxxxxxx>
  Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
  Hans de Goede <hdegoede@xxxxxxxxxx>
  Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
  Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
  Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 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                              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-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 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                                          blocked 
 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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-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 8f0c10ea2ec6e1086fbb73ff8bcbbf1ed8584b11
Author: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Date:   Thu Apr 3 12:01:22 2014 -0700

    Linux 3.10.36

commit b086eb683c73fb6a506eae277f65eeac597a6f16
Author: Daniel Borkmann <dborkman@xxxxxxxxxx>
Date:   Mon Jan 6 00:57:54 2014 +0100

    netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages
    
    commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.
    
    Some occurences in the netfilter tree use skb_header_pointer() in
    the following way ...
    
      struct dccp_hdr _dh, *dh;
      ...
      skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);
    
    ... where dh itself is a pointer that is being passed as the copy
    buffer. Instead, we need to use &_dh as the forth argument so that
    we're copying the data into an actual buffer that sits on the stack.
    
    Currently, we probably could overwrite memory on the stack (e.g.
    with a possibly mal-formed DCCP packet), but unintentionally, as
    we only want the buffer to be placed into _dh variable.
    
    Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
    Signed-off-by: Daniel Borkmann <dborkman@xxxxxxxxxx>
    Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit def52acc90faab583b124f3177d55c15d125e2d1
Author: David Rientjes <rientjes@xxxxxxxxxx>
Date:   Mon Mar 3 15:38:18 2014 -0800

    mm: close PageTail race
    
    commit 668f9abbd4334e6c29fa8acd71635c4f9101caa7 upstream.
    
    Commit bf6bddf1924e ("mm: introduce compaction and migration for
    ballooned pages") introduces page_count(page) into memory compaction
    which dereferences page->first_page if PageTail(page).
    
    This results in a very rare NULL pointer dereference on the
    aforementioned page_count(page).  Indeed, anything that does
    compound_head(), including page_count() is susceptible to racing with
    prep_compound_page() and seeing a NULL or dangling page->first_page
    pointer.
    
    This patch uses Andrea's implementation of compound_trans_head() that
    deals with such a race and makes it the default compound_head()
    implementation.  This includes a read memory barrier that ensures that
    if PageTail(head) is true that we return a head page that is neither
    NULL nor dangling.  The patch then adds a store memory barrier to
    prep_compound_page() to ensure page->first_page is set.
    
    This is the safest way to ensure we see the head page that we are
    expecting, PageTail(page) is already in the unlikely() path and the
    memory barriers are unfortunately required.
    
    Hugetlbfs is the exception, we don't enforce a store memory barrier
    during init since no race is possible.
    
    Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx>
    Cc: Holger Kiehl <Holger.Kiehl@xxxxxx>
    Cc: Christoph Lameter <cl@xxxxxxxxx>
    Cc: Rafael Aquini <aquini@xxxxxxxxxx>
    Cc: Vlastimil Babka <vbabka@xxxxxxx>
    Cc: Michal Hocko <mhocko@xxxxxxx>
    Cc: Mel Gorman <mgorman@xxxxxxx>
    Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
    Cc: Rik van Riel <riel@xxxxxxxxxx>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit d113edc6c7027a8290ddfb2f0c5ab8291a582945
Author: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
Date:   Wed Mar 26 00:25:41 2014 +0100

    net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE
    
    commit a79121d3b57e7ad61f0b5d23eae05214054f3ccd upstream.
    
    Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
    not the PSC: there was a typo in the name of the define, which this
    commit fixes.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit a16257f0ccd9bea56f2f60131eec7525147ecc80
Author: Artem Fetishev <artem_fetishev@xxxxxxxx>
Date:   Fri Mar 28 13:33:39 2014 -0700

    x86: fix boot on uniprocessor systems
    
    commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream.
    
    On x86 uniprocessor systems topology_physical_package_id() returns -1
    which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized
    which leads to GPF in rapl_pmu_init().
    
    See arch/x86/kernel/cpu/perf_event_intel_rapl.c.
    
    It turns out that physical_package_id and core_id can actually be
    retreived for uniprocessor systems too.  Enabling them also fixes
    rapl_pmu code.
    
    Signed-off-by: Artem Fetishev <artem_fetishev@xxxxxxxx>
    Cc: Stephane Eranian <eranian@xxxxxxxxxx>
    Cc: Ingo Molnar <mingo@xxxxxxx>
    Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
    Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
    Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 36e6781e914b1232ba0bd0ca8ae718941cb2fa8f
Author: Hans de Goede <hdegoede@xxxxxxxxxx>
Date:   Wed Mar 26 13:30:52 2014 -0700

    Input: cypress_ps2 - don't report as a button pads
    
    commit 6797b39e6f6f34c74177736e146406e894b9482b upstream.
    
    The cypress PS/2 trackpad models supported by the cypress_ps2 driver
    emulate BTN_RIGHT events in firmware based on the finger position, as part
    of this no motion events are sent when the finger is in the button area.
    
    The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that
    BTN_RIGHT events should be emulated in userspace, which is not necessary
    in this case.
    
    When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion
    event before propagating the button event higher up the stack, as it needs
    current abs x + y data for its BTN_RIGHT emulation. Since in the
    cypress_ps2 pads don't report motion events in the button area, this means
    that clicks in the button area end up being ignored, so
    INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and
    removing it fixes:
    
    https://bugs.freedesktop.org/show_bug.cgi?id=76341
    
    Reported-by: Adam Williamson <awilliam@xxxxxxxxxx>
    Tested-by: Adam Williamson <awilliam@xxxxxxxxxx>
    Reviewed-by: Peter Hutterer <peter.hutterer@xxxxxxxxx>
    Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit cbcc4cb6cc8fe13959a52db4427c1ccc01655d4e
Author: Hans de Goede <hdegoede@xxxxxxxxxx>
Date:   Fri Mar 28 01:01:38 2014 -0700

    Input: synaptics - add manual min/max quirk for ThinkPad X240
    
    commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.
    
    This extends Benjamin Tissoires manual min/max quirk table with support for
    the ThinkPad X240.
    
    Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 586c76514fd25905e4a8ae1547b0abbc5b723b42
Author: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
Date:   Fri Mar 28 00:43:00 2014 -0700

    Input: synaptics - add manual min/max quirk
    
    commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.
    
    The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
    However, these new Synaptics devices report bad axis ranges.
    Under Windows, it is not a problem because the Windows driver uses RMI4
    over SMBus to talk to the device. Under Linux, we are using the PS/2
    fallback interface and it occurs the reported ranges are wrong.
    
    Of course, it would be too easy to have only one range for the whole
    series, each touchpad seems to be calibrated in a different way.
    
    We can not use SMBus to get the actual range because I suspect the firmware
    will switch into the SMBus mode and stop talking through PS/2 (this is the
    case for hybrid HID over I2C / PS/2 Synaptics touchpads).
    
    So as a temporary solution (until RMI4 land into upstream), start a new
    list of quirks with the min/max manually set.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 26b4b569fda35284ed402419e45e1e897a7f467d
Author: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
Date:   Thu Mar 6 12:57:24 2014 -0800

    Input: mousedev - fix race when creating mixed device
    
    commit e4dbedc7eac7da9db363a36f2bd4366962eeefcc upstream.
    
    We should not be using static variable mousedev_mix in methods that can be
    called before that singleton gets assigned. While at it let's add open and
    close methods to mousedev structure so that we do not need to test if we
    are dealing with multiplexor or normal device and simply call appropriate
    method directly.
    
    This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551
    
    Reported-by: GiulioDP <depasquale.giulio@xxxxxxxxx>
    Tested-by: GiulioDP <depasquale.giulio@xxxxxxxxx>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 0a0ae7b3fb0fb301da83f7c7da38807c76b2b869
Author: Theodore Ts'o <tytso@xxxxxxx>
Date:   Sun Mar 30 10:20:01 2014 -0400

    ext4: atomically set inode->i_flags in ext4_set_inode_flags()
    
    commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.
    
    Use cmpxchg() to atomically set i_flags instead of clearing out the
    S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
    EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
    where an immutable file has the immutable flag cleared for a brief
    window of time.
    
    Reported-by: John Sullivan <jsrhbz@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

_______________________________________________
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®.