WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [xen-unstable test] 9077: regressions - FAIL

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [xen-unstable test] 9077: regressions - FAIL
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
Date: Sun, 25 Sep 2011 17:14:55 +0100
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Sun, 25 Sep 2011 09:16:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
flight 9077 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9077/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                   fail REGR. vs. 8995

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            5 xen-boot                     fail pass in 9073
 test-amd64-amd64-xl           5 xen-boot                     fail pass in 9075
 test-amd64-i386-xl-credit2    5 xen-boot                     fail pass in 9075
 test-i386-i386-xl-win         5 xen-boot                     fail pass in 9067
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                    fail pass in 9075
 test-i386-i386-win            5 xen-boot                     fail pass in 9071
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail pass in 9075
 test-amd64-amd64-xl-win       5 xen-boot                     fail pass in 9075
 test-amd64-amd64-xl-sedf      5 xen-boot             fail in 9073 pass in 9077
 test-amd64-amd64-win          5 xen-boot             fail in 9073 pass in 9077
 test-amd64-i386-win           5 xen-boot             fail in 9073 pass in 9077
 test-amd64-amd64-pv           5 xen-boot             fail in 9075 pass in 9077
 test-amd64-i386-xl-multivcpu  5 xen-boot             fail in 9075 pass in 9077
 test-amd64-i386-xl            5 xen-boot             fail in 9067 pass in 9077
 test-i386-i386-xl             5 xen-boot             fail in 9067 pass in 9077
 test-i386-i386-pv             5 xen-boot             fail in 9071 pass in 9077
 test-i386-i386-pair           8 xen-boot/dst_host    fail in 9071 pass in 9077
 test-i386-i386-pair           7 xen-boot/src_host    fail in 9071 pass in 9077

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop             fail in 9073 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop            fail in 9075 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check       fail in 9075 never pass
 test-i386-i386-xl-win        13 guest-stop             fail in 9067 never pass
 test-i386-i386-win           16 leak-check/check       fail in 9067 never pass

version targeted for testing:
 xen                  cc339ab1d917
baseline version:
 xen                  a422e2a4451e

------------------------------------------------------------
People who touched revisions under test:
  Andreas Herrmann <herrmann.der.user@xxxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Lasse Collin <lasse.collin@xxxxxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Thomas Renninger <trenn@xxxxxxx>
------------------------------------------------------------

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                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        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.

------------------------------------------------------------
changeset:   23872:cc339ab1d917
tag:         tip
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Thu Sep 22 18:37:06 2011 +0100
    
    tools: fix install of lomount
    
    $(BIN) went away in 23124:e3d4c34b14a3.
    
    Also there are no *.so, *.a or *.rpm built in here
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    
    
