Am 27.10.2011 16:15, schrieb Kevin Wolf: > Am 27.10.2011 15:57, schrieb Stefan Hajnoczi: >> On Thu, Oct 27, 2011 at 03:26:23PM +0200, Kevin Wolf wrote: >>> Am 19.09.2011 16:37, schrieb Frediano Ziglio: >>>> Now that iothread is always compiled sending a signal seems only an >>>> additional step. This patch also avoid writing to two pipe (one from signal >>>> and one in qemu_service_io). >>>> >>>> Work with kvm enabled or disabled. strace output is more readable (less >>>> syscalls). >>>> >>>> Signed-off-by: Frediano Ziglio <fredd...@gmail.com> >>> >>> Something in this change has bad effects, in the sense that it seems to >>> break bdrv_read_em. >> >> How does it break bdrv_read_em? Are you seeing QEMU hung with 100% CPU >> utilization or deadlocked? > > Sorry, I should have been more detailed here. > > No, it's nothing obvious, it must be some subtle side effect. The result > of bdrv_read_em itself seems to be correct (return value and checksum of > the read buffer). > > However instead of booting into the DOS setup I only get an error > message "Kein System oder Laufwerksfehler" (don't know how it reads in > English DOS versions), which seems to be produced by the boot sector. > > I excluded all of the minor changes, so I'm sure that it's caused by the > switch from kill() to a direct call of the function that writes into the > pipe. > >> One interesting thing is that qemu_aio_wait() does not release the QEMU >> mutex, so we cannot write to a pipe with the mutex held and then spin >> waiting for the iothread to do work for us. >> >> Exactly how kill and qemu_notify_event() were different I'm not sure >> right now but it could be a factor. > > This would cause a hang, right? Then it isn't what I'm seeing.
While trying out some more things, I added some fprintfs to posix_aio_process_queue() and suddenly it also fails with the kill() version. So what has changed might really just be the timing, and it could be a race somewhere that has always (?) existed. Kevin
