From owner-freebsd-net@FreeBSD.ORG Wed Feb 29 08:10:16 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 824591065670 for ; Wed, 29 Feb 2012 08:10:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBA48FC12 for ; Wed, 29 Feb 2012 08:10:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1T8AG2j073316 for ; Wed, 29 Feb 2012 08:10:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1T8AG7L073315; Wed, 29 Feb 2012 08:10:16 GMT (envelope-from gnats) Date: Wed, 29 Feb 2012 08:10:16 GMT Message-Id: <201202290810.q1T8AG7L073315@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 08:10:16 -0000 The following reply was made to PR kern/164400; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org, eugene@zhegan.in Cc: Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec processing Date: Wed, 29 Feb 2012 14:03:55 +0600 This is reproduceable on smaller amount of configs. Right now I've built a test installation of nanobsd 9.0, which is also crashing under the same conditions. For example: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x60 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0980d89 stack pointer = 0x28:0xccf245cc frame pointer = 0x28:0xccf245f4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2099 (ping) trap number = 12 panic: page fault KDB: stack backtrace: #0 0xc07d35f8 at kdb_backtrace+0x48 #1 0xc07a3163 at panic+0xf3 #2 0xc0a8a492 at trap_fatal+0x232 #3 0xc0a8a77b at trap_pfault+0x1ab #4 0xc0a8b477 at trap+0x367 #5 0xc0a766cc at calltrap+0x6 #6 0xc098fe0f at esp_output_cb+0x19f #7 0xc099f6f7 at crypto_done+0xf7 #8 0xc09a1c33 at swcr_process+0x83 #9 0xc09a06d7 at crypto_invoke+0x67 #10 0xc09a1548 at crypto_dispatch+0xe8 #11 0xc0990457 at esp_output+0x577 #12 0xc09810be at ipsec4_process_packet+0x1ee #13 0xc08c3e03 at ip_ipsec_output+0x153 #14 0xc08c6406 at ip_output+0x426 #15 0xc2671259 at gre_output+0x469 #16 0xc08c6b87 at ip_output+0xba7 #17 0xc08c73dc at rip_output+0x24c Uptime: 1m45s Automatic reboot in 15 seconds - press a key on the console to abort I can say also that 'current process' is simply a process that sends the packet which crashes the system. The crash occurs on some of the first packets immidialety after establishing SA.