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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"