Re: [Qemu-devel] dataplane: latest rc with selected patches hangs very often

[Paolo Bonzini <pbonzini@redhat.com>]

Il 11/07/2014 21:18, Andrey Korolyov ha scritto:
> On Fri, Jul 11, 2014 at 11:01 PM, Andrey Korolyov <andrey@xdel.ru> wrote:
>> Hello,
>>
>> is it worthy to re-test dp until next tag point? I am checking aio
>> with -rc1 and following picked commits (sorry for patchwork
>> references):
>>
>> stefanha:
>> 368191 New          [v3,1/4] virtio-blk: avoid dataplane
>> VirtIOBlockReq early free
>> 368787 New          [v3,2/4] dataplane: do not free VirtQueueElement
>> in vring_push()
>> 368360 New          [v3,3/4] virtio-blk: avoid g_slice_new0() for
>> VirtIOBlockReq and VirtQueueElement
>> 368863 New          [v3,4/4] virtio-blk: embed VirtQueueElement in
>> VirtIOBlockReq
>>
>> pbonzini:
>> 367551 New          [1/4] block: prefer aio_poll to qemu_aio_wait
>> 367553 New          [2/4] block: drop aio functions that operate on
>> the main AioContext
>> 367552 New          [3/4] test-aio: fix GSource-based timer test
>> 367554 New          [4/4] AioContext: speed up aio_notify
>>
>> Emulator itself stop responding in approximately ninety percent of
>> cases, e.g. it does not react to anything except SIGKILL. Windows VM
>> is able to read some bits before lockup happens because it draws an
>> initial logo.

Please try this patch:

http://article.gmane.org/gmane.comp.emulators.qemu/285674/raw

Paolo

>> hangs on vl.c:
>> (gdb) list
>> 2890        g_free(dummy);
>> 2891        if (err) {
>> 2892            qerror_report_err(err);
>> 2893            return -1;
>> 2894        }
>> 2895        return 0;
>> 2896    }
>> 2897
>> 2898    int main(int argc, char **argv, char **envp)
>> 2899    {
>> (gdb) next
>> Single stepping until exit from function __lll_lock_wait,
>> which has no line number information.
>>
>> cmdline follows:
>> if=none,id=drive-virtio-disk0,format=raw,cache=writeback,aio=native
>> ... -object iothread,id=blk0 -set device.virtio-disk0.config-wce=off
>> -set device.virtio-disk0.scsi=off -set
>> device.virtio-disk0.iothread=blk0
>
> Forgot to attach backtrace, though the issue and bt itself can be
> easily reproduced.
>