[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL v2 for-2.7 02/15] qapi: change QmpInputVisitor to
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PULL v2 for-2.7 02/15] qapi: change QmpInputVisitor to QSLIST |
Date: |
Mon, 1 Aug 2016 11:13:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
On 27/07/2016 23:37, Laszlo Ersek wrote:
> It seems to me that QEMU deadlocks when it tries to emit the
> SPICE_DISCONNECTED event.
>
> (Note that I can't find "handle SPICE_DISCONNECTED" in the libvirtd log
> even in the successful case (i.e., when QEMU is built at the parent of
> 3d344c2aabb7).)
>
> Apparently audio_atexit() is triggered when QEMU is returning from
> main() -- or calling exit() --, which somehow results in QEMU trying to
> send a SPICE_DISCONNECTED event through the monitor? I guess the monitor
> has been long dead by then.
>
> Hmmm, this gives me an idea... What happens if I remove the following
> fragment from my domain XML?
>
> <sound model='ich6'>
> <address type='pci' domain='0x0000' bus='0x02' slot='0x07'
> function='0x0'/>
> </sound>
>
> Yeah, the hang disappears, shutdown works just fine. It's a spice audio
> bug after all, apparently. Sorry for reporting it in this thread! :) I'm
> adding Gerd to the address list.
>
> To reiterate: this patch (commit 3d344c2aabb7) does *not* cause the
> symptom, it only exposes an independent bug that causes the symptom.
> And, I can work around that for now, by removing sound devices.
I think the issue here is that the monitor is gone by the time
audio_atexit is called. It is caused by commit
c1111a24a3358ecd2f17be7c8b117cfe8bc5e5f8.
The fix is to move the audio_atexit call to main before
qemu_chr_cleanup, but I'm not sure how to deal with coreaudio_atexit.
Paolo
- Re: [Qemu-devel] [PULL v2 for-2.7 02/15] qapi: change QmpInputVisitor to QSLIST,
Paolo Bonzini <=