|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.0-testing test] 12190: regressions - FAIL
flight 12190 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12190/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12038 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 12038 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail like 12033 test-amd64-i386-xl-credit2 5 xen-boot fail like 12038 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass version targeted for testing: xen c62e9965b395 baseline version: xen bf902d6661e3 ------------------------------------------------------------ People who touched revisions under test: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Olaf Hering <olaf@xxxxxxxxx> Tim Deegan <tim@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 fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-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 test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 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: 21576:c62e9965b395 tag: tip user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 09:09:05 2012 +0000 passthrough: release assigned PCI devices earlier during domain shutdown At least with xend, where there's not even a tool stack side attempt to de-assign devices during domain shutdown, this allows immediate re- starts of a domain to work reliably. (There's no apparent reason why c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of domain destruction). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24888:71159fb049f2 xen-unstable date: Fri Feb 24 11:46:32 2012 +0100 changeset: 21575:26bf0e10596e user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 09:05:20 2012 +0000 x86/emulator: workaround for AMD erratum 573 The only cases where we might end up emulating fsincos (as any other x87 operations without memory operands) are - when a HVM guest is in real mode (not applicable on AMD) - between two half page table updates in PAE mode (unlikely, and not doing the emulation here does affect only performance, not correctness) - when a guest maliciously (or erroneously) modifies an (MMIO or page table update) instruction under emulation (unspecified behavior) Hence, in order to avoid the erratum to cause harm to the entire host, don't emulate fsincos on the affected AMD CPU families. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24417:1452fb248cd5 xen-unstable date: Fri Dec 16 15:45:40 2011 +0100 changeset: 21574:35ee60fe531f user: Keir Fraser <keir@xxxxxxx> date: Wed Mar 07 09:04:11 2012 +0000 Fix build after previous changeset. Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 21573:cf5751788c49 user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 08:56:28 2012 +0000 x86, amd: Disable GartTlbWlkErr when BIOS forgets it This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS forgets to do is (or is just too old). Letting these errors enabled can cause a sync-flood on the CPU causing a reboot. The AMD BKDG recommends disabling GART TLB Wlk Error completely. Based on a Linux patch from Joerg Roedel <joerg.roedel@xxxxxxx>; see e.g. https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24389:868d82faf651 xen-unstable date: Tue Dec 13 09:45:11 2011 +0100 changeset: 21572:fef96d880430 user: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> date: Wed Mar 07 08:55:57 2012 +0000 KEXEC: fix kexec_get_range_compat to fail vocally. Fail with -ERANGE rather than silently truncating 64bit values (a physical address and size) into 32bit integers for dom0 to consume. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Simplify the bitwise arithmetic a bit. Signed-off-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24358:9961a6d5356a xen-unstable date: Mon Dec 05 19:42:46 2011 +0000 changeset: 21571:32dbcf7567ea user: Tim Deegan <tim@xxxxxxx> date: Wed Mar 07 08:54:24 2012 +0000 x86/mm: Don't lose track of the log dirty bitmap hap_log_dirty_init unconditionally sets the top of the log dirty bitmap to INVALID_MFN. If there had been a bitmap allocated, it is then leaked, and the host crashes on an ASSERT when the domain is cleaned up. Signed-off-by: Tim Deegan <tim@xxxxxxx> Acked-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> Committed-by: Tim Deegan <tim@xxxxxxx> xen-unstable changeset: 24282:a06cda9fb25f xen-unstable date: Thu Dec 01 14:17:16 2011 +0000 changeset: 21570:e4c5791fb484 user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 08:53:56 2012 +0000 x86: small fixes to pcpu platform op handling XENPF_get_cpuinfo should init the flags output field rather than only modify it. XENPF_cpu_online must check for the input CPU number to be in range. XENPF_cpu_offline must also do that, and should also reject attempts to offline CPU 0 (this fails in cpu_down() too, but preventing this here appears more correct given that the code here calls continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down() would ever allow bringing down CPU 0 (and a distinct error code is easier to deal with when debugging issues). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24201:9c6bea25f712 xen-unstable date: Thu Nov 24 17:56:26 2011 +0100 changeset: 21569:0cfc22ad014b user: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> date: Wed Mar 07 08:51:51 2012 +0000 Trivial fix for rc val in hap track dirty vram Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24193:67d2ac426def xen-unstable date: Thu Nov 24 15:44:51 2011 +0000 changeset: 21568:d4c7fac37dcf user: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> date: Wed Mar 07 08:51:27 2012 +0000 x86/mm: change return code for log-dirty disabling Disabling log dirty mode in HAP always returns -EINVAL. Make it return the correct rc on success. Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> Signed-off-by: Tim Deegan <tim@xxxxxxx> Committed-by: Tim Deegan <tim@xxxxxxx> xen-unstable changeset: 24190:6b3d8250ee2c xen-unstable date: Thu Nov 24 15:20:57 2011 +0000 changeset: 21567:b5575d7e462e user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 08:50:55 2012 +0000 x86/vioapic: clear remote IRR when switching RTE to edge triggered mode Xen itself (as much as Linux) relies on this behavior, so it should also emulate it properly. Not doing so reportedly gets in the way of kexec inside a HVM guest. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Olaf Hering <olaf@xxxxxxxxx> xen-unstable changeset: 24168:9c350ab8d3ea xen-unstable date: Mon Nov 21 09:29:31 2011 +0100 Committed-by: Keir Fraser <keir@xxxxxxx> changeset: 21566:17992e40806a user: Jan Beulich <jbeulich@xxxxxxxx> date: Wed Mar 07 08:50:32 2012 +0000 x86/IO-APIC: refine EOI-ing of migrating level interrupts Rather than going through all IO-APICs and calling io_apic_eoi_vector() for the vector in question, just use eoi_IO_APIC_irq(). This in turn allows to eliminate quite a bit of other code. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> xen-unstable changeset: 24155:0d50e704834f xen-unstable date: Fri Nov 18 09:18:41 2011 +0100 changeset: 21565:bf902d6661e3 user: Ian Campbell <ian.campbell@xxxxxxxxxx> date: Thu Feb 23 10:41:33 2012 +0000 xen: add missing unlock from gnttab_get_version Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reported-by: Francisco Rocha <f.e.liberal-rocha@xxxxxxxxxxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 24871:66cc5b67e749 xen-unstable date: Thu Feb 23 09:59:35 2012 +0000 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |