From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRQBx-0000bu-DD for qemu-devel@nongnu.org; Fri, 18 Nov 2011 10:17:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RRQBs-00041N-M3 for qemu-devel@nongnu.org; Fri, 18 Nov 2011 10:17:25 -0500 Received: from cantor2.suse.de ([195.135.220.15]:60182 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRQBs-00041B-D0 for qemu-devel@nongnu.org; Fri, 18 Nov 2011 10:17:20 -0500 Message-ID: <4EC676EB.70402@suse.de> Date: Fri, 18 Nov 2011 16:16:59 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <4EBB047A.7070104@suse.de> <4EBB9A47.1020405@suse.de> <4EBB9F1A.3020103@suse.de> <5CC0A375-CD95-472E-9688-846DF13D78A1@suse.de> <4EBBB5AE.1050803@suse.de> <4EBE4596.6010009@suse.de> In-Reply-To: <4EBE4596.6010009@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [TestDays] s390x emulation error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Developers Cc: Stefan Hajnoczi , Alexander Graf , Paolo Bonzini Am 12.11.2011 11:08, schrieb Andreas F=C3=A4rber: > Am 10.11.2011 12:29, schrieb Andreas F=C3=A4rber: >> Am 10.11.2011 11:32, schrieb Alexander Graf: >>> >>> On 10.11.2011, at 10:53, Andreas F=C3=A4rber wrote= : >>> >>>> Is there a known issue with running multiple instances of >>>> qemu-system-s390x? I got a hang on openSUSE 12.1 RC2 x86_64 host: >>>> >>>> 0x00007f0de7f698d4 in __lll_lock_wait () from /lib64/libpthread.so.0 >>>> (gdb) bt >>>> #0 0x00007f0de7f698d4 in __lll_lock_wait () from /lib64/libpthread.= so.0 >>>> #1 0x00007f0de7f651c5 in _L_lock_883 () from /lib64/libpthread.so.0 >>>> #2 0x00007f0de7f6501a in pthread_mutex_lock () from /lib64/libpthre= ad.so.0 >>>> #3 0x000000000048b4a9 in qemu_mutex_lock (mutex=3D) >>>> at /home/andreas/QEMU/qemu/qemu-thread-posix.c:54 >>>> #4 0x00000000004cd3df in qemu_mutex_lock_iothread () >>>> at /home/andreas/QEMU/qemu/cpus.c:843 >>>> #5 0x0000000000467580 in main_loop_wait (nonblocking=3D) >>>> at /home/andreas/QEMU/qemu/main-loop.c:459 >>>> #6 0x0000000000408984 in main_loop () at /home/andreas/QEMU/qemu/vl= .c:1481 >>>> #7 main (argc=3D, argv=3D, envp=3D) >>>> at /home/andreas/QEMU/qemu/vl.c:3474 >>>> >>>> Key presses didn't work, SDL window doesn't close, at 99.9% CPU. >>> >>> Huh? This is all generic code O_o. And no, it's not a known issue. >> >> Hm, reproducable by running >> >> $ s390x-softmmu/qemu-system-s390x >> >> (without arguments) on s390-next branch. >> >> I get compat_monitor0 console, but monitor or switching to real consol= e >> don't work and neither does closing. Same backtrace. >=20 > Same in my WIP qemu-system-rl78. >=20 > I found that the following main-loop change works around it for s390x > and rl78 but breaks x86_64 SeaBIOS boot. [...] >=20 > diff --git a/main-loop.c b/main-loop.c > index 60e9748..2ab5023 100644 > --- a/main-loop.c > +++ b/main-loop.c > @@ -460,7 +460,7 @@ int main_loop_wait(int nonblocking) > } >=20 > glib_select_poll(&rfds, &wfds, &xfds, (ret < 0)); > - qemu_iohandler_poll(&rfds, &wfds, &xfds, ret); > + qemu_iohandler_poll(&rfds, &wfds, &xfds, (ret < 0)); > #ifdef CONFIG_SLIRP > slirp_select_poll(&rfds, &wfds, &xfds, (ret < 0)); > #endif For the record: While s390x and rl78 showed an identical backtrace in gdb, the actual causes of the lockups turned out to be different: For rl78, tlb_fill() was not yet fully/correctly implemented, with no TB being generated for execution. We should probably error out rather than going into an infinite loop then. For s390x, the hang was workaroundable by memset()'ing not just the virtio memory region but the whole of RAM. Still investigating. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg