flight 159338 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 159344 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159344/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 04085ec1ac05a362812e9b0c6b5a8713d7dc88ad
baseline version:
xen 6871
flight 159331 qemu-mainline real [real]
flight 159343 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159331/
http://logs.test-lab.xenproject.org/osstest/logs/159343/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 159333 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi Rahul,
On 11/02/2021 16:05, Rahul Singh wrote:
On 11 Feb 2021, at 1:52 pm, Julien Grall wrote:
On 11/02/2021 13:20, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 10 Feb 2021, at 7:52 pm, Julien Grall wrote:
On 10/02/2021 18:08, Rahul Singh wrote:
Hello Julien,
On 10 Feb 2021, a
From: Julien Grall
... are the same.
When the IOMMU is enabled and the domain is direct mapped (e.g. Dom0),
Xen will insert a 1:1 mapping for each grant mapping in the P2M to
allow DMA.
This works quite well when the grantee and granter and not the same
because the GFN in the P2M should not be
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-credit1
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tr
On 17/12/2020 15:37, Ash Wilding wrote:
Hi Julien,
Hi,
First of all, apologies for the very late reply.
Thanks for taking a look at the patches and providing feedback. I've seen your
other comments and will reply to those separately when I get a chance (maybe at
the weekend or over the Ch
flight 159335 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159335/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine 4 memdisk-try-append fail pass in 159315
test-armhf-armhf-xl-rtds 18
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
flight 159339 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-xl-x
On Samstag, 13. Februar 2021 19:21:56 CET Elliott Mitchell wrote:
> On Sat, Feb 13, 2021 at 04:36:24PM +0100, Maximilian Engelhardt wrote:
> > after a recent upgrade of one of our test systems to Debian Bullseye we
> > noticed an issue where on shutdown of a pvh vm the vm was not destroyed by
> > x
On Sun, Feb 14, 2021 at 11:45:47PM +0100, Maximilian Engelhardt wrote:
> On Samstag, 13. Februar 2021 19:21:56 CET Elliott Mitchell wrote:
> > On Sat, Feb 13, 2021 at 04:36:24PM +0100, Maximilian Engelhardt wrote:
> > > * The issue started with Debian kernel 5.8.3+1~exp1 running in the vm,
> > > De
flight 159346 qemu-mainline real [real]
flight 159361 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159346/
http://logs.test-lab.xenproject.org/osstest/logs/159361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 159349 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 14.02.21 22:34, Julien Grall wrote:
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event
On 1/30/21 6:59 PM, Dario Faggioli wrote:
On Fri, 2021-01-29 at 09:08 +0100, Anders Törnqvist wrote:
On 1/26/21 11:31 PM, Dario Faggioli wrote:
Thanks again for letting us see these logs.
Thanks for the attention to this :-)
Any ideas for how to solve it?
So, you're up for testing patches,
Hi,
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print() which contains a 3
seconds loop that calls process_pending_softirqs().
What would the potential problems be if that loop is radically shortened?
/Anders
19 matches
Mail list logo
