From nobody@FreeBSD.org  Fri Apr 25 04:14:08 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C7EA7106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 25 Apr 2008 04:14:08 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id B566A8FC2D
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 25 Apr 2008 04:14:08 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m3P4DeOf082720
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 25 Apr 2008 04:13:40 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m3P4DeGP082719;
	Fri, 25 Apr 2008 04:13:40 GMT
	(envelope-from nobody)
Message-Id: <200804250413.m3P4DeGP082719@www.freebsd.org>
Date: Fri, 25 Apr 2008 04:13:40 GMT
From: Mihail <msaf1980@rambler.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: kernel trap with ipsec 
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         123066
>Category:       kern
>Synopsis:       [ipsec] [panic] kernel trap with ipsec
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    vanhu
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 25 04:20:01 UTC 2008
>Closed-Date:    Mon Mar 28 12:27:48 UTC 2011
>Last-Modified:  Mon Mar 28 12:27:48 UTC 2011
>Originator:     Mihail
>Release:        7.0
>Organization:
>Environment:
7.0-RELEASE-p1
>Description:
I get kernel trap with IPSEC when use ping with size > 3000 bytes over
IPSEC tunnel with router D-Link DI-804HV, like

ping -s 4000 -S 192.168.241.160 192.168.200.6


Local Subnet is 192.168.241.0/24
Remote Subnet is 192.168.200.0/29

/etc/ipsec.conf

spdflush;
spdadd 192.168.241.0/24 192.168.200.0/29 any -P out ipsec esp/tunnel/XX.XX.XX.XX-YY.YY.YY.YY/require;
spdadd 192.168.200.0/29 192.168.241.0/24 any -P in ipsec esp/tunnel/YY.YY.YY.YY-XX.XX.XX.XX/require;

Kernel config is simular to GENERIC with options

options         NETGRAPH
options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=100
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPDIVERT
options         DUMMYNET
options         HZ=1000
options         MROUTING

device crypto

options         IPSEC
options         IPSEC_DEBUG

Kernel dump 

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xd7d6d5e8
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc0a952f6
stack pointer           = 0x28:0xc884e974
frame pointer           = 0x28:0xc884e9d8
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         = 864 (ping)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 2m36s
Physical memory: 115 MB
Dumping 30 MB: 15


(kgdb) list *0xc0a952f6
0xc0a952f6 is at /usr/src/sys/i386/i386/support.s:499.
494     cmpl    %ecx,%eax                       /* overlapping && src < dst? */
495     jb      1f
496
497     shrl    $2,%ecx                         /* copy by 32-bit words */
498     cld                                     /* nope, copy forwards */
499     rep
500     movsl
501     movl    20(%esp),%ecx
502     andl    $3,%ecx                         /* any bytes left? */
503     rep


(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0xc075df57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc075e219 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904)
    at /usr/src/sys/i386/i386/trap.c:899
#4  0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, eva=3621180904)
    at /usr/src/sys/i386/i386/trap.c:812
#5  0xc0a9829c in trap (frame=0xc884e934) at /usr/src/sys/i386/i386/trap.c:490
#6  0xc0a7e21b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0a952f6 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498
Previous frame inner to this frame (corrupt stack?)

>How-To-Repeat:
permanently
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Apr 25 04:42:50 UTC 2008 
Responsible-Changed-Why:  
Reclassify and assign. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 

From: Kris Kennaway <kris@FreeBSD.org>
To: Mihail <msaf1980@rambler.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/123066: kernel trap with ipsec
Date: Fri, 25 Apr 2008 05:46:54 +0000

 On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote:
 
 > (kgdb) backtrace
 > #0  doadump () at pcpu.h:195
 > #1  0xc075df57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
 > #2  0xc075e219 in panic (fmt=Variable "fmt" is not available.
 > ) at /usr/src/sys/kern/kern_shutdown.c:563
 > #3  0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904)
 >     at /usr/src/sys/i386/i386/trap.c:899
 > #4  0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0, eva=3621180904)
 >     at /usr/src/sys/i386/i386/trap.c:812
 > #5  0xc0a9829c in trap (frame=0xc884e934) at /usr/src/sys/i386/i386/trap.c:490
 > #6  0xc0a7e21b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
 > #7  0xc0a952f6 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498
 > Previous frame inner to this frame (corrupt stack?)
 
 Unfortunately we need the rest of the stack.  Can you either try to
 reproduce with DDB in the kernel and obtain a stack trace from there,
 or if this is not possible then try recompiling the kernel with -O
 instead of -O2 which tends to produce better stack traces.
 
 Kris
 

