Date: Wed, 12 Sep 2007 12:27:52 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Panic in arpresolve->rt_check? Message-ID: <20070912172752.GA13960@dan.emsphone.com> In-Reply-To: <fc89en$fc2$1@sea.gmane.org> References: <fc89en$fc2$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070912172752.GA13960>