Yongbok Kim <yongbok....@imgtec.com> writes: > On 01/03/2017 18:41, Thomas Huth wrote: >> On 01.03.2017 12:36, Alex Bennée wrote: >>> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> I got a make check failure on aarch64 host running a sparc64 test: >>>> >>>> >>>> TEST: tests/prom-env-test... (pid=13573) >>>> /sparc64/prom-env/sun4u: ** >>>> ERROR:/home/pm215/qemu/translate-common.c:34:tcg_handle_interrupt: >>>> assertion failed: (qemu_mutex_iothread_locked()) >> [...] >>> What will be useful for all these reports is the backtrace. Then it's >>> fairly simple to identify the thing triggering the interrupt and >>> identify the correct place for the locking. >> >> xtensa-softmmu crashes, too: >> > > > > Hi, > > mips softmmu crashes as well. > > ** > ERROR:/user/ygk/qemu/master/translate-common.c:34:tcg_handle_interrupt: > assertion failed: (qemu_mutex_iothread_locked())
So in my next series I'm going to downgrade these assertions to --enable-debug-tcg builds as otherwise its going to be a bit whack-a-mole frontends that have yet to be converted to be MTTCG capable. That said: > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffc986d700 (LWP 17296)] > 0x00007ffff5690635 in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install > bzip2-libs-1.0.5-7.el6_0.x86_64 glib2-2.28.8-4.el6.x86_64 > glibc-2.12-1.132.el6_5.4.x86_64 libgcc-4.4.7-11.el6.x86_64 > libstdc++-4.4.7-11.el6.x86_64 z > lib-1.2.3-29.el6.x86_64 > (gdb) where > #0 0x00007ffff5690635 in raise () from /lib64/libc.so.6 > #1 0x00007ffff5691e15 in abort () from /lib64/libc.so.6 > #2 0x00007ffff6416324 in g_assertion_message () from /lib64/libglib-2.0.so.0 > #3 0x00007ffff64168f0 in g_assertion_message_expr () from > /lib64/libglib-2.0.so.0 > #4 0x00007ffff7578a6f in tcg_handle_interrupt (cpu=0x7ffff8aba600, mask=2) > at /user/ygk/qemu/master/translate-common.c:34 > #5 0x00007ffff7659b2e in cpu_interrupt (cpu=0x7ffff8aba600, mask=2) at > /user/ygk/qemu/master/include/qom/cpu.h:801 > #6 0x00007ffff7659c5c in cpu_mips_irq_request (opaque=0x7ffff8aba600, > irq=7, level=1) at /user/ygk/qemu/master/hw/mips/mips_int.c:55 > #7 0x00007ffff77b9f3d in qemu_set_irq (irq=0x7ffff8aecc10, level=1) at > /user/ygk/qemu/master/hw/core/irq.c:45 > #8 0x00007ffff765937c in qemu_irq_raise (irq=0x7ffff8aecc10) at > /user/ygk/qemu/master/include/hw/irq.h:16 > #9 0x00007ffff76596ea in cpu_mips_timer_expire (env=0x7ffff8ac2890) at > /user/ygk/qemu/master/hw/mips/cputimer.c:73 > #10 0x00007ffff7659789 in cpu_mips_get_count (env=0x7ffff8ac2890) at > /user/ygk/qemu/master/hw/mips/cputimer.c:87 This is the division between cpu emulation and hw emulation where the BQL should be taken. So I think helper_mfc0_count and helper_rdhwr_cc should wrap their calls into the HW emulation with a BQL lock. > #11 0x00007ffff76d2056 in helper_mfc0_count (env=0x7ffff8ac2890) at > /user/ygk/qemu/master/target/mips/op_helper.c:830 > #12 0x00007fffd4e328b1 in code_gen_buffer () > #13 0x00007ffff75778f1 in cpu_tb_exec (cpu=0x7ffff8aba600, > itb=0x7fffcb37d9f0) at /user/ygk/qemu/master/cpu-exec.c:165 > #14 0x00007ffff75786ca in cpu_loop_exec_tb (cpu=0x7ffff8aba600, > tb=0x7fffcb37d9f0, last_tb=0x7fffc986caa0, tb_exit=0x7fffc986cab0, > sc=0x7fffc986ca80) at /user/ygk/qemu/master/cpu-exec.c:584 > #15 0x00007ffff757899a in cpu_exec (cpu=0x7ffff8aba600) at > /user/ygk/qemu/master/cpu-exec.c:686 > #16 0x00007ffff75b4495 in tcg_cpu_exec (cpu=0x7ffff8aba600) at > /user/ygk/qemu/master/cpus.c:1251 > #17 0x00007ffff75b4769 in qemu_tcg_rr_cpu_thread_fn (arg=0x7ffff8aba600) at > /user/ygk/qemu/master/cpus.c:1347 > #18 0x00007ffff59f99d1 in start_thread () from /lib64/libpthread.so.0 > #19 0x00007ffff574686d in clone () from /lib64/libc.so.6 > (gdb) > > Regards, > Yongbok -- Alex Bennée