From: misha saf <msaf1980@rambler.ru>
To: Kris Kennaway <kris@FreeBSD.org>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: misc/123066: kernel trap with ipsec
Date: Fri, 25 Apr 2008 10:59:33 +0400

 * Kris Kennaway <kris@FreeBSD.org> [Fri, 25 Apr 2008 05:46:54 +0000]:
 > On Fri, Apr 25, 2008 at 04:13:40AM +0000, Mihail wrote:
 >
 > > (kgdb) backtrace
 > > #0  doadump () at pcpu.h:195
 > > #1  0xc075df57 in boot (howto=260) at
 > /usr/src/sys/kern/kern_shutdown.c:409
 > > #2  0xc075e219 in panic (fmt=Variable "fmt" is not available.
 > > ) at /usr/src/sys/kern/kern_shutdown.c:563
 > > #3  0xc0a9766c in trap_fatal (frame=0xc884e934, eva=3621180904)
 > >     at /usr/src/sys/i386/i386/trap.c:899
 > > #4  0xc0a978f0 in trap_pfault (frame=0xc884e934, usermode=0,
 > eva=3621180904)
 > >     at /usr/src/sys/i386/i386/trap.c:812
 > > #5  0xc0a9829c in trap (frame=0xc884e934) at
 > /usr/src/sys/i386/i386/trap.c:490
 > > #6  0xc0a7e21b in calltrap () at
 > /usr/src/sys/i386/i386/exception.s:139
 > > #7  0xc0a952f6 in generic_bcopy () at
 > /usr/src/sys/i386/i386/support.s:498
 > > Previous frame inner to this frame (corrupt stack?)
 >
 > Unfortunately we need the rest of the stack.  Can you either try to
 > reproduce with DDB in the kernel and obtain a stack trace from there,
 > or if this is not possible then try recompiling the kernel with -O
 > instead of -O2 which tends to produce better stack traces.
 >
 > Kris
 >
 
 (kgdb) info registers
 eax            0x15e6c9c0       367446464
 ecx            0x1      1
 edx            0xfbc    4028
 ebx            0x4      4
 esp            0xc1c8c300       0xc1c8c300
 ebp            0xc884e9d8       0xc884e9d8
 esi            0xc1f00c28       -1041232856
 edi            0xd7d6d5e8       -673786392
 eip            0xc0a952f6       0xc0a952f6
 eflags         0x10202  66050
 cs             0x20     32
 ss             0xc1f00c00       -1041232896
 ds             0x28     40
 es             0x28     40
 fs             0x8      8
 gs             0x0      0
 
 (kgdb) x/12xw 0xc1c8c300
 0xc1c8c300:     0xcfcecdcc      0xd3d2d1d0      0xd7d6d5d4 
 0x00000024
 0xc1c8c310:     0xdfdedddc      0xe3e2e1e0      0xe7e6e5e4 
 0xebeae9e8
 0xc1c8c320:     0xefeeedfc      0xf3f2f1f0      0xf7f6f5f4 
 0xfbfaf9f8
 
 That's all needed info ?

From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To: misha saf <msaf1980@rambler.ru>
Cc: Kris Kennaway <kris@FreeBSD.org>, freebsd-net@FreeBSD.org, 
    bug-followup@FreeBSD.org
Subject: Re: misc/123066: kernel trap with ipsec
Date: Mon, 28 Apr 2008 08:22:20 +0000 (UTC)

 On Mon, 28 Apr 2008, misha saf wrote:
 
 Hi,
 
 > db> trace
 > Tracing pid 996 tid 100075 td 0xc1ed2210
 > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a
 > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at 
 > ipsec4_process_packet+0x28b
 
 
 Could you alos lookup which line of code this is?
 
 gdb /path/to/kernel.debug
 l *ipsec4_process_packet+0x28b
 
 
 > ip_ipsec_output(c886db04, c1f00924,c886dae4,c886db0c,...) at 
 > ip_ipsec_output+0x1a3
 > ip_output(c1c8b700,0,c886dac8,20,0,...) at ip_output+0x8ef
 > rip_output(c1c8b700,c1d3c630,1c8a8c0,0,...) at rip_output+0x35e
 > rip_send(c1d3c630,0,c1c8b700,c1bcebd0,0,...) at rip_send+0x5c
 > sosend_generic(c1d3c630,c1bcebd0,c886dbe8,c1c8b700,0,...) at 
 > sosend_generic+0x64
 > sosend(c1d3c630,c1bcebd0,c886dbe8,0,0,...) at sosend+0x3f
 > kern_sendit(c1ed2210,3,c886dc64,0,0,...) at kern_sendit+0x106
 > sendit(0,8050cec,0,c886dc64,0,0,...) at sendit+0xb1
 > sendto(c1ed2210,c886dcfc,18,c886dd38,c866dd2c,...) at sendto+0x48
 > syscall(c886dd38) at syscall+0x335
 > Xint0x80_syscall() at Xint0x80_syscall+0x20
 > ----syscal(133, FreeBSD ELF32, sendto), eip = 0x28156edf, esp = 0xbfbee7ec, 
 > ebp = 0xbfbee828
 > _______________________________________________
 > freebsd-net@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-net
 > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
 >
 
 -- 
 Bjoern A. Zeeb              Stop bit received. Insert coin for new game.

