Re: LORs on 8-current kernel with 7-stable world

On Dec 27, 2008, at 13:07, "Arno J. Klaassen"  
<arno_at_heho.snv.jussieu.fr> wrote:

>
> Hello,
>
> I get these when running a  8-current kernel with 7-stable world.
> I can'f access http://sources.zabbadoz.net/freebsd/lor.html
> to see if they are known.
>
> fyi, Arno
>
> ####
>
>
> lock order reversal:
> 1st 0xffffff0001305070 user map (user map) _at_ /raid1/bsd/src-current/ 
> sys/vm/vm_map.c:3115
> 2nd 0xffffff0001502270 ufs (ufs) _at_ /raid1/bsd/src-current/sys/kern/ 
> vfs_subr.c:2079
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x65
> witness_checkorder() at witness_checkorder+0x859
> __lockmgr_args() at __lockmgr_args+0xcb8
> ffs_lock() at ffs_lock+0x8f
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x57
> vget() at vget+0x8b
> vnode_pager_lock() at vnode_pager_lock+0x1d0
> vm_fault() at vm_fault+0x22a
> trap_pfault() at trap_pfault+0x127
> trap() at trap+0x51c
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp =  
> 0x7fffffffee90 ---
>
>
> lock order reversal:
> 1st 0xffffff0001aa3098 pseudofs (pseudofs) _at_ /raid1/bsd/src-current/ 
> sys/kern/vfs_vnops.c:531
> 2nd 0xffffff00015027f8 ufs (ufs) _at_ /raid1/bsd/src-current/sys/kern/ 
> vfs_lookup.c:442
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x65
> witness_checkorder() at witness_checkorder+0x859
> __lockmgr_args() at __lockmgr_args+0xcb8
> ffs_lock() at ffs_lock+0x8f
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x57
> lookup() at lookup+0x103
> namei() at namei+0x52d
> linprocfs_domtab() at linprocfs_domtab+0x76
> pfs_read() at pfs_read+0x53c
> vn_read() at vn_read+0x267
> dofileread() at dofileread+0xa1
> kern_readv() at kern_readv+0x60
> read() at read+0x54
> ia32_syscall() at ia32_syscall+0x1ab
> Xint0x80_syscall() at Xint0x80_syscall+0x60
> --- syscall (3, Linux ELF32, read), rip = 0x28162cee, rsp =  
> 0xffffdca8, rbp = 0xffffdcbc ---
>
>
> lock order reversal:
> 1st 0xfffffffe68494f20 bufwait (bufwait) _at_ /raid1/bsd/src-current/ 
> sys/kern/vfs_bio.c:2443
> 2nd 0xffffff0001c7d000 dirhash (dirhash) _at_ /raid1/bsd/src-current/ 
> sys/ufs/ufs/ufs_dirhash.c:263
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x65
> witness_checkorder() at witness_checkorder+0x859
> _sx_xlock() at _sx_xlock+0x55
> ufsdirhash_acquire() at ufsdirhash_acquire+0x33
> ufsdirhash_remove() at ufsdirhash_remove+0x16
> ufs_dirremove() at ufs_dirremove+0x181
> ufs_remove() at ufs_remove+0x92
> VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93
> kern_unlinkat() at kern_unlinkat+0x249
> linux_unlinkat() at linux_unlinkat+0xa6
> ia32_syscall() at ia32_syscall+0x1ab
> Xint0x80_syscall() at Xint0x80_syscall+0x60
> --- syscall (301, Linux ELF32, linux_unlinkat), rip = 0x28126968,  
> rsp = 0xffffd4e8, rbp = 0xffffd508 ---

Do an installworld and reboot? This datapoint shouldn't have any  
relevance because you're mixing and matching major versions of  
components which I wouldn't expect to work necessarily.
-Garrett