On 01/06/18 10:10, Jan Beulich wrote: >>>> On 31.05.18 at 11:14, <jgr...@suse.com> 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 blocking, >>>> including tests which could not be run: >>>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 >> fail REGR. vs. 123323 >>> >>> AFAICS this seems to be the suspected Windows reboot again? >> >> Hmm, thinking more about it: xl save is done with the domU paused, >> so the guest rebooting concurrently is rather improbable. > > Not sure, considering e.g. > > libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving > domain: domain responded to suspend request: Bad address
That was at 2018-05-30 22:12:49.650+0000 Before that there was: 2018-05-30 22:12:49.320+0000: xc: Failed to get types for pfn batch (14 = Bad address): Internal error But looking at the messages issued some seconds before that I see some xenstore watch related messages in: http://logs.test-lab.xenproject.org/osstest/logs/123379/test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm/huxelrebe1---var-log-libvirt-libxl-libxl-driver.log which make me wonder whether the libxl watch handling is really correct: e.g. libxl__ev_xswatch_register() first registers the watch with xenstore and only then writes the data needed for processing the watch in the related structure. Could it be that the real suspend watch event was interpreted as a @releaseDomain event? Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
