|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 8699: trouble: broken/fail/pass
flight 8699 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8699/ Failures and problems with tests :-( Tests which did not succeed and are blocking: test-amd64-i386-pair 3 host-install/src_host(3) broken test-amd64-i386-xl-win-vcpus1 3 host-install(3) broken test-amd64-i386-win-vcpus1 3 host-install(3) broken test-amd64-i386-win 3 host-install(3) broken test-i386-i386-xl-win 3 host-install(3) broken test-i386-i386-win 3 host-install(3) broken test-amd64-amd64-win 3 host-install(3) broken 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-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 0ddb4481f883 baseline version: xen fc2be6cb89ad ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxxxx> Jeremy Fitzhardinge <jeremy@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Olaf Hering <olaf@xxxxxxxxx> ------------------------------------------------------------ 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 pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 pass 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 broken test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-i386-win-vcpus1 broken test-amd64-i386-xl-win-vcpus1 broken test-amd64-amd64-win broken test-amd64-i386-win broken test-i386-i386-win broken test-amd64-amd64-xl-win fail test-i386-i386-xl-win broken ------------------------------------------------------------ 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: 23776:0ddb4481f883 tag: tip user: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> date: Fri Aug 19 09:58:22 2011 +0100 x86/KEXEC: disable hpet legacy broadcasts earlier On x2apic machines which booted in xapic mode, hpet_disable_legacy_broadcast() sends an event check IPI to all online processors. This leads to a protection fault as the genapic blindly pokes x2apic MSRs while the local apic is in xapic mode. One option is to change genapic when we shut down the local apic, but there are still problems with trying to IPI processors in the online processor map which are actually sitting in NMI loops Another option is to have each CPU take itself out of the online CPU map during the NMI shootdown. Realistically however, disabling hpet legacy broadcasts earlier in the kexec path is the easiest fix to the problem. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> changeset: 23775:9957bef3e7b4 user: Jeremy Fitzhardinge <jeremy@xxxxxxxx> date: Fri Aug 19 09:57:42 2011 +0100 mini-os: work around ld bug causing stupid CTOR count I'm seeing pvgrub crashing when running CTORs. It appears its because the magic in the linker script is generating junk. If I get ld to output a map, I see: .ctors 0x0000000000097000 0x18 0x0000000000097000 __CTOR_LIST__ = . 0x0000000000097000 0x4 LONG 0x25c04 (((__CTOR_END__ - __CTOR_LIST__) / 0x4) - 0x2) *(.ctors) .ctors 0x0000000000097004 0x10 /home/jeremy/hg/xen/unstable/stubdom/mini-os-x86_32-grub/mini-os.o 0x0000000000097014 0x4 LONG 0x0 0x0000000000097018 __CTOR_END__ = . In other words, somehow ((0x97018-0x97000) / 4) - 2 = 0x25c04 The specific crash is that the ctor loop tries to call the NULL sentinel. I'm seeing the same with the DTOR list. Avoid this by terminating the loop with the NULL sentinel, and get rid of the CTOR count entirely. From: Jeremy Fitzhardinge <jeremy@xxxxxxxx> Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23774:e35c5202625e user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Fri Aug 19 09:55:20 2011 +0100 x86-64/EFI: construct EDD data from device path protocol information In the absence of a BIOS to handle INT13 requests, this information must be constructed artificially instead when booted from EFI. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23773:dd90b59cb11c user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Fri Aug 19 09:54:53 2011 +0100 x86: trampoline cleanup To make future changes less error prone, and to slightly simplify a possible future conversion to a relocatable trampoline even for the multiboot path (pretty desirable given that we had to change the trampoline base a number of times to escape collisions with firmware placed data), - remove final uses of bootsym_phys() from trampoline.S, allowing the symbol to be undefined before including this file (to make sure no new references get added) - replace two easy to deal with uses of bootsym_phys() in head.S - remove an easy to replace reference to BOOT_TRAMPOLINE Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23772:29aeed4979a7 user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Fri Aug 19 09:54:26 2011 +0100 x86: make run-time part of trampoline relocatable In order to eliminate an initial hack in the EFI boot code (where memory for the trampoline was just "claimed" instead of properly allocated), the trampoline code must no longer make assumption on the address at which it would be located. For the time being, the fixed address is being retained for the traditional multiboot path. As an additional benefit (at least from my pov) it allows confining the visibility of the BOOT_TRAMPOLINE definition to just the boot code. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23771:fc2be6cb89ad user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Tue Aug 16 15:05:55 2011 +0100 x86: simplify (and fix) clear_IO_APIC{,_pin}() These are used during bootup and (emergency) shutdown only, and their only purpose is to get the actual IO-APIC's RTE(s) cleared. Consequently, only the "raw" accessors should be used (and the ones going through interrupt remapping code can be skipped), with the exception of determining the delivery mode: This one must always go through the interrupt remapping path, as in the VT-d case the actual IO-APIC's RTE will have the delivery mode always set to zero (which before possibly could have resulted in such an entry getting cleared in the "raw" pass, though I haven't observed this case in practice). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> ======================================== 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 |