From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [xen-unstable test] 9005: regressions - FAIL Date: Fri, 23 Sep 2011 08:04:24 +0100 Message-ID: <4E7C4B9902000078000577B4@nat28.tlf.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: ian.jackson@eu.citrix.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On 23.09.11 at 05:57, xen.org wrote: > flight 9005 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/9005/=20 >=20 > Regressions :-( >=20 > 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 >=20 > 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 >=20 > version targeted for testing: > xen cc339ab1d917 > baseline version: > xen a422e2a4451e >=20 > ------------------------------------------------------------ > People who touched revisions under test: > Andreas Herrmann > Ian Campbell > Ian Jackson > Jan Beulich > Lasse Collin > Olaf Hering > Thomas Renninger > ------------------------------------------------------------ >=20 > jobs: > build-amd64 pass =20 > build-i386 pass =20 > build-amd64-oldkern pass =20 > build-i386-oldkern pass =20 > build-amd64-pvops pass =20 > build-i386-pvops pass =20 > test-amd64-amd64-xl fail =20 > test-amd64-i386-xl pass =20 > test-i386-i386-xl pass =20 > test-amd64-i386-rhel6hvm-amd fail =20 > test-amd64-i386-xl-credit2 fail =20 > test-amd64-amd64-xl-pcipt-intel fail =20 > test-amd64-i386-rhel6hvm-intel fail =20 > test-amd64-i386-xl-multivcpu pass =20 > test-amd64-amd64-pair fail =20 > test-amd64-i386-pair fail =20 > test-i386-i386-pair pass =20 > test-amd64-amd64-pv pass =20 > test-amd64-i386-pv fail =20 > test-i386-i386-pv fail =20 > test-amd64-amd64-xl-sedf pass =20 > test-amd64-i386-win-vcpus1 fail =20 > test-amd64-i386-xl-win-vcpus1 fail =20 > test-amd64-amd64-win fail =20 > test-amd64-i386-win fail =20 > test-i386-i386-win fail =20 > test-amd64-amd64-xl-win fail =20 > test-i386-i386-xl-win fail =20 >=20 >=20 > ------------------------------------------------------------ > sg-report-flight on woking.cam.xci-test.com > logs: /home/xc_osstest/logs > images: /home/xc_osstest/images >=20 > Logs, config files, etc. are available at > http://www.chiark.greenend.org.uk/~xensrcts/logs=20 >=20 > Test harness code can be found at > http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3Dsummary=20 >=20 >=20 > Not pushing. >=20 > ------------------------------------------------------------ > changeset: 23872:cc339ab1d917 > tag: tip > user: Ian Campbell > date: Thu Sep 22 18:37:06 2011 +0100 > =20 > tools: fix install of lomount > =20 > $(BIN) went away in 23124:e3d4c34b14a3. > =20 > Also there are no *.so, *.a or *.rpm built in here > =20 > Signed-off-by: Ian Campbell > =20 > =20 > changeset: 23871:503ee256fecf > user: Jan Beulich > date: Thu Sep 22 18:35:30 2011 +0100 > =20 > x86: ucode-amd: Don't warn when no ucode is available for a CPU = revision > =20 > This patch originally comes from the Linus mainline kernel (2.6.33), > find below the patch details: > =20 > From: Andreas Herrmann > =20 > 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. > =20 > 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. > =20 > Signed-off-by: Thomas Renninger > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23870:5c97b02f48fc > user: Jan Beulich > date: Thu Sep 22 18:34:27 2011 +0100 > =20 > XZ: Fix incorrect XZ_BUF_ERROR > =20 > From: Lasse Collin > =20 > xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the > following was true: > =20 > - The caller knows how many bytes of output to expect and only > provides > that much output space. > =20 > - 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. > =20 > - 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. > =20 > This fixes > where Squashfs thinks that a valid file system is corrupt. > =20 > 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. > =20 > 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. > =20 > Signed-off-by: Lasse Collin > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23869:db1ea4b127cd > user: Jan Beulich > date: Thu Sep 22 18:33:48 2011 +0100 > =20 > XZ decompressor: Fix decoding of empty LZMA2 streams > =20 > From: Lasse Collin > =20 > 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. > =20 > Signed-off-by: Lasse Collin > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23868:28147fd781af > user: Jan Beulich > date: Thu Sep 22 18:32:34 2011 +0100 > =20 > VT-d: fix off-by-one error in RMRR validation > =20 > (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). > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23867:571b6e90dfb4 > user: Jan Beulich > date: Thu Sep 22 18:31:44 2011 +0100 > =20 > VT-d: eliminate a mis-use of pcidevs_lock > =20 > 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). > =20 > 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). > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23866:47ec1d405af9 > user: Jan Beulich > date: Thu Sep 22 18:31:02 2011 +0100 > =20 > x86: IO-APIC code has no dependency on PCI > =20 > The IRQ handling code requires pcidevs_lock to be held only for MSI > interrupts. > =20 > 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. > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23865:d6e01c7853cf > user: Jan Beulich > date: Thu Sep 22 18:29:19 2011 +0100 > =20 > PCI multi-seg: config space accessor adjustments > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23864:314b147d524d > user: Jan Beulich > date: Thu Sep 22 18:28:38 2011 +0100 > =20 > PCI multi-seg: Pass-through adjustments > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23863:9e0259239822 > user: Jan Beulich > date: Thu Sep 22 18:28:03 2011 +0100 > =20 > PCI multi-seg: AMD-IOMMU specific adjustments > =20 > There are two places here where it is entirely unclear to me where = the > necessary PCI segment number should be taken from (as IVMD descriptor= s > 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. > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23862:85418e168527 > user: Jan Beulich > date: Thu Sep 22 18:27:26 2011 +0100 > =20 > PCI multi-seg: VT-d specific adjustments > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23861:ec7c81fbe0de > user: Jan Beulich > date: Thu Sep 22 18:26:54 2011 +0100 > =20 > PCI multi-seg: adjust domctl interface > =20 > Again, a couple of directly related functions at once get adjusted = to > account for the segment number. > =20 > Signed-off-by: Jan Beulich > =20 > =20 > changeset: 23860:a422e2a4451e > user: Jan Beulich > date: Sun Sep 18 00:26:52 2011 +0100 > =20 > x86: split MSI IRQ chip > =20 > 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. > =20 > At once the implementation of those methods gets moved from = io_apic.c > to msi.c. > =20 > Signed-off-by: Jan Beulich > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > commit cd776ee9408ff127f934a707c1a339ee600bc127 > Author: Ian Jackson > Date: Tue Jun 28 13:50:53 2011 +0100 >=20 > qemu-char.c: fix incorrect CONFIG_STUBDOM handling > =20 > qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined = [-Wundef] > =20 > Signed-off-by: Olaf Hering > Acked-by: Ian Jackson >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel=20