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

Manuel Bouyer <bou...@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference

Xen-devel mailing list

Reply via email to