Re: port-evbarm/54224: panic: lock error: Mutex: mutex_vector_enter,552: locking against myself

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 22/05/2019 22:10, perlhaq%free.fr@localhost wrote:
[snip]

> Mutex error: mutex_vector_enter,552: locking against myself
>
> lock address : 0x000000009ce091ec
> current cpu  :                  0
> current lwp  : 0x00000000a60e6980
> owner field  : 0x00000000a60e6980 wait/spin:                0/0
>
> panic: lock error: Mutex: mutex_vector_enter,552: locking against myself: lock 0x9ce091ec cpu 0 lwp 0xa60e6980
> cpu0: Begin traceback...
> 0x9673dbf4: netbsd:db_panic+0xc
> 0x9673dc0c: netbsd:vpanic+0x1a4
> 0x9673dc24: netbsd:snprintf
> 0x9673dc5c: netbsd:lockdebug_abort+0x70
> 0x9673dc74: netbsd:mutex_abort+0x30
> 0x9673dcd4: netbsd:mutex_enter+0x388
> 0x9673dd14: netbsd:pmap_fault_fixup+0x40
> 0x9673dd9c: netbsd:data_abort_handler+0x164 > 0x9673de14: netbsd:address_exception_entry+0x5c

uvm_fault_internal should never fault (address_exception_entry) itself -
this is why you trigger the KASSERT.  To debug this I'd turn on DDB and
UVMHIST in your kernel and when the panic triggers grab the output with
'show kernhist'

> 0x9673df44: netbsd:uvm_fault_internal+0x32c
> 0x9673dfac:

Working out where this address in the code is will be useful to.  You
can do this with addr2line -e netbsd.gdb -f <address>, or gdb.

Nick