branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-winxpsp3
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradition
Hi,
When running HVM on Xen 4.6 with qemu in stubdom, I've found that
something goes wrong with disk frontend (at least that was visible
problem - a lot of read and write errors in stubdom log). But further
debugging (including -DGNT_DEBUG) leads to double gnttab_end_access in
netfront.
The stac
flight 65396 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65396/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs.
65114
Tests which a
flight 65392 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65392/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-freeb
On 12/05/2015 11:44 AM, Konrad Rzeszutek Wilk wrote:
Two issues exist with the SuperMicro EFI
(1) firmware EFI mis-mapping causing Xen PANIC on restart
Can you try 'reboot=acpi' ?
...
I.e., what combination of
/mapbs
efi=no-rs
reboot=acpi
All? It should be on the Xen command line
Variables that are input (IN) variables to EFI functions should be
marked as const. Just avoid potential problems of changing data that
shouldn't be changed.
Signed-off-by: Doug Goldstein
---
So I find myself constantly doing something similar to this when
troubleshooting EFI because I like to p
This run is configured for baseline tests only.
flight 38452 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38452/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl 21 guest-start/debian.repea
On December 5, 2015 1:32:23 PM EST, PGNet Dev wrote:
>On 12/05/2015 10:05 AM, Konrad Rzeszutek Wilk wrote:
>>> Two issues exist with the SuperMicro EFI
>>>
>>> (1) firmware EFI mis-mapping causing Xen PANIC on restart
>>
>> Can you try 'reboot=acpi' ?
>
>Instead of, or in addition to, efi=no-r
On 12/05/2015 10:05 AM, Konrad Rzeszutek Wilk wrote:
Two issues exist with the SuperMicro EFI
(1) firmware EFI mis-mapping causing Xen PANIC on restart
Can you try 'reboot=acpi' ?
Instead of, or in addition to, efi=no-rs?
I.e., what combination of
/mapbs
efi=no-rs
reboot=acpi
On Fri, Dec 04, 2015 at 03:16:15PM -0800, PGNet Dev wrote:
> I run Xen 4.6 Dom0 on an Opensuse Leap 42.1 server.
>
> Hardware is a SuperMicro X10SAT motherboard
> (http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm), with
> AMI v3 BIOS + "UEFI support"
>
> Two issues exist with t
flight 65393 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 60684
test-amd64
This run is configured for baseline tests only.
flight 38451 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38451/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 68312710615c3499341f3e300b0a3921dea5a39b
baseline version:
ovm
flight 65394 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR.
vs. 63340
test-amd64-i386-l
flight 38450 distros-debian-stretch real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38450/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-stretch-netboot-pvgrub 13 guest-saverestore fail never
pass
test-armhf-armhf-ar
flight 65378 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65378/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 65346
test-armhf-armhf-xl-rtds
flight 65386 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65386/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 68312710615c3499341f3e300b0a3921dea5a39b
baseline version:
ovmf 6e3e562c9d3f3737b718b5be9c9a64e9878
flight 65372 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs.
65114
test-armhf-ar
On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote:
> http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/
>
> I think that ought to give a baseline for the bisector to work with. I'll
> prod it to do so.
Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine
address
18 matches
Mail list logo