On Fri, Mar 23, 2012 at 11:32 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Fri, Mar 23, 2012 at 11:02 AM, Richard Davies <rich...@arachsys.com> wrote: >> Stefan Hajnoczi wrote: >>> > Hi. We were producing the IDE assert()s and deadlocks with linux kernels. >>> > Although I believe the same symptoms exist on windows, I haven't actually >>> > tested it myself. Typically they would show up in the 16-bit bootloader >>> > code, even before the 32-bit OS has started. >>> >>> Okay, that makes sense. Bootloaders and the BIOS may use the simplest >>> driver interface - which may be PIO in the case. I asked because the >>> IDE DMA code path should work with I/O throttling and Windows is known >>> for sometimes falling back to the PIO code path when some heuristics >>> trigger. >> >> Whilst the bootloader was the easiest place for us to replicate this >> deadlock, we have also seen it with running Linux VMs. >> >> Older Linux kernels (e.g. CentOS 5) will fall back to PIO mode on IDE >> devices if they experience storage timeouts (e.g. due to heavy contention of >> underlying storage from other VMs). >> >> Hence, the IO limits deadlock can lead to running Linux VMs locking up as >> well as just Windows and Linux bootloaders. > > Thanks for pointing out that Linux falls back too.
I have a prototype that converts hw/ide/core.c to asynchronous I/O functions. It still needs to be cleaned up and tested against Windows (Linux with libata.dma=0 is happy). Patches will be sent next week. Stefan
