Re: [Qemu-devel] [Bug 1706296] [NEW] Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())

[Peter Maydell]

On 25 July 2017 at 15:54, Alex Bennée <address@hidden> wrote:
>
> Thomas Huth <address@hidden> writes:
>
>> On 25.07.2017 11:30, Richard Jones wrote:
>>> ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion 
>>> failed: (!qemu_mutex_iothread_locked())
>>> Aborted (core dumped)
>>>
>>> The stack trace in the failing thread is:
>>>
>>> Thread 4 (Thread 0x7fffb0418700 (LWP 21979)):
>>> #0  0x00007fffdd89b64b in raise () at /lib64/libc.so.6
>>> #1  0x00007fffdd89d450 in abort () at /lib64/libc.so.6
>>> #2  0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0
>>> #3  0x00007fffdff8c7ea in g_assertion_message_expr ()
>>>     at /lib64/libglib-2.0.so.0
>>> #4  0x00005555557a7d00 in qemu_mutex_lock_iothread ()
>>>     at /home/rjones/d/qemu/cpus.c:1580
>>> #5  0x00005555557cb429 in io_writex (address@hidden, 
>>> iotlbentry=0x55555675b678,
>>>     address@hidden, address@hidden, address@hidden, retaddr=0, 
>>> address@hidden, address@hidden)
>>>     at /home/rjones/d/qemu/accel/tcg/cputlb.c:795
>>> #6  0x00005555557ce0f7 in io_writel (retaddr=93825011136120, 
>>> addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400)
>>>     at /home/rjones/d/qemu/softmmu_template.h:265
>>> #7  0x00005555557ce0f7 in helper_le_stl_mmu (address@hidden, 
>>> address@hidden, address@hidden, oi=<optimized out>, retaddr=93825011136120, 
>>> address@hidden) at /home/rjones/d/qemu/softmmu_template.h:300
>>> #8  0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, 
>>> ptr=2148532220, v=8, retaddr=0) at 
>>> /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182
>>> #9  0x0000555555882610 in do_interrupt_protected (is_hw=<optimized
>>> out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>,
>>> intno=<optimized out>, env=0x555556751400) at
>>> /home/rjones/d/qemu/target/i386/seg_helper.c:758
>
> Erm, what is happening here? I think the seg_helper is writing a stack
> frame but for some reason to io memory, triggering the BQL. This just
> seems weird.

Even if this happens because the guest is going haywire,
if the guest can provoke it then we need to handle it
without asserting...

thanks
-- PMM