Date: Tue, 16 Mar 2021 00:06:32 -0700 From: Brian Buhrow <buhrow@nfbcal.org> To: freebsd-xen@freebsd.org Subject: Re: Corruption in xenstored tdb file? Message-ID: <202103160706.12G76WLQ014062@nfbcal.org> In-Reply-To: <202103152124.12FLOeeg004469@nfbcal.org>
next in thread | previous in thread | raw e-mail | index | archive | help
hello. Following up on this further, it seems there may be a timing issue related to this after all. If I bring up a NetBSD-5.2 VM, the VM comes up without a problem and xennet0 works just as it should. I can do this time and time again without any trouble. However, if I bring up a NetBSD-99.77 (current as of January 28 2021), I get the behavior I described in the previous message. It's obviously some kind of race condition, since if I reboot the NetBSD-current VM several times, I can get it to come up with a network interface occasionally. However, not enough to make it usable. Also, since I wrote last, I updated to 12.2-release--p4, just to see if that made things better. It did not. I suspect, but don't know for sure, that the issue is that NetBSD-current is issuing commands on the xenbus faster than it did in NetBSD-5. If that's true, then I think the problem lies with FreeBSD, as, in my view, a VM guest shouldn't be able to trigger a race condition in the host side of the server, which is what appears to be happening here. Is there a way to get a trace of the communications between the domU's and the dom0 so I can see the differences between what NetBSD used to do and what it does today? -thanks -Brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202103160706.12G76WLQ014062>