From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys6Tv-0008Ox-AO for qemu-devel@nongnu.org; Tue, 12 May 2015 05:28:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ys6Tq-0008Br-Al for qemu-devel@nongnu.org; Tue, 12 May 2015 05:28:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys6Tq-0008BO-5j for qemu-devel@nongnu.org; Tue, 12 May 2015 05:28:02 -0400 Message-ID: <5551AFB0.5020908@redhat.com> Date: Tue, 12 May 2015 09:45:52 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <18C7C30B-DC02-4CF1-8190-EFB063692272@gmail.com> <554F7124.8020900@redhat.com> <1D282622-B470-4916-BC6A-689EC83B1B42@gmail.com> In-Reply-To: <1D282622-B470-4916-BC6A-689EC83B1B42@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Help with deadlock when using sound List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: qemu-devel qemu-devel On 12/05/2015 00:43, Programmingkid wrote: >=20 > On May 10, 2015, at 10:54 AM, Paolo Bonzini wrote: >=20 >> >> >> On 06/05/2015 18:40, Programmingkid wrote: >>> When I try to use the pcspk sound hardware, QEMU freezes and uses >>> 100% of the cpu time. This is the command I use: >>> >>> qemu-system-i386 -cdrom -soundhw pcspk >>> >>> This looks like a deadlock situation because some unknown code called >>> qemu_mutex_lock(). Here is the stack trace at the freeze: >>> >>> (gdb) bt #0 0x00007fff824e2db6 in semaphore_wait_trap () #1 >>> 0x00007fff824e8417 in pthread_mutex_lock () #2 0x0000000100267199 in >>> qemu_mutex_lock (mutex=3D>> optimizations>) at util/qemu-thread-posix.c:73 #3 0x003c44016e95153b >>> in ?? () >>> >>> My host is Mac OS 10.6.8. My guest isn't really anything. I have used >>> Windows XP before but it isn't necessary to reproduce the problem. >>> >>> The ?? is what appears to be the problem. I can't even print >>> instructions at that address. Any ideas as to what is calling the >>> qemu_mutex_lock() function could help. The unknown code here is probably some place where gdb cannot find the frame pointer. Not a surprise if you are using a 5 year old debugger with (presumably) a newer compiler. >> Reproduced with a FreeDOS image from QEMU Advent Calendar. It locks u= p >> as soon as you type "beep". >> >> It works with the PulseAudio and ALSA backends, but it doesn't with th= e >> SDL backend, even on Linux. >> >> Also, it deadlocks even with KVM enabled. >> >> Paolo >=20 > OK, I see a pattern. SDL and CoreAudio both don't support audio input. = Both of them have this code: > .voice_size_in =3D 0 >=20 > Alsa and PulseAudio do support audio input and work. Coincidence? Yes. Locking in SDL is completely broken. sdl_callback runs with the SDL audio lock taken, but then it waits on a semaphore so you cannot call any other SDL audio function from the main thread. As soon as you do that, you get a deadlock. I'm strongly tempted to just remove the driver. On the other hand, CoreAudio seems to be okay. Can you try "thread apply all bt full" from gdb? Paolo