| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home