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

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



>>> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.