changeset:   23871:503ee256fecf
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:35:30 2011 +0100
    
    x86: ucode-amd: Don't warn when no ucode is available for a CPU revision
    
    This patch originally comes from the Linus mainline kernel (2.6.33),
    find below the patch details:
    
    From: Andreas Herrmann <herrmann.der.user@xxxxxxxxxxxxxx>
    
    There is no point in warning when there is no ucode available
    for a specific CPU revision. Currently the container-file, which
    provides the AMD ucode patches for OS load, contains only a few
    ucode patches.
    
    It's already clearly indicated by the printed patch_level
    whenever new ucode was available and an update happened. So the
    warning message is of no help but rather annoying on systems
    with many CPUs.
    
    Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23870:5c97b02f48fc
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:34:27 2011 +0100
    
    XZ: Fix incorrect XZ_BUF_ERROR
    
    From: Lasse Collin <lasse.collin@xxxxxxxxxxx>
    
    xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the
    following was true:
    
     - The caller knows how many bytes of output to expect and only
       provides
       that much output space.
    
     - When the last output bytes are decoded, the caller-provided input
       buffer ends right before the LZMA2 end of payload marker.  So LZMA2
       won't provide more output anymore, but it won't know it yet and
       thus
       won't return XZ_STREAM_END yet.
    
     - A BCJ filter is in use and it hasn't left any unfiltered bytes in
       the
       temp buffer.  This can happen with any BCJ filter, but in practice
       it's more likely with filters other than the x86 BCJ.
    
    This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408>
    where Squashfs thinks that a valid file system is corrupt.
    
    This also fixes a similar bug in single-call mode where the
    uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller
    provided no output space.  Many empty .xz files don't contain any
    blocks and thus don't trigger this bug.
    
    This also tweaks a closely related detail: xz_dec_bcj_run() could call
    xz_dec_lzma2_run() to decode into temp buffer when it was known to be
    useless.  This was harmless although it wasted a minuscule number of
    CPU cycles.
    
    Signed-off-by: Lasse Collin <lasse.collin@xxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23869:db1ea4b127cd
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:33:48 2011 +0100
    
    XZ decompressor: Fix decoding of empty LZMA2 streams
    
    From: Lasse Collin <lasse.collin@xxxxxxxxxxx>
    
    The old code considered valid empty LZMA2 streams to be corrupt.
    Note that a typical empty .xz file has no LZMA2 data at all,
    and thus most .xz files having no uncompressed data are handled
    correctly even without this fix.
    
    Signed-off-by: Lasse Collin <lasse.collin@xxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23868:28147fd781af
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:32:34 2011 +0100
    
    VT-d: fix off-by-one error in RMRR validation
    
    (base_addr,end_addr) is an inclusive range, and hence there shouldn't
    be a subtraction of 1 in the second invocation of page_is_ram_type().
    For RMRRs covering a single page that actually resulted in the
    immediately preceding page to get checked (which could have resulted
    in a false warning).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23867:571b6e90dfb4
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:31:44 2011 +0100
    
    VT-d: eliminate a mis-use of pcidevs_lock
    
    dma_pte_clear_one() shouldn't acquire this global lock for the purpose
    of processing a per-domain list. Furthermore the function a few lines
    earlier has a comment stating that acquiring pcidevs_lock isn't
    necessary here (whether that's really correct is another question).
    
    Use the domain's mappin_lock instead to protect the mapped_rmrrs list.
    Fold domain_rmrr_mapped() into its sole caller so that the otherwise
    implicit dependency on pcidevs_lock there becomes more obvious (see
    the comment there).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23866:47ec1d405af9
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:31:02 2011 +0100
    
    x86: IO-APIC code has no dependency on PCI
    
    The IRQ handling code requires pcidevs_lock to be held only for MSI
    interrupts.
    
    As the handling of which was now fully moved into msi.c (i.e. while
    applying fine without, the patch needs to be applied after the one
    titled "x86: split MSI IRQ chip"), io_apic.c now also doesn't need to
    include PCI headers anymore.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23865:d6e01c7853cf
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:29:19 2011 +0100
    
    PCI multi-seg: config space accessor adjustments
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23864:314b147d524d
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:28:38 2011 +0100
    
    PCI multi-seg: Pass-through adjustments
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23863:9e0259239822
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:28:03 2011 +0100
    
    PCI multi-seg: AMD-IOMMU specific adjustments
    
    There are two places here where it is entirely unclear to me where the
    necessary PCI segment number should be taken from (as IVMD descriptors
    don't have such, only IVHD ones do). AMD confirmed that for the time
    being it is acceptable to imply that only segment 0 exists.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23862:85418e168527
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:27:26 2011 +0100
    
    PCI multi-seg: VT-d specific adjustments
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23861:ec7c81fbe0de
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Sep 22 18:26:54 2011 +0100
    
    PCI multi-seg: adjust domctl interface
    
    Again, a couple of directly related functions at once get adjusted to
    account for the segment number.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
changeset:   23860:a422e2a4451e
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Sun Sep 18 00:26:52 2011 +0100
    
    x86: split MSI IRQ chip
    
    With the .end() accessor having become optional and noting that
    several of the accessors' behavior really depends on the result of
    msi_maskable_irq(), the splits the MSI IRQ chip type into two - one
    for the maskable ones, and the other for the (MSI only) non-maskable
    ones.
    
    At once the implementation of those methods gets moved from io_apic.c
    to msi.c.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    
========================================
commit cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Tue Jun 28 13:50:53 2011 +0100

    qemu-char.c: fix incorrect CONFIG_STUBDOM handling
    
    qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef]
    
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [xen-unstable test] 9077: regressions - FAIL, xen . org <=