Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffffa7b83547 stack pointer = 0x10:0xffffffffa5683690 frame pointer = 0x10:0xffffffffa5683790 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 32m25s Dumping 1023 MB (2 chunks) (kgdb) bt #0 0xffffffff8043644d in doadump () #1 0xffffffff80436474 in doadump () #2 0x0000000000000004 in ?? () #3 0xffffffff80436a77 in boot () #4 0x0000000000000019 in ?? () #5 0x0000000033ca70c0 in ?? () #6 0xffffff003dbb5be0 in ?? () #7 0x0000000000000104 in ?? () #8 0x0000000000000000 in ?? () #9 0xffffff003dbb5be0 in ?? () #10 0xffffff003dbb4358 in ?? () #11 0xffffffff80437111 in panic () #12 0x0000003000000010 in ?? () #13 0xffffffffa5683500 in ?? () #14 0xffffffffa5683430 in ?? () #15 0xffffffffa5683500 in ?? () #16 0xffffffffa5683440 in ?? () #17 0xffffffff807b490a in __func__.0 () #18 0x0000000000000001 in ?? () #19 0x0000000000102948 in ?? () #20 0x00000000000ffe00 in ?? () #21 0x000000000000000a in ?? () #22 0x00000000000ffe00 in ?? () ---Type <return> to continue, or q <return> to quit--- #23 0x000000000000000a in ?? () #24 0xffffffff809cb020 in thread0 () #25 0xffffffff809cb020 in thread0 () #26 0x0000000000000000 in ?? () #27 0xffffff003db8eb00 in ?? () #28 0x00000000287b75b4 in ?? () #29 0x00000000a568000a in ?? () #30 0xffffff0000d99000 in ?? () #31 0xffffff0030746600 in ?? () #32 0x0000000000000096 in ?? () #33 0x0000000000000096 in ?? () #34 0xffffffff85ec9000 in ?? () #35 0xffffffff8026ba2b in bge_start_locked () #36 0xffffffffa5680006 in ?? () #37 0xffffffffa5683570 in ?? () #38 0x000000000000000c in ?? () #39 0xffffff003dbb5be0 in ?? () #40 0x000000000000000c in ?? () #41 0xffffffff806bcc8f in trap_fatal () #42 0x0000000000000000 in ?? () #43 0x00000000000fffff in ?? () #44 0x000000003074659b in ?? () #45 0xffffff003dbb4358 in ?? () ---Type <return> to continue, or q <return> to quit--- #46 0x0000000000000000 in ?? () #47 0xffffffffa5683d10 in ?? () #48 0x0000000000000001 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000001 in ?? () #51 0xffffffff806bd00c in trap_pfault () #52 0x0000000000000004 in ?? () #53 0xffffff003dbb5be0 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000003 in ?? () #56 0xffffff003dbb5be0 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0xffffff003dbb4358 in ?? () #61 0xffffffff806bd2c3 in trap () #62 0x0000000100000001 in ?? () #63 0xffffff003033a600 in ?? () #64 0xffffffffa5683790 in ?? () #65 0x00000000ca53b2f2 in ?? () #66 0x0000000000000000 in ?? () #67 0xffffffffa5683840 in ?? () #68 0x0000000000000000 in ?? () ---Type <return> to continue, or q <return> to quit--- #69 0xffffffff806a433b in calltrap () Previous frame identical to this frame (corrupt stack?) I will resubmit it with a kernel with debugging symbols present.
This is from the debug kernel: #92 0x0000000000000000 in ?? () #93 0xffffffff809e0240 in ip_rsvpd () #94 0xffffffff804cdaae in pfil_run_hooks (ph=0xffffffffa5683790, mp=0x0, ifp=0xffffff0000d99800, dir=-900484366, inp=0x0) at ../../../net/pfil.c:139 #95 0xffffffff80504c7b in ip_output (m=0xffffff0003087c00, opt=0x881cecb, ro=0xffffffffa56839f0, flags=1, imo=0x0, inp=0x0) at ../../../netinet/ip_output.c:679 #96 0xffffffff80501b17 in ip_forward (m=0xffffff0003087c00, srcrt=14258176) at ../../../netinet/ip_input.c:1923 #97 0xffffffff805024dc in ip_input (m=0xffffff0003087c00) at ../../../netinet/ip_input.c:694 #98 0xffffffff804cc1ec in netisr_processqueue (ni=0xffffffff809deb30) at ../../../net/netisr.c:236 #99 0xffffffff804cc49d in swi_net (dummy=0xffffff0001a9f200) at ../../../net/netisr.c:349 #100 0xffffffff8041bd58 in ithread_loop (arg=0xffffff00000345e0) at ../../../kern/kern_intr.c:682 #101 0xffffffff8041a4f7 in fork_exit ( callout=0xffffffff8041bc10 <ithread_loop>, arg=0xffffff00000345e0, frame=0xffffffffa5683c50) at ../../../kern/kern_fork.c:788 #102 0xffffffff806a46fe in fork_trampoline () at ../../../amd64/amd64/exception.S:411 #103 0x0000000000000000 in ?? () Which is related to this function: int pfil_run_hooks(struct pfil_head *ph, struct mbuf **mp, struct ifnet *ifp, int dir, struct inpcb *inp) { struct packet_filter_hook *pfh; struct mbuf *m = *mp; int rv = 0; if (ph->ph_busy_count == -1) return (0); /* * Prevent packet filtering from starving the modification of * the packet filters. We would prefer a reader/writer locking * mechanism with guaranteed ordering, though. */ if (ph->ph_want_write) { m_freem(*mp); *mp = NULL; return (ENOBUFS); } PFIL_RLOCK(ph); for (pfh = pfil_hook_get(dir, ph); pfh != NULL; pfh = TAILQ_NEXT(pfh, pfil_link)) { if (pfh->pfil_func != NULL) { 139 -> rv = (*pfh->pfil_func)(pfh->pfil_arg, &m, ifp, dir, inp) ; if (rv != 0 || m == NULL) break; } } PFIL_RUNLOCK(ph); *mp = m; return (rv); } The value of 0x0 for m there doesn't make sense *UNLESS* it is the first packet. -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/
Responsible Changed From-To: freebsd-bugs->freebsd-net I think the fine guys at net@ may take care... ;)
On Tue, Mar 18, 2008 at 11:21:04PM +0000, vwe@FreeBSD.org wrote: > I think the fine guys at net@ may take care... ;) After running a debug kernel it hasn't happened anymore. Once it happens again (I will know :-) I will have more information on this. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/
State Changed From-To: open->suspended Suspend for now until Edwin is able to reproduce this.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Keyword: crash – in lieu of summary line prefix: [panic] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>