[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 05.06.18 at 18:19, <ian.jackson@xxxxxxxxxx> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.