flight 8707 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8707/
Failures and problems with tests :-(
Tests which did not succeed and are blocking:
test-amd64-amd64-pair 3 host-install/src_host(3) broken in 8705
Tests which are failing intermittently (not blocking):
test-i386-i386-win 14 guest-start.2 fail pass in 8705
test-amd64-i386-xl-credit2 9 guest-start fail in 8705 pass in 8707
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-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-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-i386-i386-win 16 leak-check/check fail in 8705 never pass
version targeted for testing:
xen 7ba9270b127b
baseline version:
xen fc2be6cb89ad
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Christoph Egger <Christoph.Egger@amd.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@novell.com>
Jeremy Fitzhardinge <jeremy@goop.org>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
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 pass
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 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: 23778:7ba9270b127b
tag: tip
user: Tim Deegan <tim@xen.org>
date: Fri Aug 19 13:29:27 2011 +0100
nestedhvm: avoid endless loop of nested page faults
Stop sending IPIs to flush the nested-on-nested pagetable
after write operations. Instead flush the TLB only.
This fixes an endless loop of nested page faults after
adding an entry to the nested-on-nested pagetable.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 23777:e86b85dc6820
user: Tim Deegan <tim@xen.org>
date: Fri Aug 19 13:29:25 2011 +0100
nestedhvm: do not send IPIs twice
In p2m_get_nestedp2m() there is no need to send IPIs via
nestedhvm_vmcx_flushtlb() since p2m_flush_table() already
did that.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 23776:0ddb4481f883
user: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
changeset: 23775:9957bef3e7b4
user: Jeremy Fitzhardinge <jeremy@goop.org>
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@goop.org>
Signed-off-by: Keir Fraser <keir@xen.org>
changeset: 23774:e35c5202625e
user: Jan Beulich <jbeulich@novell.com>
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@novell.com>
changeset: 23773:dd90b59cb11c
user: Jan Beulich <jbeulich@novell.com>
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@novell.com>
changeset: 23772:29aeed4979a7
user: Jan Beulich <jbeulich@novell.com>
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@novell.com>
changeset: 23771:fc2be6cb89ad
user: Jan Beulich <jbeulich@novell.com>
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@novell.com>
=======================================commit
cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@eu.citrix.com>
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@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel