On Mon, May 15, 2017 at 11:18 -0400, Dan Cross wrote: > On Mon, May 15, 2017 at 11:01 AM, Mike Belopuhov <m...@belopuhov.com> wrote: > > > > Thanks for reporting this, however there's not enough info to follow > > up on this right now. What is clear is that your provider is using > > an ancient version of Xen that doesn't even support the callback > > vector interrupt delivery (the emulated xspd0 device is delivering > > all interrupts). We have developed code for Xen 4.5+ platforms and > > there was only some testing done by users on 3.x. So, in a way, you > > can consider Xen 3.x to not be officially supported at this point. > > > > That's unfortunate. Sadly, this is common across two different providers > (Panix and rootbsd.net). The latter, I'm sure, would at least be interested > in coordinating with you guys to get a fix. I'll open a trouble ticket with > them. > > Having said that, I've got a few questions: > > > > - Do you see other write failures as well? > > > > Yes. E.g, syslogd had a similar write failure before panic. >
Can you reproduce any of these write failures at will? What happens when you just send a signal to dump the core? You can test this by running "sleep 100", and then call "pkill -ABRT -lf sleep". > - Do you have swap enabled? (pstat -s) > > > Yes; a gig: > > : jaan; pstat -s > Device 1K-blocks Used Avail Capacity Priority > /dev/sd0b 1048249 0 1048249 0% 0 > : jaan; > Do you see swap being used under your load? > - Do you see crashes when bsd.mp is used instead of a single processor > > kernel (that's right, even on the single processor VM)? > > > > Yes; the panic happens whether using single- or multi-processor kernels. > Good, nothing has slipped through those cracks again.
