Am 10.06.2015 um 04:12 schrieb Fam Zheng: > On Tue, 06/09 11:01, Christian Borntraeger wrote: >> Am 09.06.2015 um 04:28 schrieb Fam Zheng: >>> On Tue, 06/02 16:36, Christian Borntraeger wrote: >>>> Paolo, >>>> >>>> I bisected >>>> commit a0710f7995f914e3044e5899bd8ff6c43c62f916 >>>> Author: Paolo Bonzini <pbonz...@redhat.com> >>>> AuthorDate: Fri Feb 20 17:26:52 2015 +0100 >>>> Commit: Kevin Wolf <kw...@redhat.com> >>>> CommitDate: Tue Apr 28 15:36:08 2015 +0200 >>>> >>>> iothread: release iothread around aio_poll >>>> >>>> to cause a problem with hanging guests. >>>> >>>> Having many guests all with a kernel/ramdisk (via -kernel) and >>>> several null block devices will result in hangs. All hanging >>>> guests are in partition detection code waiting for an I/O to return >>>> so very early maybe even the first I/O. >>>> >>>> Reverting that commit "fixes" the hangs. >>>> Any ideas? >>> >>> Christian, I can't reproduce this on my x86 box with virtio-blk-pci. Do you >>> have a reproducer for x86? Or could you collect backtraces for all the >>> threads >>> in QEMU when it hangs? >>> >>> My long shot is that the main loop is blocked at aio_context_acquire(ctx), >>> while the iothread of that ctx is blocked at aio_poll(ctx, blocking). >> >> Here is a backtrace on s390. I need 2 or more disks, (one is not enough). > > It shows iothreads and main loop are all waiting for events, and the vcpu > threads are running guest code. > > It could be the requests being leaked. Do you see this problem with a regular > file based image or null-co driver? Maybe we're missing something about the > AioContext in block/null.c.
It seems to run with normal file based images. As soon as I have two or more null-aio devices it hangs pretty soon when doing a reboot loop. Christian
