| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] [xen-unstable test] 7621: regressions - FAIL
flight 7621 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/7621/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-rhel6hvm-intel 12 guest-localmigrate/x10 fail REGR. vs. 7607
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-xcpkern-i386-rhel6hvm-intel 14 guest-start.2 fail never pass
test-amd64-xcpkern-i386-rhel6hvm-amd 14 guest-start.2 fail never pass
test-amd64-i386-rhel6hvm-amd 12 guest-localmigrate/x10 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-xcpkern-i386-xl-win 13 guest-stop fail never pass
test-amd64-xcpkern-i386-win 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-xcpkern-i386-win 16 leak-check/check fail never pass
version targeted for testing:
xen 7b4a45a4075d
baseline version:
xen 23c068b10923
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Jan Beulich <jbeulich@xxxxxxxxxx>
Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Keir Fraser <keir@xxxxxxx>
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
------------------------------------------------------------
jobs:
build-i386-xcpkern pass
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-xcpkern-i386-xl pass
test-i386-xcpkern-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-xcpkern-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 pass
test-amd64-xcpkern-i386-xl-credit2 pass
test-amd64-i386-rhel6hvm-intel fail
test-amd64-xcpkern-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-xcpkern-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-xcpkern-i386-pair pass
test-i386-xcpkern-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-xcpkern-i386-pv pass
test-i386-xcpkern-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-xcpkern-i386-win fail
test-i386-xcpkern-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-xcpkern-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: 23552:7b4a45a4075d
tag: tip
user: Keir Fraser <keir@xxxxxxx>
date: Thu Jun 16 16:57:22 2011 +0100
tasklets: Switch a few tasklets to run in softirq context.
There are a couple of others which may also be safe. I've converted
only the most obvious one.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23551:3ff057cbb16b
user: Keir Fraser <keir@xxxxxxx>
date: Thu Jun 16 16:56:31 2011 +0100
tasklets: Allow tasklets to be created that run in softirq context.
Where this is safe, it can reduce latency and cpu overhead compared
with scheduling the idle vcpu to perform the same tasklet work.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23550:fb5f0febeddc
user: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
date: Thu Jun 16 16:17:35 2011 +0100
pv-on-hvm: hvm_domain_use_pirq return positive no matter if the evtchn is
bound
This patch fixes PV on HVM interrupt remapping with recent Linux
kernels and upstream qemu. hvm_domain_use_pirq should return positive
even if the evtchn is not currently bound. If it doesn't assert_irq
ends up injecting legacy interrupts even after the guest disabled the
irq.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
changeset: 23549:a574bf2f5059
user: Keir Fraser <keir@xxxxxxx>
date: Thu Jun 16 16:14:51 2011 +0100
Protect xen/stdarg.h for multiple inclusion.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23548:de67ab2d5321
user: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
date: Thu Jun 16 16:12:20 2011 +0100
Use same data array for INTEL and AMD cpufreq handling
The AMD and INTEL specific parts of cpufreq handling used different
per-cpu data structures with nearly identical semantics. Fold the two
structures into one by adding a generic architecture data item.
Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
changeset: 23547:b5955b9fc26c
user: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
date: Thu Jun 16 16:11:13 2011 +0100
KEXEC: prevent panic on the kexec path when talking to the DMAR
hardware
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
changeset: 23546:d25f2c114ace
user: Keir Fraser <keir@xxxxxxx>
date: Wed Jun 15 20:33:58 2011 +0100
x86_emulate: Fix decode of FUCOMIP %stN.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23545:e462d2e76734
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Wed Jun 15 20:25:13 2011 +0100
x86: sync thermal monitor LVT handling with Linux
As of 2.6.33, Linux checks that the thermal monitor LVT isn't set to
SMI delivery mode on just the value read on the boot CPU. As of 2.6.39
it additionally avoids writing back the saved value when its delivery
mode is FIXED (as this can cause APIC errors).
Changes done here that aren't in Linux are
- write back the boot CPU value also if delivery mode is FIXED, but
there is also a valid vector
- print the messages when bailing out only once (on the boot CPU)
- when doing the final (enabling) write to the LVT, don't re-read the
old value from the APIC, as we have it in a local variable already
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23544:644838dc1322
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Wed Jun 15 20:24:41 2011 +0100
x86/apic: check maxlvt before accessing certain LVT fields
This follows Linux, including in not checking maxlvt for certain
accesses to APIC_LVTERR.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23543:a8edfacd4b5e
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Wed Jun 15 20:24:09 2011 +0100
x86-64: fix incorrect assertion in __maddr_to_virt()
When memory map sparseness reduction is in use, machine address ranges
can't validly be compared directly against the total size of the
direct mapping range.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23542:23c068b10923
user: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
date: Wed Jun 15 16:16:41 2011 +0100
KEXEC: correctly revert x2apic state when kexecing
Introduce the boolean variable 'kexecing' which indicates to functions
whether we are on the kexec path or not. This is used by
disable_local_APIC() to try and revert the APIC mode back to how it
was found on boot.
We also need some fudging of the x2apic_enabled variable. It is used
in multiple places over the codebase to mean multiple things,
including:
What did the user specifify on the command line?
Did the BIOS boot me in x2apic mode?
Is the BSP Local APIC in x2apic mode?
What mode is my Local APIC in?
Therefore, set it up to prevent a protection fault when disabling the
IOAPICs. (In this case, it is used in the "What mode is my Local APIC
in?" case, so the processor doesnt suffer a protection fault because
of trying to use x2apic MSRs when it should be using xapic MMIO)
Finally, make sure that interrupts are disabled when jumping into the
purgatory code. It would be bad to service interrupts in the Xen
context when the next kernel is booting.
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
| <Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] [xen-unstable test] 7621: regressions - FAIL,
xen . org <=
|
|
|
| |
|
Home