On Mon, Mar 08, 2004 at 12:10:40PM -0800, Peter Wemm wrote: > > I wish it helps... > > This particular one was my fault, I believe it's been fixed. However, I > also believe this particular LOR happens via other code paths that were > not my fault. I updated my kernel last night to what I was sure was sources dated after your fix, but I was still seeing it. The system would lock up shortly thereafter, so I had to revert to 5.2.1-R. lock order reversal 1st 0xc103b060 system map (system map) _at_ vm/vm_map.c:2210 2nd 0xc0725500 Giant (Giant) _at_ vm/vm_fault.c:1084 Stack backtrace: backtrace(0,ffffffff,c0733520,c0733868,c06fa21c) at backtrace+0x12 witness_checkorder(c0725500,9,c06d2cd4,43c) at witness_checkorder+0x593 _mtx_lock_flags(c0725500,0,c06d2ccb,43c,c1039744) at _mtx_lock_flags+0x67 vm_fault_unwire(c103b000,e86b9000,e86ba000,c103b000,e855dc28) at vm_fault_unwire+0x25 vm_map_entry_unwire(c103b000,c1039744) at vm_map_entry_unwire+0x15 vm_map_delete(c103b000,e86b9000,e86ba000,c958bec0,c99fa4ec) at vm_map_delete+0x118 vm_map_remove(c103b000,e86b9000,e86ba000,e855dc8c,c067491d) at vm_map_remove+0x42 kmem_free(c103b000,e86b9000,1000,c07254c0,0) at kmem_free+0x25 user_ldt_free(c99fc540) at user_ldt_free+0xbd cpu_exit(c99fc540,c99fa3dc,0,c06bda4f,1f8) at cpu_exit+0x2f exit1(c99fc540,0,e855dd40,c0675b13,c99fc540) at exit1+0xd38 exit1(c99fc540,e855dd14,1,9,286) at exit1 syscall(2f,2f,2f,bfbfe89c,bfbfe8ac) at syscall+0x217 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1), eip = 0x28245163, esp = 0xbfbfe848, ebp = 0xbfbfe864 --- Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:46 UTC