On 19/03/17 22:20, Alaric Snell-Pym wrote: > > Does any of that point to what the problem might be? How can I tell what > process holds the lock we're queuing up on? To my untrained eye, it > looks like some kind of filesystem lock, but I'm not familiar with > NetBSD's locks... > Hmmf, I just ran into it again (I've been rearranging some things on the server, so I keep needing to reboot VMs; and when this crops up, I need to reboot ALL the VMs because I need to reboot dom0!) I didn't have time to investigate further (and I've not yet gotten around to building a kernel with lock debugging in), but to reflect the value to me of getting this working,I'm going to offer a bounty of 0.1 bitcoins (worth 97EUR at time of writing; not a huge amount, but I'm just running my server for personal, friend, family, and open-source projects as a hobby myself, and have mouths to feed from my day job...) to the first person who fixes it! For the avoidance of doubt, I mean: + A patch that gets accepted into NetBSD. + A backport of said patch to 7.0.1/amd64/Xen 4.5.3 so I can actually use it! + With the patch in place, I can do a bunch of xen admin commands that would usually crash the thing (eg, restarting all of my domUs) and nothing untoward happens. So if your patch fixes this bug but introduces another, then it doesn't count! + If several people contribute towards fixing it, they agree how to split the bounty between themselves; if they can't, I'll either use my own judgement or donate the lot (or its cash equivalent) to the NetBSD foundation. + If anybody helps who would rather NOT get a bounty for ethical reasons, I'll pay their share to TNF instead. Thanks, ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/
Attachment:
signature.asc
Description: OpenPGP digital signature