Panic in arpresolve->rt_check?

[Dan Nelson]

In the last episode (Sep 12), Ivan Voras said:
> I've got several crash dumps caused by the following:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 01
> fault virtual address   = 0x188
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0654e25
> stack pointer           = 0x28:0xe38b6924
> frame pointer           = 0x28:0xe38b693c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 15 (swi1: net)
> trap number             = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c09322d0,e38b6800,c0661841,c094d6f1,0,...) at 
> db_trace_self_wrapper+0x26
> kdb_backtrace(c094d6f1,0,c0903950,e38b680c,0,...) at kdb_backtrace+0x29
> panic(c0903950,c094e9ad,c4d5677c,1,1,...) at panic+0x111
> trap_fatal(c094e8af,c,0,11000000,c4d56558,...) at trap_fatal+0x383
> trap(e38b68e4) at trap+0x12b
> calltrap() at calltrap+0x6
> --- trap 0xc, eip = 0xc0654e25, esp = 0xe38b6924, ebp = 0xe38b693c ---
> _mtx_lock_sleep(c5e10c90,c4d10aa0,0,0,0,...) at _mtx_lock_sleep+0x85
> rt_check(e38b6984,e38b69a0,c57963f0,0,0,...) at rt_check+0x120
> arpresolve(c4e27000,c5e0fbb8,c5f20e00,c57963f0,e38b69ba,...) at 
> arpresolve+0xb4
> ether_output(c4e27000,c5f20e00,c57963f0,c5e0fbb8,c8a6a3f0,...) at 
> ether_output+0x7e
> ip_output(c5f20e00,0,e38b6a28,0,0,...) at ip_output+0xa59
> tcp_output(c89e2168,8,36ee80,0,0,...) at tcp_output+0x1493
> tcp_do_segment(c89e2168,28,0,6b4835a1,901f,...) at tcp_do_segment+0x1c55
> tcp_input(c60e1700,14,c4ea3c00,1,0,...) at tcp_input+0xd2e
> ip_input(c60e1700,0,c08b0028,e38b0028,0,...) at ip_input+0x6b0
> netisr_processqueue(c4d10aa0,0,1,1000000,c4d10aa0,...) at 
> netisr_processqueue+0xdb
> swi_net(0,0,c092df73,46b,0,...) at swi_net+0x12b
> ithread_loop(c4d0c270,e38b6d38,0,0,0,...) at ithread_loop+0x1cb
> fork_exit(c0643a60,c4d0c270,e38b6d38) at fork_exit+0xa4
> fork_trampoline() at fork_trampoline+0x8
> 
> This is on a recent -CURRENT, i386, SMP. NIC is fxp. If anyone needs more 
> data, please let me know - this is a critical problem for me. The same 
> machine worked ok with 6-STABLE.

Quite a few people have reported similar issues, either a trap 12 or a
"mtx_lock() of destroyed mutex", all with a stack ending in rt_check.

http://lists.freebsd.org/pipermail/freebsd-current/2007-March/070231.html
http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014092.html
http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074643.html
http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076041.html
http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076242.html

The same panic was also reported for 6.2 via PR 107865 and PR 112490. 
112490 included a workaround patch (I haven't tried it; just found it).

-- 
	Dan Nelson
	dnelson at allantgroup.com