On Tue, Jun 12, 2018 at 01:57:35AM -0600, Jan Beulich wrote: > Let's focus on this scenario for now, as it is under better (timing) control > on the Xen side. Below is a first debugging patch which > - avoids the ASSERT() in question, instead triggering a printk(), in the hope > that the data logged and/or other ASSERT()s shed some additional light > on the situation > - logs cleanup activity (this is likely to be quite chatty, so be sure you set > up large enough internal buffers) > > Ideally, if no other ASSERT() triggers as a result of the bypassed one, > you'd try to catch more than a single instance of the problem, so we can > see a possible pattern (if there is one). A simplistic first XTF test I've > created based on your description of the L2 handling model in NetBSD > did not trigger the interesting printk(), but at least that way I've been > able to see that the domain cleanup logging produces useful data. > > At the very least I hope that with this we can derive whether the > root of the problem is at page table teardown / cleanup time, or with > management of live ones.
I applied this patch to 4.11rc4 (let's not change too much things at the same time) and rebooted my test host. Hopefully I'll have some data to report soon -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference -- _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xenproject.org/mailman/listinfo/xen-devel