From: misha saf <msaf1980@rambler.ru>
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Cc: Kris Kennaway <kris@FreeBSD.org>, <freebsd-net@FreeBSD.org>, <bug-followup@FreeBSD.org>
Subject: Re: misc/123066: kernel trap with ipsec
Date: Mon, 28 Apr 2008 15:30:12 +0400

 * "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> [Mon, 28 Apr 2008 
 08:22:20 +0000 (UTC)]:
 > On Mon, 28 Apr 2008, misha saf wrote:
 >
 > Hi,
 >
 > > db> trace
 > > Tracing pid 996 tid 100075 td 0xc1ed2210
 > > generic_bcopy(c1c8b700, c1eeac80,0,14,9,...) at generic_bcopy+0x1a
 > > ipsec4_process_packet(c1c8b700, c1eeac80,20,0,c1f00924,...) at
 > > ipsec4_process_packet+0x28b
 >
 >
 > Could you alos lookup which line of code this is?
 >
 > gdb /path/to/kernel.debug
 > l *ipsec4_process_packet+0x28b
 >
 > --
 > Bjoern A. Zeeb              Stop bit received. Insert coin for new 
 game.
 
 (gdb) l *ipsec4_process_packet+0x28b
 0xc08fecab is in ipsec4_process_packet 
 (/usr/src/sys/netipsec/ipsec_output.c:486).
 481              */
 482             if (sav->tdb_xform->xf_type != XF_IP4) {
 483                     ip = mtod(m, struct ip *);
 484                     i = ip->ip_hl << 2;
 485                     off = offsetof(struct ip, ip_p);
 486                     error = (*sav->tdb_xform->xf_output)(m, isr, 
 NULL, i, off);
 487             } else {
 488                     error = ipsec_process_done(m, isr);
 489             }
 490             IPSECREQUEST_UNLOCK(isr);

