On Sun, 13 Nov 2005, Jason wrote:
If not, could you tell me the revisions of netinet/{tcp*,in_pcb}.c?[EMAIL PROTECTED] netinet $ pwd /usr/src/sys/netinet [EMAIL PROTECTED] netinet $ grep FreeBSD tcp*.c tcp_debug.c: * $FreeBSD: src/sys/netinet/tcp_debug.c,v 1.25.2.1 2005/01/31 23:26:36 imp Exp $ tcp_hostcache.c: * $FreeBSD: src/sys/netinet/tcp_hostcache.c,v 1.7.2.2 2005/02/13 18:18:33 rwatson Exp $ tcp_input.c: * $FreeBSD: src/sys/netinet/tcp_input.c,v 1.252.2.21 2005/07/05 19:25:42 ps Exp $ tcp_output.c: * $FreeBSD: src/sys/netinet/tcp_output.c,v 1.100.2.7 2005/05/04 13:59:26 andre Exp $ tcp_sack.c: * $FreeBSD: src/sys/netinet/tcp_sack.c,v 1.3.2.9 2005/04/19 18:37:26 ps Exp $ tcp_subr.c: * $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.201.2.21 2005/06/14 11:59:46 rwatson Exp $ tcp_syncache.c: * This software was developed for the FreeBSD Project by Jonathan Lemon tcp_syncache.c: * $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.66.2.2 2005/02/12 16:02:59 rwatson Exp $ tcp_timer.c: * $FreeBSD: src/sys/netinet/tcp_timer.c,v 1.66.2.6 2005/01/31 23:26:37 imp Exp $ tcp_usrreq.c: * $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.107.2.6 2005/06/14 12:01:03 rwatson Exp $ [EMAIL PROTECTED] netinet $ grep FreeBSD in_pcb.c * $FreeBSD: src/sys/netinet/in_pcb.c,v 1.153.2.10 2005/06/14 11:57:06 rwatson Exp $ [EMAIL PROTECTED] netinet $
Do you use IPv6 on this box, and in particular, TCP over IPv6? Do you use tcpdrop(8) to kill TCP connections?
There appears to be one bug fix since the revision you're using relating to tcpdrop(8) on TCP connections in the TIMEWAIT state that might result in a panic like the one you're seeing. The panic and trace look familiar, but without the panic message it's hard to confirm. If the machine has not already been reset, you might try showing the message buffer in DDB, which would have the effect of printing out the ring buffer that likely contains the panic message.
There have also been a number of fixes relating to raw sockets which may also apply to ipdivert related configurations, but I'm not sure they could lead to this particular panic easily. This strikes me a a pcb/tcp race of some sort.
Thanks, Robert N M Watson
thank you. JasonThanks, Robert N M Watsondb> AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 No such command db> trace Tracing pid 608 tid 100103 td 0xc2688480 kdb_enter(c07ec00d) at kdb_enter+0x2b panic(c07e8435,c07eb5f7,c07eb390,366,c299b434) at panic+0x127 mtx_destroy(c812457c,0) at mtx_destroy+0x5c in_pcbdetach(c81244ec,c616e6f0,c616e6f0,14,e830db44) at in_pcbdetach+0x1b4 tcp_close(c616e6f0,1,0,14,c616e6f0) at tcp_close+0x94 tcp_input(c3e3b200,14,6da8d318,0,0) at tcp_input+0x16df ip_input(c3e3b200) at ip_input+0x50d div_output(c2728288,c3e3b200,c263b620,0,e830dc0c) at div_output+0x1f7 div_send(c2728288,0,c3e3b200,c263b620,0) at div_send+0x3f sosend(c2728288,c263b620,e830dc40,c3e3b200,0) at sosend+0x5e7 kern_sendit(c2688480,3,e830dcbc,0,0) at kern_sendit+0x104 sendit(c2688480,3,e830dcbc,0,bfbeed98) at sendit+0x161 sendto(c2688480,e830dd04,6,6888be,292) at sendto+0x4d syscall(2f,bfbf002f,e830002f,1,28) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280d31cf, esp = 0xbfbeecdc, ebp = 0xbfbfed88 --- db> monsterjam jason $ uname -a FreeBSD monsterjam.org 5.4-STABLE FreeBSD 5.4-STABLE #2: Fri Aug 26 15:15:59 EDT 2005 monsterjam.org:/usr/src/sys/i386/compile/FREEBIE i386 thanks/regards, Jason _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"-- ================================================ | Jason Welsh [EMAIL PROTECTED] | | http://monsterjam.org DSS PGP: 0x5E30CC98 | | gpg key: http://monsterjam.org/gpg/ | ================================================
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
