From owner-freebsd-stable@FreeBSD.ORG Fri Jan 22 17:18:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3824710656A5 for ; Fri, 22 Jan 2010 17:18:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id B928A8FC16 for ; Fri, 22 Jan 2010 17:18:22 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-045-145.pools.arcor-ip.net [88.66.45.145]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Mefpk-1NA4xh1vEO-00OgaM; Fri, 22 Jan 2010 18:18:21 +0100 Received: (qmail 89242 invoked from network); 22 Jan 2010 17:18:21 -0000 Received: from f8x64.laiers.local (192.168.4.188) by ns1.laiers.local with SMTP; 22 Jan 2010 17:18:21 -0000 From: Max Laier Organization: FreeBSD To: John Baldwin Date: Fri, 22 Jan 2010 18:18:20 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <4B58280C.50602@smeets.im> <4B595D0D.3060904@smeets.im> <201001220920.13458.jhb@freebsd.org> In-Reply-To: <201001220920.13458.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001221818.20409.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/XNn0n0w+4rHPJIWLxYZ1rpcuJ+c2Mno1tx4O CdpZ6sIFknOk022Rka8HimEcPhsQDvkisADO/Ha/iv2XImD2gL JhuOk0J6+XagVsHJAKd4Q== Cc: Bjoern Zeeb , Luigi Rizzo , Florian Smeets , freebsd-stable@freebsd.org Subject: Re: 7.2-STABLE page fault with kernel from 12.01.2010 / crashinfo available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:18:23 -0000 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 , > 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