From: Boris MARECHAL <boris.marechal@netasq.com>
To: bug-followup@FreeBSD.org, msaf1980@rambler.ru
Cc:  
Subject: Re: kern/123066: [ipsec] [panic] kernel trap with ipsec
Date: Tue, 13 Jan 2009 13:38:22 +0100

 --Apple-Mail-59-140032122
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed;
 	delsp=yes
 Content-Transfer-Encoding: 7bit
 
 seems linked with kern/124609: [ipsec] [panic] ipsec 'remainder too  
 big' panic with ping -s 3989
 --Apple-Mail-59-140032122
 Content-Disposition: attachment;
 	filename=smime.p7s
 Content-Type: application/pkcs7-signature;
 	name=smime.p7s
 Content-Transfer-Encoding: base64
 
 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFczCCBW8w
 ggRXoAMCAQICCnDGsUgWa/KQamQwDQYJKoZIhvcNAQEEBQAwgZExCzAJBgNVBAYTAkZSMQ0wCwYD
 VQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0g
 U2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRp
 b24gQXV0aG9yaXR5MB4XDTA4MDEwMzExMTIzNFoXDTEwMDEwMjExMTIzNFowgdQxCzAJBgNVBAYU
 AkZSMQ0wCwYDVQQIFAROb3JkMS4wLAYDVQQKFCVORVRBU1EgLSBTZWN1cmUgSW50ZXJuZXQgQ29u
 bmVjdGl2aXR5MScwJQYDVQQLFB5ORVRBU1EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxGjAYBgNV
 BAcUEVZpbGxlbmV1dmUgZCdBc2NxMRcwFQYDVQQDFA5Cb3JpcyBNQVJFQ0hBTDEoMCYGCSqGSIb3
 DQEJARYZYm9yaXMubWFyZWNoYWxAbmV0YXNxLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
 gYEA5GEoHCGB2ZhZx/I7Jq0hetpb+HPf2DKzieLoklK125o3RaSdHELZYnWB2Cvi6xRG5p+wmOl2
 ABo0qwxkve2QfdapHXppQo2aNVp++Z528p22ASaQzJnzBT9JTPVxMFopgMbMBgCmMrye6lpI3laW
 HEoCcIrfD4Vfus4i62JCwvMCAwEAAaOCAgYwggICMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFDIY
 DOPzGbqvpVtqkCbFSKhMMB2wMIG+BgNVHSMEgbYwgbOAFCcq6x3ZRNo6F3NqCSAgySWo+X+yoYGX
 pIGUMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBk
 J0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAl
 BgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBADAOBgNVHQ8BAf8EBAMCBeAw
 EQYJYIZIAYb4QgEBBAQDAgWgMIHNBgNVHR8EgcUwgcIwWqBYoFaGVGxkYXA6Ly9wa2kubmV0YXNx
 LmNvbS9jbj1md2NhLG91PWNhcyxvPW5ldGFzcSxkYz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M
 aXN0O2JpbmFyeTA4oDagNIYyaHR0cDovL2ludHJhbmV0Lm5ldGFzcS5jb20vaW50cmFuZXQvcGtp
 L25ldGFzcS5jcmwwKqAooCaGJGh0dHA6Ly93d3cubmV0YXNxLmNvbS9wa2kvbmV0YXNxLmNybDAf
 BglghkgBhvhCAQ0EEhYQVXNlciBDZXJ0aWZpY2F0ZTANBgkqhkiG9w0BAQQFAAOCAQEATwF5SdOw
 IoofZ5U2A16VEBBstYXne5mBItzdvsU8U2AlPXVXcr3/ZsvM0J9ivjKRge1LHVaOgChpxBN5aGhD
 QfKrWVYPALiqn8gQYWlJ5hmlJvxeAQOBU/hpLx9Y5bJ+3DQBjyDsghdRCL6/0Ym5Aj/VgEiTI/1t
 hgK6XNCRyonyTnArtGGhgwEqxOSSQ2zkUvg24DLhzSdUMtC+NydUyatJsHiqVuxuM22wVmCQCbjq
 M9hjGfae9zD1ieAPyeqEHmyCqwBeYblH3EXxnWwXRdKU2VzH1ZAJr5du5hEmlB5yCSEEqMP6joYJ
 w0QErq8VZxj1SlbEECPqrYz/muQDRzGCAxIwggMOAgEBMIGgMIGRMQswCQYDVQQGEwJGUjENMAsG
 A1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAt
 IFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0
 aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBqZDAJBgUrDgMCGgUAoIIBxzAYBgkqhkiG9w0BCQMxCwYJ
 KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAxMTMxMjM4MjJaMCMGCSqGSIb3DQEJBDEWBBQs
 /AQv77ynpgALw0zBqFApHWO1FDCBsQYJKwYBBAGCNxAEMYGjMIGgMIGRMQswCQYDVQQGEwJGUjEN
 MAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFT
 USAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZp
 Y2F0aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBqZDCBswYLKoZIhvcNAQkQAgsxgaOggaAwgZExCzAJ
 BgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwG
 A1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVU
 QVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgpwxrFIFmvykGpkMA0GCSqGSIb3DQEBAQUABIGA
 UFUnxt5ghZ6XqG+YvpeOozRotFeS2nQT0A8Dr8y6YYAxOOB0NZXxkDRY7ubWzCt0X8WDunfdu8Oe
 OO7aGRKMaPr3d3eZp4R2LPTQcf5Vgtu9+D2GyrlEMFeBohpy2PoVHNpIwc44y9r7b8+rvuojFhUo
 xDwp9XGQYm6Oi4kvpxcAAAAAAAA=
 
 --Apple-Mail-59-140032122--
Responsible-Changed-From-To: freebsd-net->vanhu 
Responsible-Changed-By: bz 
Responsible-Changed-When: Sat Jan 31 22:25:12 UTC 2009 
Responsible-Changed-Why:  
kern/124609 seems linked to this one and you handled that; could 
you check if both PRs are the same? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 
State-Changed-From-To: open->feedback 
State-Changed-By: vanhu 
State-Changed-When: Mon Mar 16 12:41:24 UTC 2009 
State-Changed-Why:  
Yes, it does really looks like 	kern/124609... 

Could you please try again with a 7.1-STABLE and confirm 
us it has been solved ? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 
State-Changed-From-To: feedback->closed 
State-Changed-By: vanhu 
State-Changed-When: Mon Mar 28 12:26:27 UTC 2011 
State-Changed-Why:  
No feedback for two years, and really looks like kern/124609, so 
has been fixed a while ago. 



http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 
>Unformatted:
