Date: Thu, 29 Mar 2012 21:48:30 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Mark Felder <feld@feld.me> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, Joe Greco <jgreco@ns.sol.net> Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash Message-ID: <CAJ-VmokU23NNnFd6FY4nr-_FRBfSftYgebJNroxOwrfxtCzepQ@mail.gmail.com> In-Reply-To: <op.wbykhgrl34t2sn@cr48.lan> References: <201203300027.q2U0RVZS085304@aurora.sol.net> <op.wbykhgrl34t2sn@cr48.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Again, it's starting to sound like an interrupt handling issue which may or may not be limited to the storage device. You'll have to engage someone who knows those device drivers and likely have them add some debugging to the driver which can be easily flipped on (via binaries in a ramdisk - very important if you can't run sysctl because your disk IO has locked up!) to see what the current state of things. It's likely that the BSD mpt(4) and other storage drivers, and/or our interrupt handling code, is just slightly different enough to confuse the snot out of VMWare. I'd first look at the obvious - (eg, if you've just stopped receiving interrupts, even if new IO is scheduled). I'd also ask VMware if they have any tools that they can run on a VM to get the state of the internal emulated driver. For example, register dumps of the device to see if it's in a hung state, register dumps of the PIC/APIC to see what state they're in, etc. Maybe pull in someone like ixsystems and see if they can help debug this kind of stuff? If you're paying vmware for support, you could pull them into things with ixsystems and see if the two of them can help you sort this out? Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokU23NNnFd6FY4nr-_FRBfSftYgebJNroxOwrfxtCzepQ>