rtentry LOR from Feb 14 -CURRENT

I was testing PPPoA on the DSL interface I'm hacking on when this happened.

It doesn't appear to be related to it, as the interface doesn't cause any
routes to be added to the system (it's NATM only).

Feb 14 was my branchpoint for bms_wix in p4. I haven't done an IFC yet
mainly due to phk turbulence.

It does appear to be related to a change I made to /etc/ppp/ppp.conf which
affected how ppp set up the tun0 interface:

 set ifaddr 172.16.0.1/0 212.0.0.0/0 0 0
 add! default HISADDR

Invoking ppp resulted in the following:

lock order reversal
 1st 0xc29c3a64 rtentry (rtentry) _at_ net/rtsock.c:387
 2nd 0xc28c727c radix node head (radix node head) _at_ net/route.c:133
Stack backtrace:
backtrace(0,ffffffff,c0633390,c0633598,c060a2dc) at backtrace+0x12
witness_checkorder(c28c727c,9,c05e82d4,85) at witness_checkorder+0x593
_mtx_lock_flags(c28c727c,0,c05e82cb,85,7) at _mtx_lock_flags+0x67
rtalloc1(c2afcc6c,0,0,d2d4db44,0) at rtalloc1+0x61
ifa_ifwithroute(803,c2afcc5c,c2afcc6c,c29c3a64,c28c7200) at ifa_ifwithroute+0x64
rt_getifa(d2d4db44,0,c29c3a00,c2afcc00,c05e2457) at rt_getifa+0xaa
route_output(c10f6b00,c29b4d20,8c,c10f6b00,1f74) at route_output+0x549
raw_usend(c29b4d20,0,c10f6b00,0,0,c2a4c000) at raw_usend+0x6c
rts_send(c29b4d20,0,c10f6b00,0,0) at rts_send+0x1b
sosend(c29b4d20,0,d2d4dc88,c10f6b00,0) at sosend+0x3fd
soo_write(c2949e9c,d2d4dc88,c39d5d00,0,c2a4c000) at soo_write+0x37
dofilewrite(c2a4c000,c2949e9c,a,bfbfdad0,8c) at dofilewrite+0xbb
write(c2a4c000,d2d4dd14,3,9,292) at write+0x3e
syscall(2f,2f,2f,ffffffff,8c) at syscall+0x217
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x2824bf9b, esp = 0xbfbfd8cc, ebp = 0xbfbfd8f8 ---

immediately followed by:-

panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry _at_ ../../../net/r
oute.c:182

(kgdb) bt
#0  0xc0598e03 in Debugger (msg=0xc05df22e "panic") at machine/atomic.h:263
#1  0xc049cc9f in __panic (file=0xc05de64f "../../../kern/kern_mutex.c",
    line=436,
    fmt=0xc05de739 "_mtx_lock_sleep: recursed on non-recursive mutex %s _at_ %s:%d\
n") at ../../../kern/kern_shutdown.c:536
#2  0xc04952cf in _mtx_lock_sleep (m=0xc29c3a64, opts=0,
    file=0xc05e82cb "../../../net/route.c", line=182)
    at ../../../kern/kern_mutex.c:479
#3  0xc0494f4f in _mtx_lock_flags (m=0xc29c3a64, opts=0,
    file=0xc05e82cb "../../../net/route.c", line=182)
    at ../../../kern/kern_mutex.c:251
#4  0xc04fde3c in rtalloc1 (dst=0xc2afcc6c, report=0, ignflags=18)
    at ../../../net/route.c:182
#5  0xc04fe31c in ifa_ifwithroute (flags=18, dst=0xc2afcc5c,
    gateway=0xc2afcc6c) at ../../../net/route.c:443
#6  0xc04fe49e in rt_getifa (info=0xd2d4db44) at ../../../net/route.c:527
#7  0xc04ffeb5 in route_output (m=0xc10f6b00, so=0xc29b4d20)
    at ../../../net/rtsock.c:445
#8  0xc04fdab0 in raw_usend (so=0xc0c14000, flags=0, m=0x0, nam=0x0,
    control=0x12, td=0xc2a4c000) at ../../../net/raw_usrreq.c:257
#9  0xc04ff93f in rts_send (so=0xc29b4d20, flags=0, m=0xc10f6b00, nam=0x0,
    control=0x0, td=0xc2a4c000) at ../../../net/rtsock.c:243
#10 0xc04cffa5 in sosend (so=0xc29b4d20, addr=0x0, uio=0xd2d4dc88,
    top=0xc10f6b00, control=0x0, flags=0, td=0xc2a4c000)
    at ../../../kern/uipc_socket.c:722
#11 0xc04c296f in soo_write (fp=0x12, uio=0xd2d4dc88, active_cred=0xc39d5d00,
    flags=0, td=0xc2a4c000) at ../../../kern/sys_socket.c:115
#12 0xc04be007 in dofilewrite (td=0xc2a4c000, fp=0xc2949e9c, fd=10,
    buf=0xbfbfdad0, nbyte=140, offset=-4557290979178053614, flags=0)
    at ../../../sys/file.h:249
#13 0xc04bdea2 in write (td=0xc2a4c000, uap=0xd2d4dd14)
    at ../../../kern/sys_generic.c:334
#14 0xc05a6d2f in syscall (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 140, tf_ebp = -
1077946120, tf_isp = -757801612, tf_ebx = 10, tf_edx = 0, tf_ecx = 673957868, tf
_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 673496987, tf_cs = 31, tf_eflags =
 658, tf_esp = -1077946164, tf_ss = 47}) at ../../../i386/i386/trap.c:1008

Enjoy - the DSL driver is nearly ready, though.
BMS