> Source from the 11th indicates that this line number to points to a > vm_map_lock_read() call inside vm_map_lookup() which would be called on a > page fault. seems so > > stray iqr 9 > > _mtx_lock_sleep: recursed on non-recursive mutex > > kern_mutex.c:436 > > Ouch. > > > I have kernel dump which I can provide (but my kernel is not -g > > compiled) > > Run an "nm /boot/kernel/kernel |sort" and report the function names and > addresses of the functions just above and below the eip (0xc05babdc). > > Regards, is this enough? c05ba630 t vm_map_zfini c05ba660 t vm_map_zinit c05ba6e0 t vmspace_zdtor c05ba710 t vm_map_zdtor c05ba7c0 T vmspace_alloc c05ba840 T vm_init2 c05ba8e0 T vmspace_free c05ba9e0 T vmspace_exitfree c05baac0 T _vm_map_lock c05bab60 T _vm_map_unlock c05babc0 T _vm_map_lock_read c05bac50 T _vm_map_unlock_read c05bacb0 T _vm_map_trylock c05bad30 T _vm_map_trylock_read c05badb0 T _vm_map_lock_upgrade c05bae40 T _vm_map_lock_downgrade c05baec0 T vm_map_unlock_and_wait c05baf40 T vm_map_wakeup c05bafb0 T vmspace_resident_count c05bafc0 T vmspace_wired_count c05bafd0 T vm_map_create c05bb020 t _vm_map_init c05bb070 T vm_map_initReceived on Fri Feb 13 2004 - 02:21:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:42 UTC