Re: new LOR to report...

On Wed, 25 Jan 2006 19:37:40 -0800
John-Mark Gurney <gurney_j_at_resnet.uoregon.edu> wrote:

> Ok, just ran across a new LOR when trying to unload a module:
> lock order reversal: (sleepable after non-sleepable)
>  1st 0xc106c708 mt_zone (UMA zone) _at_ vm/uma_core.c:2448
>  2nd 0xc3934044 user map (user map) _at_ vm/vm_map.c:2993
> KDB: stack backtrace:
> kdb_backtrace(0,ffffffff,c070fb58,c070fa68,c06d122c) at
> kdb_backtrace+0x29 witness_checkorder(c3934044,9,c06ab0ce,bb1) at
> witness_checkorder+0x586 _sx_xlock(c3934044,c06ab0c5,bb1) at
> _sx_xlock+0x50
> _vm_map_lock_read(c3934000,c06ab0c5,bb1,1d5d9dc,c3aa86e0) at
> _vm_map_lock_read+0x33 vm_map_lookup(d1d5da68,0,1,d1d5da6c,d1d5da5c)
> at vm_map_lookup+0x28 vm_fault(c3934000,0,1,0,c39db6c0) at
> vm_fault+0x66 trap_pfault(d1d5db84,0,15) at trap_pfault+0xce
> trap(8,28,28,0,c106c700) at trap+0x3a5
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc060ecc4, esp = 0xd1d5dbc4, ebp = 0xd1d5dbd0 ---
> uma_zfree_internal(c106a960,c3b99000,0,1,3) at uma_zfree_internal+0xd0
> uma_zfree_arg(c106a960,c3b99000,0) at uma_zfree_arg+0x348
> malloc_uninit(c3b79980) at malloc_uninit+0xdc
> linker_file_sysuninit(c3ad1400,0,2,c3ad1400,c3aa8678) at
> linker_file_sysuninit+0x7d
> linker_file_unload(c3ad1400,0,0,c39db6c0,d1d5dc80) at
> linker_file_unload+0x116
> kern_kldunload(c39db6c0,b,0,d1d5dd30,c065dc92) at kern_kldunload+0x7c
> kldunloadf(c39db6c0,d1d5dd04,c,c39db6c0,d1d5dd30) at kldunloadf+0x1e
> syscall(3b,3b,3b,b,bfbfe9be) at syscall+0x27e Xint0x80_syscall() at
> Xint0x80_syscall+0x1f --- syscall (444, FreeBSD ELF32, kldunloadf),
> eip = 0x280ba223, esp = 0xbfbfe41c, ebp = 0xbfbfe888 ---
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x15
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc060ecc4
> stack pointer           = 0x28:0xd1d5dbc4
> frame pointer           = 0x28:0xd1d5dbd0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 790 (kldunload)
> [thread pid 790 tid 100080 ]
> Stopped at      uma_zfree_internal+0xd0:        movzbl 
> 0x15(%ebx),%eax db> tr
> Tracing pid 790 tid 100080 td 0xc39db6c0
> uma_zfree_internal(c106a960,c3b99000,0,1,3) at uma_zfree_internal+0xd0
> uma_zfree_arg(c106a960,c3b99000,0) at uma_zfree_arg+0x348
> malloc_uninit(c3b79980) at malloc_uninit+0xdc
> linker_file_sysuninit(c3ad1400,0,2,c3ad1400,c3aa8678) at
> linker_file_sysuninit+0x7d
> linker_file_unload(c3ad1400,0,0,c39db6c0,d1d5dc80) at
> linker_file_unload+0x116
> kern_kldunload(c39db6c0,b,0,d1d5dd30,c065dc92) at kern_kldunload+0x7c
> kldunloadf(c39db6c0,d1d5dd04,c,c39db6c0,d1d5dd30) at kldunloadf+0x1e
> syscall(3b,3b,3b,b,bfbfe9be) at syscall+0x27e Xint0x80_syscall() at
> Xint0x80_syscall+0x1f --- syscall (444, FreeBSD ELF32, kldunloadf),
> eip = 0x280ba223, esp = 0xbfbfe41c, ebp = 0xbfbfe888 ---
> 
> I didn't see it on the list...

This looks very similar to the panic I encountered while unloading a
module with 6-stable. I've already sent a mail to the stable-list, but
will attach the debug info again to this mail.

Maybe it helps figuring it out. :-)

Bye
Marc

-- 
"And what rough beast, its hour come round at last,
Slouches towards Bethlehem to be born?"

W.B. Yeats, The Second Coming