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

Re: [Xen-devel] [xen-unstable test] 9005: regressions - FAIL

To: <ian.jackson@xxxxxxxxxxxxx>,<xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-unstable test] 9005: regressions - FAIL
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Fri, 23 Sep 2011 08:04:24 +0100
Cc:
Delivery-date: Fri, 23 Sep 2011 00:06:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <osstest-9005-mainreport@xxxxxxx>
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>
References: <osstest-9005-mainreport@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 23.09.11 at 05:57, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 9005 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9005/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-rhel6hvm-amd  5 xen-boot                   fail REGR. vs. 
> 8995
>  test-i386-i386-pv             5 xen-boot                   fail REGR. vs. 
> 8995
>  test-amd64-amd64-xl-win       5 xen-boot                   fail REGR. vs. 
> 8995

These must be caused by 23863:9e0259239822, failing only on AMD
IOMMU capable systems; looking into it.

Jan

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl           5 xen-boot                     fail pass in 
> 9000
>  test-amd64-i386-pv            5 xen-boot                     fail pass in 
> 9000
>  test-amd64-i386-xl-credit2    5 xen-boot                     fail pass in 
> 9000
>  test-amd64-i386-pair          8 xen-boot/dst_host            fail pass in 
> 9000
>  test-amd64-i386-pair          7 xen-boot/src_host            fail pass in 
> 9000
>  test-amd64-amd64-pair         8 xen-boot/dst_host            fail pass in 
> 9000
>  test-amd64-amd64-pair         7 xen-boot/src_host            fail pass in 
> 9000
>  test-amd64-amd64-pv           5 xen-boot             fail in 9000 pass in 
> 9005
>  test-amd64-i386-xl-multivcpu  5 xen-boot             fail in 9000 pass in 
> 9005
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot            fail in 9000 pass in 
> 9005
>  test-i386-i386-win            5 xen-boot             fail in 9000 pass in 
> 9005
>  test-i386-i386-pair           8 xen-boot/dst_host    fail in 9000 pass in 
> 9005
>  test-i386-i386-pair           7 xen-boot/src_host    fail in 9000 pass in 
> 9005
>  test-amd64-i386-win-vcpus1    5 xen-boot             fail in 9000 pass in 
> 9005
> 
> 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-i386-xl-win-vcpus1 13 guest-stop                   fail  never 
> pass
>  test-i386-i386-win           16 leak-check/check             fail   never 
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never 
> pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never 
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never 
> pass
>  test-amd64-i386-win          16 leak-check/check             fail   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                                        fail    
>  test-amd64-i386-pair                                         fail    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           fail    
>  test-i386-i386-pv                                            fail    
>  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 



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

<Prev in Thread] Current Thread [Next in Thread>