|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 9077: regressions - FAIL
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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |