Hello,
On Wed, Jun 03, 2020 at 11:33:52PM +, Agarwal, Anchal wrote:
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> On Tue, May 19, 2020 at 11:27:50PM
On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:
> During system shutdown quite often I hit infinite stream of errors like
> this:
>
> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
> (XEN) domain_crash called from io.c:178
>
> This is all running on Xen 4.13.0 (I think I've
On 04.06.2020 09:08, Jan Beulich wrote:
> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:
>> Then, we get the main issue:
>>
>> (XEN) d3v0 handle_pio port 0xb004 read 0x
>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
>> (XEN) domain_crash called from io.c:178
>>
>>
> -Original Message-
> From: Jan Beulich
> Sent: 04 June 2020 07:43
> To: Andrew Cooper
> Cc: Xen-devel ; Wei Liu ; Roger
> Pau Monné
> ; Juergen Gross ; Paul Durrant
> ; Dario Faggioli
>
> Subject: Re: [PATCH for-4.14] x86/shim: Fix defconfig selection and trim the
> build further
>
> -Original Message-
> From: Igor Druzhinin
> Sent: 03 June 2020 23:42
> To: xen-devel@lists.xenproject.org
> Cc: jbeul...@suse.com; andrew.coop...@citrix.com; w...@xen.org;
> roger@citrix.com;
> george.dun...@citrix.com; p...@xen.org; Igor Druzhinin
>
> Subject: [PATCH for-4.14 v3]
Hi,
> On 3 Jun 2020, at 19:09, Julien Grall wrote:
>
>
>
> On 03/06/2020 18:13, CodeWiz2280 wrote:
>> Hi Julien,
>
> Hello,
>
> In general, we avoid top post on xen-devel, instead we reply inline. I
> believe gmail should allow you to do it :).
>
>> The offset is already applied to the mem
> -Original Message-
> From: Xen-devel On Behalf Of Jürgen
> Groß
> Sent: 04 June 2020 06:03
> To: xen-devel@lists.xenproject.org
> Subject: Xenstore quota and driver domains
>
> A recent report on xen-users surfaced a problem we have with driver
> domains in medium sized or large config
On 04.06.20 10:07, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of Jürgen
Groß
Sent: 04 June 2020 06:03
To: xen-devel@lists.xenproject.org
Subject: Xenstore quota and driver domains
A recent report on xen-users surfaced a problem we have with driver
domains in mediu
Hi,
On 04/06/2020 01:15, Corey Minyard wrote:
On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote:
Touching the watchdog is required to be able to reboot the board.
The implementation is based on
drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.
Ah, I was looking at t
> -Original Message-
> From: Jürgen Groß
> Sent: 04 June 2020 09:11
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Subject: Re: Xenstore quota and driver domains
>
> On 04.06.20 10:07, Paul Durrant wrote:
> >> -Original Message-
> >> From: Xen-devel On Behalf Of
> >> Jürge
On 04.06.20 10:16, Paul Durrant wrote:
-Original Message-
From: Jürgen Groß
Sent: 04 June 2020 09:11
To: p...@xen.org; xen-devel@lists.xenproject.org
Subject: Re: Xenstore quota and driver domains
On 04.06.20 10:07, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Beh
(+ Andre)
Hi,
On 03/06/2020 23:31, Stefano Stabellini wrote:
Touching the watchdog is required to be able to reboot the board.
In general the preferred method is PSCI. Does it mean RPI 4 doesn't
support PSCI at all?
The implementation is based on
drivers/watchdog/bcm2835_wdt.c:__bcm2835_
On 04/06/2020 09:02, Bertrand Marquis wrote:
Hi,
Hi Bertrand,
On 3 Jun 2020, at 19:09, Julien Grall wrote:
On 03/06/2020 18:13, CodeWiz2280 wrote:
Hi Julien,
Hello,
In general, we avoid top post on xen-devel, instead we reply inline. I believe
gmail should allow you to do it :).
On 04/06/2020 09:48, Julien Grall wrote:
Hi,
> On 03/06/2020 23:31, Stefano Stabellini wrote:
>> Touching the watchdog is required to be able to reboot the board.
>
> In general the preferred method is PSCI. Does it mean RPI 4 doesn't
> support PSCI at all?
There is mainline Trusted Firmware (T
> On 4 Jun 2020, at 09:59, Julien Grall wrote:
>
>
>
> On 04/06/2020 09:02, Bertrand Marquis wrote:
>> Hi,
>
> Hi Bertrand,
>
>>> On 3 Jun 2020, at 19:09, Julien Grall wrote:
>>>
>>>
>>>
>>> On 03/06/2020 18:13, CodeWiz2280 wrote:
Hi Julien,
>>>
>>> Hello,
>>>
>>> In general, we
flight 150682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
On 04/06/2020 07:43, Jan Beulich wrote:
> On 03.06.2020 19:09, Andrew Cooper wrote:
>> Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be able to
>> deselect/configure.
>>
>> Enabling EXPERT now causes the request of the Credit1 scheduler to be
>> honoured
>> (rather than giving u
Hi,
On 04/06/2020 10:08, Bertrand Marquis wrote:
I would have thought that linux would have need some memory, even small in the
32bit space in order to boot.
Yes it needs some, but then they are switching to use the high memory
alias after the MMU has been switch on.
From my understanding,
flight 150680 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 2 hosts-allo
While the issue is more general, I noticed that asm-macros.i not getting
re-generated as needed. This was due to its .*.d file mentioning
asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at
it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds
dependency tracking f
On 04.06.2020 09:49, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 03 June 2020 23:42
>> To: xen-devel@lists.xenproject.org
>> Cc: jbeul...@suse.com; andrew.coop...@citrix.com; w...@xen.org;
>> roger@citrix.com;
>> george.dun...@citrix.com; p...@xen.org; I
> -Original Message-
> From: Jan Beulich
> Sent: 04 June 2020 11:34
> To: p...@xen.org
> Cc: 'Igor Druzhinin' ;
> xen-devel@lists.xenproject.org;
> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com;
> george.dun...@citrix.com
> Subject: Re: [PATCH for-4.14 v3] x86/svm: do not
flight 150687 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150687/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb78cfbec07eda45118b630a09b0af549b43a135
baseline version:
ovmf 68d720fd92bbdbbfae5ad
On 04/06/2020 11:50, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 04 June 2020 11:34
>> To: p...@xen.org
>> Cc: 'Igor Druzhinin' ;
>> xen-devel@lists.xenproject.org;
>> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com;
>> george.dun...@citrix.com
>
On 04/06/2020 08:08, Jan Beulich wrote:
> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:
>> Then, we get the main issue:
>>
>> (XEN) d3v0 handle_pio port 0xb004 read 0x
>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
>> (XEN) domain_crash called from io.c:178
>>
>>
flight 150674 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150674/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-i386-xl broken
test-amd64-i386-qemu
On 04/06/2020 11:22, Jan Beulich wrote:
> While the issue is more general, I noticed that asm-macros.i not getting
> re-generated as needed. This was due to its .*.d file mentioning
> asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at
> it also use -MQ to avoid the somewhat fr
On 04.06.2020 12:50, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 04 June 2020 11:34
>>
>> On 04.06.2020 09:49, Paul Durrant wrote:
-Original Message-
From: Igor Druzhinin
Sent: 03 June 2020 23:42
To: xen-devel@lists.xenproject.org
Cc: jbeul...@suse.com; andr
On 04.06.2020 13:35, Andrew Cooper wrote:
> On 04/06/2020 11:22, Jan Beulich wrote:
>> While the issue is more general, I noticed that asm-macros.i not getting
>> re-generated as needed. This was due to its .*.d file mentioning
>> asm-macros.o instead of asm-macros.i. Use -MQ here as well, and whil
> -Original Message-
> From: Jan Beulich
> Sent: 04 June 2020 12:47
> To: p...@xen.org
> Cc: 'Igor Druzhinin' ;
> xen-devel@lists.xenproject.org;
> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com;
> george.dun...@citrix.com
> Subject: Re: [PATCH for-4.14 v3] x86/svm: do not
On Thu, Jun 04, 2020 at 09:15:33AM +0100, Julien Grall wrote:
> Hi,
>
> On 04/06/2020 01:15, Corey Minyard wrote:
> > On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote:
> > > Touching the watchdog is required to be able to reboot the board.
> > >
> > > The implementation is based
On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote:
>
> Hi,
>
> On 04/06/2020 10:08, Bertrand Marquis wrote:
> > I would have thought that linux would have need some memory, even small in
> > the 32bit space in order to boot.
>
> Yes it needs some, but then they are switching to use the high memor
On 04/06/2020 12:59, Corey Minyard wrote:
On Thu, Jun 04, 2020 at 09:15:33AM +0100, Julien Grall wrote:
Hi,
On 04/06/2020 01:15, Corey Minyard wrote:
On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote:
Touching the watchdog is required to be able to reboot the board.
The i
On 04.06.2020 13:13, Andrew Cooper wrote:
> On 04/06/2020 08:08, Jan Beulich wrote:
>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:
>>> Then, we get the main issue:
>>>
>>> (XEN) d3v0 handle_pio port 0xb004 read 0x
>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
>>>
flight 150690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
This becomes part of the message but right now it is juse "".
So no functional change yet.
Signed-off-by: Ian Jackson
---
cs-bisection-step | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 35085e89..90e0601a 100755
--- a/cs-bisect
If we were halfway through bisecting, we treat the incident failure as
the basis failure. But our previous bisection results can count as
indications that things are really failing - we don't need to repro on
the very final commit.
Signed-off-by: Ian Jackson
---
cs-bisection-step | 3 ++-
1 fil
This will be used by the callback in a moment.
No functional change yet.
Signed-off-by: Ian Jackson
---
cs-bisection-step | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 478baa5b..35085e89 100755
--- a/cs-bisection-step
+++ b
This arranges for an ongoing bisection to be able to restart more
efficiently when the staging tip advances, and yet the test being
bisected still fails.
This will speed up the current osstest bisection of the smoke test
libvirt failure.
There are no code changes outside the bisector and the bise
This flag tells need_repro to look at parent commits of the indicated
rtuple node, as well as the node itself. We walk up the tree. If
there are multiple parents, we stop; likewise if we find any rtuple
which doesn't have the expected results.
Signed-off-by: Ian Jackson
---
cs-bisection-step |
Jim Fehlig writes ("Re: [libvirt test] 149773: regressions - FAIL"):
> On 4/24/20 3:53 AM, osstest service owner wrote:
> > flight 149773 libvirt real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/149773/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
Xen PCI passthrough support may not be available and thus the global
variable "has_igd_gfx_passthru" might be compiled out. Common code
should not access it in that case.
Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
xen-common.c so this patch instead move access to the
has_ig
xenconsoled doesn't automatically convert \n into \r\n, which causes test
output appear like this in a terminal:
[root@host ~]# xl create -c tests/selftest/test-pv64-selftest.cfg
Parsing config from tests/selftest/test-pv64-selftest.cfg
--- Xen Test Framework ---
On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote:
> On 04.06.2020 13:13, Andrew Cooper wrote:
> > On 04/06/2020 08:08, Jan Beulich wrote:
> >> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:
> >>> Then, we get the main issue:
> >>>
> >>> (XEN) d3v0 handle_pio port 0xb004 read
On 6/4/20 4:57 AM, Peng Fan wrote:
> Grall ;
>> Nataliya Korovkina
>> Subject: UEFI support in ARM DomUs
> We have made U-Boot run inside XEN DomU, but just only PV console part,
> not implement other frontend drivers currently. Would this help for your
> case if enable EFI in U-Boot?
Well, we ha
On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
> On 6/4/20 4:57 AM, Peng Fan wrote:
> > Grall ;
> >> Nataliya Korovkina
> >> Subject: UEFI support in ARM DomUs
> > We have made U-Boot run inside XEN DomU, but just only PV console part,
> > not implement other frontend drivers currently. Would
Hi,
On 04/06/2020 16:26, Oleksandr Andrushchenko wrote:
On 6/4/20 4:57 AM, Peng Fan wrote:
Grall ;
Nataliya Korovkina
Subject: UEFI support in ARM DomUs
We have made U-Boot run inside XEN DomU, but just only PV console part,
not implement other frontend drivers currently. Would this help for
On 6/4/20 6:51 AM, Ian Jackson wrote:
Jim Fehlig writes ("Re: [libvirt test] 149773: regressions - FAIL"):
On 4/24/20 3:53 AM, osstest service owner wrote:
flight 149773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149773/
Regressions :-(
Tests which did not succeed an
flight 150695 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
On 04/06/20 15:30, Anthony PERARD wrote:
> - fix build when Xen headers aren't available.
> By building stubs/xen-pt.c only when CONFIG_XEN=y
> (The alternative would be to move the prototypes used by the stub into
> xen.h, which doesn't depends on xen headers.)
Good catch.
On Thu, 4 Jun 2020, André Przywara wrote:
> On 04/06/2020 09:48, Julien Grall wrote:
>
> Hi,
>
> > On 03/06/2020 23:31, Stefano Stabellini wrote:
> >> Touching the watchdog is required to be able to reboot the board.
> >
> > In general the preferred method is PSCI. Does it mean RPI 4 doesn't
> >
On Thu, 4 Jun 2020, Julien Grall wrote:
> On 04/06/2020 16:26, Oleksandr Andrushchenko wrote:
> > On 6/4/20 4:57 AM, Peng Fan wrote:
> > > Grall ;
> > > > Nataliya Korovkina
> > > > Subject: UEFI support in ARM DomUs
> > > We have made U-Boot run inside XEN DomU, but just only PV console part,
> >
Hi,
On 04/06/2020 17:27, Stefano Stabellini wrote:
On Thu, 4 Jun 2020, Julien Grall wrote:
On 04/06/2020 16:26, Oleksandr Andrushchenko wrote:
On 6/4/20 4:57 AM, Peng Fan wrote:
Grall ;
Nataliya Korovkina
Subject: UEFI support in ARM DomUs
We have made U-Boot run inside XEN DomU, but just
Hi,
On 04/06/2020 17:24, Stefano Stabellini wrote:
On Thu, 4 Jun 2020, André Przywara wrote:
On 04/06/2020 09:48, Julien Grall wrote:
Hi,
On 03/06/2020 23:31, Stefano Stabellini wrote:
Touching the watchdog is required to be able to reboot the board.
In general the preferred method is PSC
On 04/06/2020 17:24, Stefano Stabellini wrote:
> On Thu, 4 Jun 2020, André Przywara wrote:
>> On 04/06/2020 09:48, Julien Grall wrote:
>>
>> Hi,
>>
>>> On 03/06/2020 23:31, Stefano Stabellini wrote:
Touching the watchdog is required to be able to reboot the board.
>>>
>>> In general the prefer
> On May 26, 2020, at 11:16 PM, George Dunlap wrote:
>
> The generated golang bindings (types.gen.go and helpers.gen.go) are
> left checked in so that they can be fetched from xenbits using the
> golang tooling. This means that they must be updated whenever
> libxl_types.idl (or other dependen
On Thu, 4 Jun 2020, André Przywara wrote:
> On 04/06/2020 17:24, Stefano Stabellini wrote:
> > On Thu, 4 Jun 2020, André Przywara wrote:
> >> On 04/06/2020 09:48, Julien Grall wrote:
> >>
> >> Hi,
> >>
> >>> On 03/06/2020 23:31, Stefano Stabellini wrote:
> Touching the watchdog is required to
On Thu, Jun 4, 2020 at 9:36 AM Julien Grall wrote:
>
> Hi,
>
> On 04/06/2020 17:24, Stefano Stabellini wrote:
> > On Thu, 4 Jun 2020, André Przywara wrote:
> >> On 04/06/2020 09:48, Julien Grall wrote:
> >>
> >> Hi,
> >>
> >>> On 03/06/2020 23:31, Stefano Stabellini wrote:
> Touching the watc
On Thu, Jun 4, 2020 at 8:31 AM Stefano Stabellini
wrote:
>
> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
> > On 6/4/20 4:57 AM, Peng Fan wrote:
> > > Grall ;
> > >> Nataliya Korovkina
> > >> Subject: UEFI support in ARM DomUs
> > > We have made U-Boot run inside XEN DomU, but just only PV
On Thu, 4 Jun 2020, Julien Grall wrote:
> Hi,
>
> On 04/06/2020 17:24, Stefano Stabellini wrote:
> > On Thu, 4 Jun 2020, André Przywara wrote:
> > > On 04/06/2020 09:48, Julien Grall wrote:
> > >
> > > Hi,
> > >
> > > > On 03/06/2020 23:31, Stefano Stabellini wrote:
> > > > > Touching the watchd
On Thu, 4 Jun 2020, Roman Shaposhnik wrote:
> On Thu, Jun 4, 2020 at 9:36 AM Julien Grall wrote:
> >
> > Hi,
> >
> > On 04/06/2020 17:24, Stefano Stabellini wrote:
> > > On Thu, 4 Jun 2020, André Przywara wrote:
> > >> On 04/06/2020 09:48, Julien Grall wrote:
> > >>
> > >> Hi,
> > >>
> > >>> On 03
> On Jun 2, 2020, at 11:50 PM, Roman Shaposhnik wrote:
>
> On Mon, Jun 1, 2020 at 9:12 AM Stefano Stabellini
> wrote:
>>
>> + George
>>
>> On Sun, 31 May 2020, Roman Shaposhnik wrote:
>>> Hi Julien!
>>>
>>> On Sun, May 31, 2020 at 3:24 PM Julien Grall
>>> wrote:
On Sun, 31 May
On 04/06/2020 17:46, Stefano Stabellini wrote:
> On Thu, 4 Jun 2020, André Przywara wrote:
>> On 04/06/2020 17:24, Stefano Stabellini wrote:
>>> On Thu, 4 Jun 2020, André Przywara wrote:
On 04/06/2020 09:48, Julien Grall wrote:
Hi,
> On 03/06/2020 23:31, Stefano Stabellini w
On 04/06/2020 17:46, Stefano Stabellini wrote:
On Thu, 4 Jun 2020, André Przywara wrote:
On 04/06/2020 17:24, Stefano Stabellini wrote:
On Thu, 4 Jun 2020, André Przywara wrote:
On 04/06/2020 09:48, Julien Grall wrote:
Hi,
On 03/06/2020 23:31, Stefano Stabellini wrote:
Touching the watc
On 6/4/20 1:46 PM, Boris Ostrovsky wrote:
> On 6/3/20 6:22 PM, Stefano Stabellini wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index 0a6cb67f0fc4..60ef07440905 100644
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -64,16 +64,16 @@ st
On 6/3/20 6:22 PM, Stefano Stabellini wrote:
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 0a6cb67f0fc4..60ef07440905 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct dev
Hi,
On 04/06/2020 13:07, CodeWiz2280 wrote:
On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote:
Hi,
On 04/06/2020 10:08, Bertrand Marquis wrote:
I would have thought that linux would have need some memory, even small in the
32bit space in order to boot.
Yes it needs some, but then they ar
> The simplest short-term way to fix this would be to remove the `go fmt` call
> from `gengotypes.py`. It’s actually relatively unusual for generated code to
> look pretty (or even be looked at). We could also consider adding in some
> “manual” formatting in gengotypes.py, like indentation, so
On 6/3/20 6:22 PM, Stefano Stabellini wrote:
> Hi all,
>
> This series is a collection of fixes to get Linux running on the RPi4 as
> dom0.
>
> Conceptually there are only two significant changes:
>
> - make sure not to call virt_to_page on vmalloc virt addresses (patch
> #1)
> - use phys_to_dma
flight 150694 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150694/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150631
test-amd64-i386-xl-qemuu-win7-amd64
flight 150702 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150702/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
During the Xen Community Call today, I was asked to forward information about
the Bareflank Community Call taking place next week.
The Zoom information for this call will be posted to this issue prior to the
meeting. Also, if you have something specific you would like to add to the
agenda, ple
The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a
while. commitish_version() pulls an old version of xen/Makefile out of
history, and uses the xenversion rule.
Currently, this fails with:
tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or
dire
On 04/06/2020 21:52, Andrew Cooper wrote:
> The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a
> while. commitish_version() pulls an old version of xen/Makefile out of
> history, and uses the xenversion rule.
>
> Currently, this fails with:
>
> tmp.support-matrix.xen.m
flight 150691 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 150663
Tests which did not
flight 150708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
On Thu, Jun 4, 2020 at 2:24 PM Julien Grall wrote:
>
> Hi,
>
> On 04/06/2020 13:07, CodeWiz2280 wrote:
> > On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 04/06/2020 10:08, Bertrand Marquis wrote:
> >>> I would have thought that linux would have need some memory, eve
flight 150712 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150712/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
flight 150709 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 150663
test-amd64-coresche
79 matches
Mail list logo
