Am 04.05.2010 15:42, schrieb Peter Lieven: > hi kevin, > > you did it *g* > > looks promising. applied this patched and was not able to reproduce yet :-) > > secure way to reproduce was to shut down all multipath paths, then > initiate i/o > in the vm (e.g. start an application). of course, everything hangs at > this point. > > after reenabling one path, vm crashed. now it seems to behave correctly and > just report an DMA timeout and continues normally afterwards. Great, I'm going to submit it as a proper patch then. Christoph, by now I'm pretty sure it's right, but can you have another look if this is correct, anyway? > can you imagine of any way preventing the vm to consume 100% cpu in > that waiting state? > my current approach is to run all vms with nice 1, which helped to keep the > machine responsible if all vms (in my test case 64 on a box) have hanging > i/o at the same time. I don't have anything particular in mind, but you could just attach gdb and get another backtrace while it consumes 100% CPU (you'll need to use "thread apply all bt" to catch everything). Then we should see where it's hanging. Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
