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
|
Home