7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo
max at love2party.net
Fri Jan 22 17:18:23 UTC 2010
On Friday 22 January 2010 15:20:13 John Baldwin wrote:
> On Friday 22 January 2010 3:08:45 am Florian Smeets wrote:
> > If it really is IPsec traffic then there are no rewrite rules only 10 pf
> > pass rules on the enc0 interface and a "scrub in all" rule.
> > Perhaps it matters that i have these set:
> > net.enc.out.ipsec_bpf_mask=0x00000001
> > net.enc.out.ipsec_filter_mask=0x00000001
> > net.enc.in.ipsec_bpf_mask=0x00000002
> > net.enc.in.ipsec_filter_mask=0x00000002
> > so that i can filter the "encapsulated" traffic.
> I have no idea, I've cc'd mlaier@ (pf) and bz@ (ipsec) to see if they have
> any ideas.
pf could be the culprit if it were present in the trace, but I don't see any
sign of it:
On Thursday 21 January 2010 11:10:20 Florian Smeets wrote:
> #7 0xc0572e48 in m_copydata (m=0x0, off=0, len=40, cp=0xc23cced8
> at /usr/src/sys/kern/uipc_mbuf.c:815
> #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at
> #9 0xc05fa30c in ip_input (m=0xc23dc900) at
> #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at
> #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at
> #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at
> #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at
> #14 0xc04b8973 in sis_intr (arg=0xc2093800) at
> #15 0xc050344b in ithread_loop (arg=0xc20ab410) at
> #16 0xc04ffe36 in fork_exit (callout=0xc05032a0 <ithread_loop>,
> arg=0xc20ab410, frame=0xc1f15d38) at /usr/src/sys/kern/kern_fork.c:811
> #17 0xc06d9180 in fork_trampoline () at
pf does change the byte order in the pfil hook, but changes it back on return
to the stack either when returning from the hook or when calling back into the
stack. There have been some issues where we missed returns to the stack that
would result in this situation, but since pf is not in the trace, this is
clearly not the case here.
It might indeed be related to enc(4). I remember there have been some issues
in IPSEC where it failed to properly copy a packet before modifying it. Maybe
this is what is happening. Details escape me at the moment.
Can you also make sure that your if_enc.c has revision 174978:
More information about the freebsd-stable