Re: [xen-unstable test] 123379: regressions - FAIL

[Juergen Gross <jgross@suse.com>]

On 06/06/18 11:35, Jan Beulich wrote:
>>>> On 05.06.18 at 18:19, <ian.jackson@citrix.com> 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+0000: xc: Failed to get types for pfn batch (14 = Bad address): Internal error
>> 2018-05-30 22:12:49.483+0000: xc: Save failed (14 = Bad address): Internal error
>> 2018-05-30 22:12:49.648+0000: libxl-save-helper: complete r=-1: Bad address
>>
>> You can see similar messages in the other logfile:
>>
>> 2018-05-30 22:12:49.650+0000: libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving domain: domain responded to suspend request: Bad address
>>
>> All of these are reports of the same thing: xc_get_pfn_type_batch at
>> xc_sr_save.c:133 failed with EFAULT.  I'm afraid I don't know why.
>>
>> There is no corresponding message in the host's serial log nor the
>> dom0 kernel log.
> 
> I vaguely recall from the time when I had looked at the similar Windows
> migration issues that the guest is already in the process of being cleaned
> up when these occur. Commit 2dbe9c3cd2 ("x86/mm: silence a pointless
> warning") intentionally suppressed a log message here, and the
> immediately following debugging code (933f966bcd x86/mm: add
> temporary debugging code to get_page_from_gfn_p2m()) was reverted
> a little over a month later. This wasn't as a follow-up to another patch
> (fix), but following the discussion rooted at
> https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg00324.html

That was -ESRCH, not -EFAULT.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel