On 13/06/18 10:58, Andrew Cooper wrote:
> On 13/06/18 09:52, Juergen Gross wrote:
>> On 12/06/18 17:58, Juergen Gross wrote:
>>> On 08/06/18 12:12, Juergen Gross wrote:
On 07/06/18 13:30, Juergen Gross wrote:
> On 06/06/18 11:40, Juergen Gross wrote:
>> On 06/06/18 11:35, Jan Beulich w
On 13/06/18 09:52, Juergen Gross wrote:
> On 12/06/18 17:58, Juergen Gross wrote:
>> On 08/06/18 12:12, Juergen Gross wrote:
>>> On 07/06/18 13:30, Juergen Gross wrote:
On 06/06/18 11:40, Juergen Gross wrote:
> On 06/06/18 11:35, Jan Beulich wrote:
> On 05.06.18 at 18:19, wrote:
>
On 12/06/18 17:58, Juergen Gross wrote:
> On 08/06/18 12:12, Juergen Gross wrote:
>> On 07/06/18 13:30, Juergen Gross wrote:
>>> On 06/06/18 11:40, Juergen Gross wrote:
On 06/06/18 11:35, Jan Beulich wrote:
On 05.06.18 at 18:19, wrote:
test-amd64-i386-libvirt-qemuu-debianhv
On 13/06/18 09:21, Jan Beulich wrote:
On 13.06.18 at 08:50, wrote:
>> On 13/06/18 08:11, Jan Beulich wrote:
>>> Teaching the privcmd driver of all
>>> the indirections in hypercall request structures doesn't look very
>>> attractive (or maintainable). Or are you thinking of the caller
>>> pro
>>> On 13.06.18 at 08:50, wrote:
> On 13/06/18 08:11, Jan Beulich wrote:
>> Teaching the privcmd driver of all
>> the indirections in hypercall request structures doesn't look very
>> attractive (or maintainable). Or are you thinking of the caller
>> providing sideband information describing the b
On 13/06/18 08:11, Jan Beulich wrote:
On 12.06.18 at 17:58, wrote:
>> Trying to reproduce the problem in a limited test environment finally
>> worked: doing a loop of "xl save -c" produced the problem after 198
>> iterations.
>>
>> I have asked a SUSE engineer doing kernel memory management i
>>> On 12.06.18 at 17:58, wrote:
> Trying to reproduce the problem in a limited test environment finally
> worked: doing a loop of "xl save -c" produced the problem after 198
> iterations.
>
> I have asked a SUSE engineer doing kernel memory management if he
> could think of something. His idea i
On 08/06/18 12:12, Juergen Gross wrote:
> On 07/06/18 13:30, Juergen Gross wrote:
>> On 06/06/18 11:40, Juergen Gross wrote:
>>> On 06/06/18 11:35, Jan Beulich wrote:
>>> On 05.06.18 at 18:19, wrote:
>>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14
>>> guest-saverestore.2
>>
On 07/06/18 13:30, Juergen Gross wrote:
> On 06/06/18 11:40, Juergen Gross wrote:
>> On 06/06/18 11:35, Jan Beulich wrote:
>> On 05.06.18 at 18:19, wrote:
>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14
>> guest-saverestore.2
I thought I would reply again with the
On 06/06/18 11:40, Juergen Gross wrote:
> On 06/06/18 11:35, Jan Beulich wrote:
> On 05.06.18 at 18:19, wrote:
> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>>>
>>> I thought I would reply again with the key point from my earlier mail
>>> highlighted, and go
On 06/06/18 11:35, Jan Beulich wrote:
On 05.06.18 at 18:19, wrote:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>>
>> I thought I would reply again with the key point from my earlier mail
>> highlighted, and go a bit further. The first thing to go wrong in
>>> On 05.06.18 at 18:19, wrote:
>> > test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>
> I thought I would reply again with the key point from my earlier mail
> highlighted, and go a bit further. The first thing to go wrong in
> this was:
>
> 2018-05-30 22:12:49.320+
On 05/06/18 18:16, Ian Jackson wrote:
> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = Bad
> address): Internal error
This is worrying me.
The message is issued as a result of xc_get_pfn_type_batch() failing.
I see no other possibility for the failure with errno being
>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
I thought I would reply again with the key point from my earlier mail
highlighted, and go a bit further. The first thing to go wrong in
this was:
2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14
Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123379: regressions
- FAIL"):
> Before that there was:
>
> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14
> = Bad address): Internal error
This seems to be the only message about the root
On 01/06/18 10:10, Jan Beulich wrote:
On 31.05.18 at 11:14, wrote:
>> On 31/05/18 10:32, Juergen Gross wrote:
>>> On 31/05/18 08:00, osstest service owner wrote:
flight 123379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123379/
Regressions :-
>>> On 31.05.18 at 11:14, wrote:
> On 31/05/18 10:32, Juergen Gross wrote:
>> On 31/05/18 08:00, osstest service owner wrote:
>>> flight 123379 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/123379/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are
On 31/05/18 10:32, Juergen Gross wrote:
> On 31/05/18 08:00, osstest service owner wrote:
>> flight 123379 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/123379/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could no
On 31/05/18 08:00, osstest service owner wrote:
> flight 123379 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/123379/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-libvirt-qemuu-debi
flight 123379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail
REGR. vs. 123323
t
20 matches
Mail list logo