Am 18.05.2010 13:10, schrieb Peter Lieven:
> hi kevin,
>
> here is the backtrace of (hopefully) all threads:
>
> ^C
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0x7f39b72656f0 (LWP 10695)]
> 0x00007f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0
>
> (gdb) thread apply all bt
>
> Thread 2 (Thread 0x7f39b57b8950 (LWP 10698)):
> #0 0x00007f39b6c3eedb in read () from /lib/libpthread.so.0
> #1 0x000000000049e723 in qemu_laio_completion_cb (opaque=0x22b4010) at
> linux-aio.c:125
> #2 0x000000000049e8ad in laio_cancel (blockacb=0x22ba310) at
> linux-aio.c:184
I think it's stuck here in an endless loop:
while (laiocb->ret == -EINPROGRESS)
qemu_laio_completion_cb(laiocb->ctx);
Can you verify this by single-stepping one or two loop iterations? ret
and errno after the read call could be interesting, too.
We'll be stuck in an endless loop if the request doesn't complete, which
might well happen in your scenario. Not sure what the right thing to do
is. We probably need to fail the bdrv_aio_cancel to avoid blocking the
whole program, but I have no idea what device emulations should do on
that condition.
As long as we can't handle that condition correctly, leaving the hang in
place is probably the best option. Maybe add some sleep to avoid 100%
CPU consumption.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
