|
[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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |