Date: Fri, 22 Jan 2010 18:18:20 +0100 From: Max Laier <max@love2party.net> To: John Baldwin <jhb@freebsd.org> Cc: Bjoern Zeeb <bz@freebsd.org>, Luigi Rizzo <luigi@freebsd.org>, Florian Smeets <flo@smeets.im>, freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available Message-ID: <201001221818.20409.max@love2party.net> In-Reply-To: <201001220920.13458.jhb@freebsd.org> References: <4B58280C.50602@smeets.im> <4B595D0D.3060904@smeets.im> <201001220920.13458.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > "\203??b??\237\f)h?M\220\224?\023?\205K(e??s?\"???k?oQ?~\223\020g\030") > at /usr/src/sys/kern/uipc_mbuf.c:815 > #8 0xc05f8b28 in ip_forward (m=0xc23dc900, srcrt=0) at > /usr/src/sys/netinet/ip_input.c:1307 > #9 0xc05fa30c in ip_input (m=0xc23dc900) at > /usr/src/sys/netinet/ip_input.c:609 > #10 0xc05c83d5 in netisr_dispatch (num=2, m=0xc23dc900) at > /usr/src/sys/net/netisr.c:185 > #11 0xc05bf581 in ether_demux (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:834 > #12 0xc05bf973 in ether_input (ifp=0xc20a4800, m=0xc23dc900) at > /usr/src/sys/net/if_ethersubr.c:692 > #13 0xc04b8749 in sis_rxeof (sc=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1476 > #14 0xc04b8973 in sis_intr (arg=0xc2093800) at > /usr/src/sys/dev/sis/if_sis.c:1667 > #15 0xc050344b in ithread_loop (arg=0xc20ab410) at > /usr/src/sys/kern/kern_intr.c:1126 > #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 > /usr/src/sys/i386/i386/exception.s:271 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: http://svn.freebsd.org/viewvc/base/release/7.2.0/sys/net/if_enc.c?view=diff&r1=174977&r2=174978 Regards, -- Max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001221818.20409.max>