From owner-freebsd-net@FreeBSD.ORG Sun Jun 27 15:17:35 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303691065670; Sun, 27 Jun 2010 15:17:35 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id C0E428FC20; Sun, 27 Jun 2010 15:17:34 +0000 (UTC) Received: from [192.168.2.132] (pool-96-238-218-232.snfcca.dsl-w.verizon.net [96.238.218.232]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5RFHB8F035418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Jun 2010 11:17:26 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277651853; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=H3oNFH+oylKQ+iBZtY74Z/B75D+eu29FfpWkxguBX4inz7IKVbUU9Gf UrySyaGeO6GjzrdSQpZwWPt7WvzGY+Q== Message-Id: <7F89D5E5-2641-4007-A00D-6AE78E3A2CA7@lakerest.net> From: Randall Stewart To: netch@netch.kiev.ua In-Reply-To: <20100626130013.GA1502@netch.kiev.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 27 Jun 2010 08:17:05 -0700 References: <20100626130013.GA1502@netch.kiev.ua> X-Mailer: Apple Mail (2.936) Cc: Michael Tuexen , net@freebsd.org Subject: Re: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 15:17:35 -0000 netch: I take it you have KTRACE enabled.. otherwise you would not hit this line ;-) When you did the sctp_sendmsg call what were the parameters on your user program? R On Jun 26, 2010, at 6:00 AM, Valentin Nechayev wrote: > Hi, > > FreeBSD 7.3-RELEASE i386 > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc05955ca > stack pointer = 0x28:0xe783bb94 > frame pointer = 0x28:0xe783bc80 > 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 = 7751 (spc) > trap number = 12 > panic: page fault > Uptime: 20d6h25m18s > Physical memory: 1910 MB > Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 > 26 10 > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc053a730 in boot (howto=260) at /usr/BSD/src/sys/kern/ > kern_shutdown.c:418 > #2 0xc053a931 in panic (fmt=Variable "fmt" is not available. > ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 > #3 0xc0762e4c in trap_fatal (frame=0xe783bb54, eva=0) > at /usr/BSD/src/sys/i386/i386/trap.c:950 > #4 0xc07630b0 in trap_pfault (frame=0xe783bb54, usermode=0, eva=0) > at /usr/BSD/src/sys/i386/i386/trap.c:863 > #5 0xc0763a92 in trap (frame=0xe783bb54) > at /usr/BSD/src/sys/i386/i386/trap.c:541 > #6 0xc074f81b in calltrap () at /usr/BSD/src/sys/i386/i386/ > exception.s:166 > #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > #8 0xc0763405 in syscall (frame=0xe783bd38) > at /usr/BSD/src/sys/i386/i386/trap.c:1101 > #9 0xc074f880 in Xint0x80_syscall () > at /usr/BSD/src/sys/i386/i386/exception.s:262 > #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > (kgdb) f 7 > #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > 2386 ktrsockaddr(to); > (kgdb) p to > $1 = (struct sockaddr *) 0x0 > (kgdb) l > 2381 error = getsock(td->td_proc->p_fd, uap->sd, &fp, > NULL); > 2382 if (error) > 2383 goto sctp_bad; > 2384 #ifdef KTRACE > 2385 if (KTRPOINT(td, KTR_STRUCT)) > 2386 ktrsockaddr(to); > 2387 #endif > 2388 > 2389 iov[0].iov_base = uap->msg; > 2390 iov[0].iov_len = uap->mlen; > > As seen from code, if uap->tolen is zero, `to' isn't initialized and > remains > NULL. This error is identical to -CURRENT. > > Seems this zero originates from libc code for sctp_send(): > > === > #ifdef SYS_sctp_generic_sendmsg > struct sockaddr *to = NULL; > > return (syscall(SYS_sctp_generic_sendmsg, sd, > data, len, to, 0, sinfo, flags)); > #else > === > > why after `to'? > > > -netch- > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Sun Jun 27 15:19:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01E631065675; Sun, 27 Jun 2010 15:19:29 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id A8D7E8FC19; Sun, 27 Jun 2010 15:19:28 +0000 (UTC) Received: from [192.168.2.132] (pool-96-238-218-232.snfcca.dsl-w.verizon.net [96.238.218.232]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5RFJNci035506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Jun 2010 11:19:26 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277651968; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=VByud13PsbskeW5lPQj1Oq9aByPjmgvpGiMNkZ1heVFSZ722QN/7ccf gZtiJTc/EoroRrLgcrs9QwjQAq3uJuQ== Message-Id: From: Randall Stewart To: Michael Tuexen In-Reply-To: <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 27 Jun 2010 08:19:17 -0700 References: <20100626130013.GA1502@netch.kiev.ua> <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: rrs@freebsd.org, netch@netch.kiev.ua, net@freebsd.org Subject: Re: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 15:19:29 -0000 Michael: You are to fast for me... of course I need to check multiple email bins on something like this.. and I need my coffee this AM ;-) R On Jun 26, 2010, at 12:30 PM, Michael Tuexen wrote: > On Jun 26, 2010, at 3:00 PM, Valentin Nechayev wrote: > >> Hi, >> >> FreeBSD 7.3-RELEASE i386 >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x0 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc05955ca >> stack pointer = 0x28:0xe783bb94 >> frame pointer = 0x28:0xe783bc80 >> 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 = 7751 (spc) >> trap number = 12 >> panic: page fault >> Uptime: 20d6h25m18s >> Physical memory: 1910 MB >> Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 >> 26 10 >> >> (kgdb) bt >> #0 doadump () at pcpu.h:196 >> #1 0xc053a730 in boot (howto=260) at /usr/BSD/src/sys/kern/ >> kern_shutdown.c:418 >> #2 0xc053a931 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 >> #3 0xc0762e4c in trap_fatal (frame=0xe783bb54, eva=0) >> at /usr/BSD/src/sys/i386/i386/trap.c:950 >> #4 0xc07630b0 in trap_pfault (frame=0xe783bb54, usermode=0, eva=0) >> at /usr/BSD/src/sys/i386/i386/trap.c:863 >> #5 0xc0763a92 in trap (frame=0xe783bb54) >> at /usr/BSD/src/sys/i386/i386/trap.c:541 >> #6 0xc074f81b in calltrap () at /usr/BSD/src/sys/i386/i386/ >> exception.s:166 >> #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, >> uap=0xe783bcfc) >> at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 >> #8 0xc0763405 in syscall (frame=0xe783bd38) >> at /usr/BSD/src/sys/i386/i386/trap.c:1101 >> #9 0xc074f880 in Xint0x80_syscall () >> at /usr/BSD/src/sys/i386/i386/exception.s:262 >> #10 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> (kgdb) f 7 >> #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, >> uap=0xe783bcfc) >> at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 >> 2386 ktrsockaddr(to); >> (kgdb) p to >> $1 = (struct sockaddr *) 0x0 >> (kgdb) l >> 2381 error = getsock(td->td_proc->p_fd, uap->sd, &fp, >> NULL); >> 2382 if (error) >> 2383 goto sctp_bad; >> 2384 #ifdef KTRACE >> 2385 if (KTRPOINT(td, KTR_STRUCT)) >> 2386 ktrsockaddr(to); >> 2387 #endif >> 2388 >> 2389 iov[0].iov_base = uap->msg; >> 2390 iov[0].iov_len = uap->mlen; >> >> As seen from code, if uap->tolen is zero, `to' isn't initialized >> and remains >> NULL. This error is identical to -CURRENT. > Thanks for reporting it. It is fixed in r209540 for current. > > Best regards > Michael >> >> Seems this zero originates from libc code for sctp_send(): >> >> === >> #ifdef SYS_sctp_generic_sendmsg >> struct sockaddr *to = NULL; >> >> return (syscall(SYS_sctp_generic_sendmsg, sd, >> data, len, to, 0, sinfo, flags)); >> #else >> === >> >> why after `to'? >> >> >> -netch- >> > > _______________________________________________ > 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Sun Jun 27 16:12:01 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8EBB1065673; Sun, 27 Jun 2010 16:12:01 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 16B598FC17; Sun, 27 Jun 2010 16:12:01 +0000 (UTC) Received: from [192.168.1.190] (p508FC348.dip.t-dialin.net [80.143.195.72]) by mail-n.franken.de (Postfix) with ESMTP id D80031C0B463D; Sun, 27 Jun 2010 18:11:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Sun, 27 Jun 2010 18:13:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100626130013.GA1502@netch.kiev.ua> <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> To: Randall Stewart X-Mailer: Apple Mail (2.1081) Cc: rrs@freebsd.org, netch@netch.kiev.ua, net@freebsd.org Subject: Re: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 16:12:02 -0000 On Jun 27, 2010, at 5:19 PM, Randall Stewart wrote: > Michael: >=20 > You are to fast for me... of course I need to check multiple email > bins on something like this.. and I need my coffee this AM ;-) I'll try to MFC the change to stable/8 and releng/8.1. I'll also see if it can go into stable/7 Best regards Michael >=20 > R > On Jun 26, 2010, at 12:30 PM, Michael Tuexen wrote: >=20 >> On Jun 26, 2010, at 3:00 PM, Valentin Nechayev wrote: >>=20 >>> Hi, >>>=20 >>> FreeBSD 7.3-RELEASE i386 >>>=20 >>> Fatal trap 12: page fault while in kernel mode >>> fault virtual address =3D 0x0 >>> fault code =3D supervisor read, page not present >>> instruction pointer =3D 0x20:0xc05955ca >>> stack pointer =3D 0x28:0xe783bb94 >>> frame pointer =3D 0x28:0xe783bc80 >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b >>> =3D DPL 0, pres 1, def32 1, gran 1 >>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >>> current process =3D 7751 (spc) >>> trap number =3D 12 >>> panic: page fault >>> Uptime: 20d6h25m18s >>> Physical memory: 1910 MB >>> Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 = 26 10 >>>=20 >>> (kgdb) bt >>> #0 doadump () at pcpu.h:196 >>> #1 0xc053a730 in boot (howto=3D260) at = /usr/BSD/src/sys/kern/kern_shutdown.c:418 >>> #2 0xc053a931 in panic (fmt=3DVariable "fmt" is not available. >>> ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 >>> #3 0xc0762e4c in trap_fatal (frame=3D0xe783bb54, eva=3D0) >>> at /usr/BSD/src/sys/i386/i386/trap.c:950 >>> #4 0xc07630b0 in trap_pfault (frame=3D0xe783bb54, usermode=3D0, = eva=3D0) >>> at /usr/BSD/src/sys/i386/i386/trap.c:863 >>> #5 0xc0763a92 in trap (frame=3D0xe783bb54) >>> at /usr/BSD/src/sys/i386/i386/trap.c:541 >>> #6 0xc074f81b in calltrap () at = /usr/BSD/src/sys/i386/i386/exception.s:166 >>> #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) >>> at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 >>> #8 0xc0763405 in syscall (frame=3D0xe783bd38) >>> at /usr/BSD/src/sys/i386/i386/trap.c:1101 >>> #9 0xc074f880 in Xint0x80_syscall () >>> at /usr/BSD/src/sys/i386/i386/exception.s:262 >>> #10 0x00000033 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>>=20 >>> (kgdb) f 7 >>> #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) >>> at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 >>> 2386 ktrsockaddr(to); >>> (kgdb) p to >>> $1 =3D (struct sockaddr *) 0x0 >>> (kgdb) l >>> 2381 error =3D getsock(td->td_proc->p_fd, uap->sd, &fp, = NULL); >>> 2382 if (error) >>> 2383 goto sctp_bad; >>> 2384 #ifdef KTRACE >>> 2385 if (KTRPOINT(td, KTR_STRUCT)) >>> 2386 ktrsockaddr(to); >>> 2387 #endif >>> 2388 >>> 2389 iov[0].iov_base =3D uap->msg; >>> 2390 iov[0].iov_len =3D uap->mlen; >>>=20 >>> As seen from code, if uap->tolen is zero, `to' isn't initialized and = remains >>> NULL. This error is identical to -CURRENT. >> Thanks for reporting it. It is fixed in r209540 for current. >>=20 >> Best regards >> Michael >>>=20 >>> Seems this zero originates from libc code for sctp_send(): >>>=20 >>> =3D=3D=3D >>> #ifdef SYS_sctp_generic_sendmsg >>> struct sockaddr *to =3D NULL; >>>=20 >>> return (syscall(SYS_sctp_generic_sendmsg, sd, >>> data, len, to, 0, sinfo, flags)); >>> #else >>> =3D=3D=3D >>>=20 >>> why after `to'? >>>=20 >>>=20 >>> -netch- >>>=20 >>=20 >> _______________________________________________ >> 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" >>=20 >=20 > ------------------------------ > Randall Stewart > 803-317-4952 (cell) >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 04:26:44 2010 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 9F4B5106566B; Mon, 28 Jun 2010 04:26:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 772008FC19; Mon, 28 Jun 2010 04:26:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5S4Qisk007378; Mon, 28 Jun 2010 04:26:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5S4QihI007374; Mon, 28 Jun 2010 04:26:44 GMT (envelope-from linimon) Date: Mon, 28 Jun 2010 04:26:44 GMT Message-Id: <201006280426.o5S4QihI007374@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148155: [vimage] Kernel panic with PF/IPFilter + VIMAGE kernel option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 04:26:44 -0000 Old Synopsis: Kernel panic with PF/IPFilter + VIMAGE kernel option New Synopsis: [vimage] Kernel panic with PF/IPFilter + VIMAGE kernel option Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 28 04:25:46 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148155 From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 04:27:37 2010 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 9A4AF1065677; Mon, 28 Jun 2010 04:27:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7297B8FC08; Mon, 28 Jun 2010 04:27:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5S4Rbwn007460; Mon, 28 Jun 2010 04:27:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5S4RbVn007456; Mon, 28 Jun 2010 04:27:37 GMT (envelope-from linimon) Date: Mon, 28 Jun 2010 04:27:37 GMT Message-Id: <201006280427.o5S4RbVn007456@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148078: [ath] wireless networking stops functioning X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 04:27:37 -0000 Old Synopsis: wireless networking stops functioning New Synopsis: [ath] wireless networking stops functioning Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 28 04:26:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148078 From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 04:30:07 2010 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 E27DA106566C; Mon, 28 Jun 2010 04:30:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA8CF8FC12; Mon, 28 Jun 2010 04:30:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5S4U7Sp008172; Mon, 28 Jun 2010 04:30:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5S4U7CB008168; Mon, 28 Jun 2010 04:30:07 GMT (envelope-from linimon) Date: Mon, 28 Jun 2010 04:30:07 GMT Message-Id: <201006280430.o5S4U7CB008168@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148112: [ath] Atheros 9285 cannot register with wifi AP (timeout) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 04:30:08 -0000 Old Synopsis: Atheros 9285 cannot register with wifi AP (timeout) New Synopsis: [ath] Atheros 9285 cannot register with wifi AP (timeout) Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 28 04:29:48 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148112 From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 04:31:13 2010 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 149231065676; Mon, 28 Jun 2010 04:31:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E07058FC1D; Mon, 28 Jun 2010 04:31:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5S4VCc8016769; Mon, 28 Jun 2010 04:31:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5S4VCgp016765; Mon, 28 Jun 2010 04:31:12 GMT (envelope-from linimon) Date: Mon, 28 Jun 2010 04:31:12 GMT Message-Id: <201006280431.o5S4VCgp016765@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148108: [bge] FreeBSD 7.2 or 8.0 does not recognize, 4.11 can identify the hardware device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 04:31:13 -0000 Old Synopsis: Freebsd 7.2 or 8.0 does not recognize, 4.11 can identify the hardware device New Synopsis: [bge] FreeBSD 7.2 or 8.0 does not recognize, 4.11 can identify the hardware device Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 28 04:30:15 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148108 From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 11:06:58 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51F3F1065674 for ; Mon, 28 Jun 2010 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7068FC1A for ; Mon, 28 Jun 2010 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5SB6wYp086594 for ; Mon, 28 Jun 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5SB6v0M086592 for freebsd-net@FreeBSD.org; Mon, 28 Jun 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jun 2010 11:06:57 GMT Message-Id: <201006281106.o5SB6v0M086592@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/148155 net [vimage] Kernel panic with PF/IPFilter + VIMAGE kernel o kern/148112 net [ath] Atheros 9285 cannot register with wifi AP (timeo o kern/148108 net [bge] FreeBSD 7.2 or 8.0 does not recognize, 4.11 can o kern/148078 net [ath] wireless networking stops functioning o kern/148013 net [rl] [patch] add WoL support to rl(4) o kern/148004 net [em] Inconsistent networking with em driver on FreeBSD o kern/147989 net [em] em Receive errors / CRC Errors / Alignment Errors o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147824 net [msk]: watchdog timeouts & Tx descriptor error o kern/147684 net [nfe] nVidia MCP55 driver blocks IPMI LAN on load o kern/147352 net [netinet] [patch] replace printf() with log() for "Lim o kern/147245 net [dummynet] dummynet skip traffic over configured limit o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/81095 net IPsec connection stops working if associated network i o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 448 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 16:43:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB428106564A for ; Mon, 28 Jun 2010 16:43:18 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 59D138FC15 for ; Mon, 28 Jun 2010 16:43:17 +0000 (UTC) Received: by fxm13 with SMTP id 13so1293439fxm.13 for ; Mon, 28 Jun 2010 09:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=CFL1laPS6M/8b249BY27Us/IOdRmQAwx7rNFA7VIkF8=; b=vTP/mHuZmxXqMDpADM0SQdUXN6z/K6xhl1WHrXRuuqFkmDZej7liRI+SFI0vcwj01m M9kGo7K7PW+cerQpFB/HRISZfCsDU1rwtXN8pTw6AsoTP+IsGassN3W5ZJWJnT6ORMUC awrwentk7aQsz+Hz2OcpgIVQ5WwrwSyTxCccM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=bIZEFkRK2lEgHh50c9WXUwBEuHGXZO21pZ0TUrwCJaMOIt0STneVcvcrnovExCmb4Z xqYp66CPa7KMbp1r9YNtJPe2ryhiLaMbsF3SEDeX5FJ17vfgxnnC3yo433fzzwYb6xXl PkgUedcWVR1oNvj/0DPy1lckjlsBRiInIdVkM= Received: by 10.87.41.18 with SMTP id t18mr7461100fgj.1.1277743393548; Mon, 28 Jun 2010 09:43:13 -0700 (PDT) Received: from beastie.lan ([195.60.174.86]) by mx.google.com with ESMTPS id y2sm45726167faj.15.2010.06.28.09.43.10 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 09:43:11 -0700 (PDT) Message-ID: <4C28D0D1.1050104@gmail.com> Date: Mon, 28 Jun 2010 19:41:53 +0300 From: Andrey Kosachenko User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [em] panic on fresh 9.0-current system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:43:18 -0000 Hi, Panic is observed on the fresh current system. It is constantly reproducible for me. STR: 1. connect laptop to the cable modem (DOCSIS) over ethernet; 2. laptop acquires IP address successfully (via DHCP); 3. doing any kind of network activity (wget, or even simply ping or nslookup) causes panic; According to the specs laptop (thinkpad t410) got the following NIC: Intel 82577LM Gigabit Network Connection (Hanksville), PHY, PCIe x1 More detailed info is the following: - # sysctl kern | egrep osrel kern.osrelease: 9.0-CURRENT kern.osreldate: 900014 - # uname -a FreeBSD beastie.lan 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Jun 28 11:50:10 EEST 2010 root@beastie.lan:/usr/obj/usr/src/sys/BEASTIE-20100628-01 amd64 - kgdb traceback: http://pastebin.org/363534 - dmesg output: http://pastebin.org/363541 - pciconf -lv: http://pastebin.org/363545 Could you, please, suggest how to deal with it. Please, let me know in case more info is required. Thanks in advance. -- Best regards, Andrey Kosachenko From owner-freebsd-net@FreeBSD.ORG Mon Jun 28 17:05:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A817D106566B for ; Mon, 28 Jun 2010 17:05:49 +0000 (UTC) (envelope-from carlson39@llnl.gov) Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by mx1.freebsd.org (Postfix) with ESMTP id 98F1F8FC1A for ; Mon, 28 Jun 2010 17:05:46 +0000 (UTC) X-Attachments: None Received: from bagua.llnl.gov (HELO [134.9.197.135]) ([134.9.197.135]) by smtp.llnl.gov with ESMTP; 28 Jun 2010 09:37:20 -0700 Message-ID: <4C28CFBE.6050903@llnl.gov> Date: Mon, 28 Jun 2010 09:37:18 -0700 From: Mike Carlson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Intel 10Gb nic (ix driver) and bizarre netstat output X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 17:05:49 -0000 I've got a 10Gb intel nic on a FreeBSD 8.0-p3/AMD64 system, using the ix driver: ix0: port 0xdce0-0xdcff mem 0xdf3a0000-0xdf3bffff,0xdf3c0000- 0xdf3fffff,0xdf39c000-0xdf39ffff irq 35 at device 0.0 on pci5 ix0: Using MSIX interrupts with 17 vectors ix0: [ITHREAD] ... ix0: Ethernet address: 00:1b:21:3f:b5:fc ix0: flags=8843 metric 0 mtu 9194 options=5bb ether 00:1b:21:3f:b5:fc inet 192.168.6.56 netmask 0xffffff00 broadcast 192.168.6.255 media: Ethernet autoselect (10Gbase-LR ) status: active What seems a bit odd is even when they system is 'idle', netstat reports a burst of outgoing data at an unpredictable interval: # netstat -I ix0 -w 1 input (ix0) output packets errs bytes packets errs bytes colls 1 0 496 1 0 18446744073709551436 0 1 0 252 1 0 0 0 28 0 19768 42 0 0 0 2 0 316 1 0 0 0 1 0 252 1 0 0 0 That large "burst" becomes more frequent if there is a reasonable network load on the server (like a NFS or Samba file transfer): # netstat -I ix0 -w 1 input (ix0) output packets errs bytes packets errs bytes colls 1 0 496 1 0 18446744073709551436 0 1652 0 1601979 2310 0 113716 0 337 0 521230 397 0 18446744073709437900 0 7562 0 276543 14580 0 21130649 0 33784 0 90243561 65289 0 6398014 0 34929 0 101041195 67431 0 18446744073708070746 0 36180 0 102019403 70112 0 932461 0 36337 0 104575965 70340 0 18446744073708694467 0 35933 0 104627291 69241 0 18446744073707935998 0 36498 0 104697232 70544 0 18446744073709094889 0 36580 0 106044621 70737 0 18446744073708270130 0 22934 0 80783509 44337 0 18446744073694340268 0 11469 0 34850586 22131 0 18446744073707453470 0 15661 0 40976798 30191 0 3816924 0 14885 0 40763491 28572 0 1794493 0 14554 0 47191162 28140 0 18446744073703905316 0 16620 0 43843276 32154 0 3277056 0 11800 0 38234856 22832 0 18446744073704976762 0 14640 0 37771926 28340 0 3720383 0 12230 0 37078829 23631 0 18446744073707401669 0 Is this normal? Or, is there something strange about my network environment, and if so, are there any suggestions to help me narrow down the issue? Thanks, Mike C From owner-freebsd-net@FreeBSD.ORG Tue Jun 29 05:05:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BBDF106566B for ; Tue, 29 Jun 2010 05:05:25 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-gy0-f196.google.com (mail-gy0-f196.google.com [209.85.160.196]) by mx1.freebsd.org (Postfix) with ESMTP id 51E8F8FC16 for ; Tue, 29 Jun 2010 05:05:24 +0000 (UTC) Received: by gyg8 with SMTP id 8so289325gyg.7 for ; Mon, 28 Jun 2010 22:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=qmukqLj4KMX3JrKPPhp7PoFaAdId7R2QBPhll3eJZuQ=; b=eMFfflNttoY8M9z4rFS4/uN8+g7Z7HJ/rkXInEdxBYoBr+JjA9bed73OIZn369Qcou OAZ2X903MqoiZEOBVhDqc5VtcrHNsFGpcvXubwtqccbmWpJUPXyQwOCsEhCTd2YE9dL9 mpfTkWRiTyHI4Sm/+Vcie5xpaI3kY9tZzanZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=cIU+14odEBk8Vc4CRy47TJ7mNwGqTiD2qhFodOsxQUcAe/h0xuPWRW3SzvciWT6sEs KE18sFZob2zdqH1jLIbgUNSujaXfzLnwar72jnm69dt+nKKM9jMnZhzpWbPDZwmM0Wrb nbv1OE2pvDRP8KfSulo1OkasQOhwrPOvUiLLQ= Received: by 10.100.16.4 with SMTP id 4mr7879158anp.2.1277787917377; Mon, 28 Jun 2010 22:05:17 -0700 (PDT) Received: from [190.48.253.199] ([190.48.253.199]) by mx.google.com with ESMTPS id w6sm39123360anb.23.2010.06.28.22.05.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 22:05:16 -0700 (PDT) Sender: Fernando Gont Message-ID: <4C296B1C.9050308@gont.com.ar> Date: Tue, 29 Jun 2010 00:40:12 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pta1@fastmail.us References: <1277340593.17629.1381616693@webmail.messagingengine.com> In-Reply-To: <1277340593.17629.1381616693@webmail.messagingengine.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPv6 and Anycast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 05:05:25 -0000 Hi, Paul, > I was wondering if someon knew if FreeBSD supports the creation of > anycast addresses and groups. Anycast is a routing artifact. There's nothing (syntactically) special about anycast when compared to unicast addresses. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Tue Jun 29 07:14:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC873106564A for ; Tue, 29 Jun 2010 07:14:06 +0000 (UTC) (envelope-from upakul@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 86A6D8FC15 for ; Tue, 29 Jun 2010 07:14:06 +0000 (UTC) Received: by iwn9 with SMTP id 9so531904iwn.13 for ; Tue, 29 Jun 2010 00:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=WS53e5H5Qqs3QV2Ztiv4480471bKEBMX9i2F3mA4d4U=; b=rZ84MPzTO/a3dK1QRpGWs/n+oWBViu9At+MjtXDRt68Z7jphs5VvpK0snCKozw+DtT OntY+jiJrcdoqfGsQXi/VLJDy/dUtC76S8knO+4gvHAlkZmp0rw9FqYe+WwcobQ0TR15 ONEDfxp1xi94KReR72FVmG44ZQwzrP9hJY+AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Z8nnG4P0tB7riQbvvBqaNxHIH/swoaHO3Crx9YVbGnl7Tb7P39xekSVZ589SrUP88M wx1/Xw/8Ksq7zC9pwSM3TCOIlSi7+tpUgrbKjIHRfPcw8//+A7hQkm5UqdYNtmyz2Zk9 4Aj7yKT4acfGp/JUXNm+/Bbd8xYipLMIThntI= MIME-Version: 1.0 Received: by 10.231.155.131 with SMTP id s3mr6593133ibw.2.1277794021660; Mon, 28 Jun 2010 23:47:01 -0700 (PDT) Received: by 10.231.15.139 with HTTP; Mon, 28 Jun 2010 23:47:01 -0700 (PDT) Date: Tue, 29 Jun 2010 12:17:01 +0530 Message-ID: From: Upakul Barkakaty To: freebsd-net@freebsd.org X-Mailman-Approved-At: Tue, 29 Jun 2010 11:18:48 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Freescale P4080 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 07:14:06 -0000 Hi all, Is the Freescale P4080's Data path acceleration architecture(DPAA) supported in FreeBSD? -- Regards, Upakul Barkakaty From owner-freebsd-net@FreeBSD.ORG Wed Jun 30 08:00:16 2010 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 E13AD106566C for ; Wed, 30 Jun 2010 08:00: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 B8C5F8FC12 for ; Wed, 30 Jun 2010 08:00:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5U80GpP016692 for ; Wed, 30 Jun 2010 08:00:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5U80GC5016691; Wed, 30 Jun 2010 08:00:16 GMT (envelope-from gnats) Date: Wed, 30 Jun 2010 08:00:16 GMT Message-Id: <201006300800.o5U80GC5016691@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dominic Fandrey Cc: Subject: Re: kern/144898: [wpi] [panic] wpi panics system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dominic Fandrey List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 08:00:17 -0000 The following reply was made to PR kern/144898; it has been noted by GNATS. From: Dominic Fandrey To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de Cc: Subject: Re: kern/144898: [wpi] [panic] wpi panics system Date: Wed, 30 Jun 2010 09:59:36 +0200 Just a followup. The device works when I reduce kern.hz to 200Hz. There's a 50% package loss, but TCP works fine as long as you can live with the increased latency. Of course you can forget about UDP. I can still reliably produce a panic by turning the hardware radio switch off while the device is up. Also the range of the device is really bad. I cannot establish a connection in the exact same spot where an atheros device works flawlessly and reports great reception. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-net@FreeBSD.ORG Wed Jun 30 17:01:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4581065673 for ; Wed, 30 Jun 2010 17:01:54 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4166B8FC20 for ; Wed, 30 Jun 2010 17:01:53 +0000 (UTC) Received: by gyf3 with SMTP id 3so702412gyf.13 for ; Wed, 30 Jun 2010 10:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QL7rQQ48BRvFLugYFDeX24cDfkLGL2HriueYEcaI8lA=; b=DhbvZd2yJlmB8HfoPoFhAJrrxLy4GMHuU6hRAyCrOrNQvJTLFkmQwGHZgr1LAChl+C iXwSkbZE0/4kue36yDQ0MTpGRFZEuNbcETEXNChA+brQjedoiJ6gMqtbqzS3pe4uiU1v ahYHYHJFefDRQXbSXkYfnB2pnBFYuup4NU578= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A7ZxnnBfmsBRz5ovPSNTMPMCySy2qNC7elLoHWKcMC32BryBBIsFu/ppBNPr+5C+HG cj35r1b8W60w8BoDsDbm9zkMp+zyA+nsSbNHXj2/oj1l7FpLVcziCr0yTEccOgGewAB2 6peUZe6yG6ydPK6fJpqiszd/0c/HE+4SJ1vR4= MIME-Version: 1.0 Received: by 10.101.2.32 with SMTP id e32mr11085298ani.73.1277917310749; Wed, 30 Jun 2010 10:01:50 -0700 (PDT) Received: by 10.101.13.8 with HTTP; Wed, 30 Jun 2010 10:01:50 -0700 (PDT) In-Reply-To: <4C28CFBE.6050903@llnl.gov> References: <4C28CFBE.6050903@llnl.gov> Date: Wed, 30 Jun 2010 13:01:50 -0400 Message-ID: From: Alexander Sack To: Mike Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel 10Gb nic (ix driver) and bizarre netstat output X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:01:54 -0000 M On Mon, Jun 28, 2010 at 12:37 PM, Mike Carlson wrote: > I've got a 10Gb intel nic on a FreeBSD 8.0-p3/AMD64 system, using the ix > driver: > > ix0: por= t > 0xdce0-0xdcff mem 0xdf3a0000-0xdf3bffff,0xdf3c0000- > 0xdf3fffff,0xdf39c000-0xdf39ffff irq 35 at device 0.0 on pci5 > ix0: Using MSIX interrupts with 17 vectors > ix0: [ITHREAD] > ... > ix0: Ethernet address: 00:1b:21:3f:b5:fc > > ix0: flags=3D8843 metric 0 mtu 91= 94 > > =A0options=3D5bb > =A0 =A0ether 00:1b:21:3f:b5:fc > =A0 =A0inet 192.168.6.56 netmask 0xffffff00 broadcast 192.168.6.255 > =A0 =A0media: Ethernet autoselect (10Gbase-LR ) > =A0 =A0status: active > > What seems a bit odd is even when they system is 'idle', netstat reports = a > burst of outgoing data at an unpredictable interval: > # netstat -I ix0 -w 1 > =A0 =A0 =A0 =A0 =A0 =A0input =A0 =A0 =A0 =A0 =A0(ix0) =A0 =A0 =A0 =A0 =A0= output > =A0 packets =A0errs =A0 =A0 =A0bytes =A0 =A0packets =A0errs =A0 =A0 =A0by= tes colls > =A0 =A0 =A0 =A0 1 =A0 =A0 0 =A0 =A0 =A0 =A0496 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 0 18446744073709551436 =A0 =A0 0 > =A0 =A0 =A0 =A0 1 =A0 =A0 0 =A0 =A0 =A0 =A0252 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0 =A0 =A0 =A028 =A0 =A0 0 =A0 =A0 =A019768 =A0 =A0 =A0 =A0 42 =A0 =A0 0= =A0 =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0 =A0 =A0 =A0 2 =A0 =A0 0 =A0 =A0 =A0 =A0316 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0 =A0 =A0 =A0 1 =A0 =A0 0 =A0 =A0 =A0 =A0252 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 0 > > That large "burst" becomes more frequent if there is a reasonable network > load on the server (like a NFS or Samba file transfer): > # netstat -I ix0 -w 1 > =A0 =A0 =A0 =A0 =A0 =A0input =A0 =A0 =A0 =A0 =A0(ix0) =A0 =A0 =A0 =A0 =A0= output > =A0 packets =A0errs =A0 =A0 =A0bytes =A0 =A0packets =A0errs =A0 =A0 =A0by= tes colls > =A0 =A0 =A0 =A0 1 =A0 =A0 0 =A0 =A0 =A0 =A0496 =A0 =A0 =A0 =A0 =A01 =A0 = =A0 0 18446744073709551436 =A0 =A0 0 > =A0 =A0 =A01652 =A0 =A0 0 =A0 =A01601979 =A0 =A0 =A0 2310 =A0 =A0 0 =A0 = =A0 113716 =A0 =A0 0 > =A0 =A0 =A0 337 =A0 =A0 0 =A0 =A0 521230 =A0 =A0 =A0 =A0397 =A0 =A0 0 184= 46744073709437900 =A0 =A0 0 > =A0 =A0 =A07562 =A0 =A0 0 =A0 =A0 276543 =A0 =A0 =A014580 =A0 =A0 0 =A0 2= 1130649 =A0 =A0 0 > =A0 =A0 33784 =A0 =A0 0 =A0 90243561 =A0 =A0 =A065289 =A0 =A0 0 =A0 =A063= 98014 =A0 =A0 0 > =A0 =A0 34929 =A0 =A0 0 =A0101041195 =A0 =A0 =A067431 =A0 =A0 0 184467440= 73708070746 =A0 =A0 0 > =A0 =A0 36180 =A0 =A0 0 =A0102019403 =A0 =A0 =A070112 =A0 =A0 0 =A0 =A0 9= 32461 =A0 =A0 0 > =A0 =A0 36337 =A0 =A0 0 =A0104575965 =A0 =A0 =A070340 =A0 =A0 0 184467440= 73708694467 =A0 =A0 0 > =A0 =A0 35933 =A0 =A0 0 =A0104627291 =A0 =A0 =A069241 =A0 =A0 0 184467440= 73707935998 =A0 =A0 0 > =A0 =A0 36498 =A0 =A0 0 =A0104697232 =A0 =A0 =A070544 =A0 =A0 0 184467440= 73709094889 =A0 =A0 0 > =A0 =A0 36580 =A0 =A0 0 =A0106044621 =A0 =A0 =A070737 =A0 =A0 0 184467440= 73708270130 =A0 =A0 0 > =A0 =A0 22934 =A0 =A0 0 =A0 80783509 =A0 =A0 =A044337 =A0 =A0 0 184467440= 73694340268 =A0 =A0 0 > =A0 =A0 11469 =A0 =A0 0 =A0 34850586 =A0 =A0 =A022131 =A0 =A0 0 184467440= 73707453470 =A0 =A0 0 > =A0 =A0 15661 =A0 =A0 0 =A0 40976798 =A0 =A0 =A030191 =A0 =A0 0 =A0 =A038= 16924 =A0 =A0 0 > =A0 =A0 14885 =A0 =A0 0 =A0 40763491 =A0 =A0 =A028572 =A0 =A0 0 =A0 =A017= 94493 =A0 =A0 0 > =A0 =A0 14554 =A0 =A0 0 =A0 47191162 =A0 =A0 =A028140 =A0 =A0 0 184467440= 73703905316 =A0 =A0 0 > =A0 =A0 16620 =A0 =A0 0 =A0 43843276 =A0 =A0 =A032154 =A0 =A0 0 =A0 =A032= 77056 =A0 =A0 0 > =A0 =A0 11800 =A0 =A0 0 =A0 38234856 =A0 =A0 =A022832 =A0 =A0 0 184467440= 73704976762 =A0 =A0 0 > =A0 =A0 14640 =A0 =A0 0 =A0 37771926 =A0 =A0 =A028340 =A0 =A0 0 =A0 =A037= 20383 =A0 =A0 0 > =A0 =A0 12230 =A0 =A0 0 =A0 37078829 =A0 =A0 =A023631 =A0 =A0 0 184467440= 73707401669 =A0 =A0 0 > > Is this normal? Or, is there something strange about my network environme= nt, > and if so, are there any suggestions to help me narrow down the issue? Have you tried running tcpdump -i ix0 to see what the 42 packets were when its "idle?" -aps From owner-freebsd-net@FreeBSD.ORG Wed Jun 30 17:07:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DDE3106567D; Wed, 30 Jun 2010 17:07:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8FFD8FC15; Wed, 30 Jun 2010 17:07:47 +0000 (UTC) Received: by gxk7 with SMTP id 7so701348gxk.13 for ; Wed, 30 Jun 2010 10:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WUDGMKOBF0xS0mv0c6VPBg4o7Q1a8Xn8pVAlkN4ZAak=; b=HXS4Gns/ylLMjMWfkRdQZ/V0Hl7Cs/vgj1ekCE7HB5TWzxkzvD7Z1IMdfg0OSVWg7+ l46Fskt7UiFwTmAhaKDWbTUDfSWN1HPieezLw14lZvc16Vxi6dnR3+5PH77eYK02ZBPZ e9roplgdCFb2NBSec9ylc0ViXPzl+AYAQWIT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hY7fD8ZnPXbSB6Fsy7SjBIZKogoj6YlQtPvCrQ7/Sb7AJPDZBwNTZSuMw13zeTYFOh 5HjdAeAqZHC0HUnso+QSq2F9wejpPUkSGnH1Xb9dRxwC4zQzQIk7wWBe/feeyWRtvQ5y yIRpXKU8AtfQaz0dlqD0eARQMo9Tplgq2I2VU= MIME-Version: 1.0 Received: by 10.229.214.77 with SMTP id gz13mr5282479qcb.168.1277917664259; Wed, 30 Jun 2010 10:07:44 -0700 (PDT) Received: by 10.229.250.197 with HTTP; Wed, 30 Jun 2010 10:07:44 -0700 (PDT) In-Reply-To: References: <82D310BD-48DE-4F79-84C6-356AB4F04C42@averesystems.com> Date: Wed, 30 Jun 2010 10:07:44 -0700 Message-ID: From: Jack Vogel To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Juli Mallett , freebsd-net@freebsd.org, Andrew Boyer Subject: Re: Dual-rate transceivers with ixgbe? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:07:48 -0000 The latest delta should give you what you need, sysctl dev.ix.0.advertise_gig=1 Jack On Thu, Jun 17, 2010 at 9:02 PM, Alexander Sack wrote: > On Thu, Jun 17, 2010 at 2:29 PM, Jack Vogel wrote: > > I have been working on this this morning, and I have a way of doing the > same > > thing > > you do with ethtool on Linux, I should have something in HEAD shortly. > This > > will > > let you "force" the advertisement of the link to 1G only. > > > > Jack, > > I am not sure if you want me to share! :) > > I have something that works with my 1G SFP (Finisar) which isnt > supported but works 100% of all my 1G SFPs. The problem is that the > driver assumes AN in a lot of spots even when connected to a passive > tap because if you have a multispeed fiber, negotion is always TRUE! > :( > > I guess my question is for the 1G only, I assume you turn AN off to > make this go (that seems to always work). > > Thanks! > > -aps > > PS I know, I know, 1G AN sucks....btw, thanks Jack for being > responsive to all of this stuff... > From owner-freebsd-net@FreeBSD.ORG Wed Jun 30 17:28:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152FD106566B for ; Wed, 30 Jun 2010 17:28:39 +0000 (UTC) (envelope-from carlson39@llnl.gov) Received: from nspiron-1.llnl.gov (nspiron-1.llnl.gov [128.115.41.81]) by mx1.freebsd.org (Postfix) with ESMTP id ED59A8FC16 for ; Wed, 30 Jun 2010 17:28:38 +0000 (UTC) X-Attachments: ix0-tcpdump.txt, netstat.txt Received: from bagua.llnl.gov (HELO [134.9.197.135]) ([134.9.197.135]) by nspiron-1.llnl.gov with ESMTP; 30 Jun 2010 10:28:38 -0700 Message-ID: <4C2B7EC4.2090005@llnl.gov> Date: Wed, 30 Jun 2010 10:28:36 -0700 From: Mike Carlson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Sack References: <4C28CFBE.6050903@llnl.gov> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040203050901030107050900" Cc: freebsd-net@freebsd.org Subject: Re: Intel 10Gb nic (ix driver) and bizarre netstat output X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:28:39 -0000 This is a multi-part message in MIME format. --------------040203050901030107050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/30/2010 10:01 AM, Alexander Sack wrote: > M > > On Mon, Jun 28, 2010 at 12:37 PM, Mike Carlson wrote: > >> I've got a 10Gb intel nic on a FreeBSD 8.0-p3/AMD64 system, using the ix >> driver: >> >> ix0: port >> 0xdce0-0xdcff mem 0xdf3a0000-0xdf3bffff,0xdf3c0000- >> 0xdf3fffff,0xdf39c000-0xdf39ffff irq 35 at device 0.0 on pci5 >> ix0: Using MSIX interrupts with 17 vectors >> ix0: [ITHREAD] >> ... >> ix0: Ethernet address: 00:1b:21:3f:b5:fc >> >> ix0: flags=8843 metric 0 mtu 9194 >> >> options=5bb >> ether 00:1b:21:3f:b5:fc >> inet 192.168.6.56 netmask 0xffffff00 broadcast 192.168.6.255 >> media: Ethernet autoselect (10Gbase-LR) >> status: active >> >> What seems a bit odd is even when they system is 'idle', netstat reports a >> burst of outgoing data at an unpredictable interval: >> # netstat -I ix0 -w 1 >> input (ix0) output >> packets errs bytes packets errs bytes colls >> 1 0 496 1 0 18446744073709551436 0 >> 1 0 252 1 0 0 0 >> 28 0 19768 42 0 0 0 >> 2 0 316 1 0 0 0 >> 1 0 252 1 0 0 0 >> >> That large "burst" becomes more frequent if there is a reasonable network >> load on the server (like a NFS or Samba file transfer): >> # netstat -I ix0 -w 1 >> input (ix0) output >> packets errs bytes packets errs bytes colls >> 1 0 496 1 0 18446744073709551436 0 >> 1652 0 1601979 2310 0 113716 0 >> 337 0 521230 397 0 18446744073709437900 0 >> 7562 0 276543 14580 0 21130649 0 >> 33784 0 90243561 65289 0 6398014 0 >> 34929 0 101041195 67431 0 18446744073708070746 0 >> 36180 0 102019403 70112 0 932461 0 >> 36337 0 104575965 70340 0 18446744073708694467 0 >> 35933 0 104627291 69241 0 18446744073707935998 0 >> 36498 0 104697232 70544 0 18446744073709094889 0 >> 36580 0 106044621 70737 0 18446744073708270130 0 >> 22934 0 80783509 44337 0 18446744073694340268 0 >> 11469 0 34850586 22131 0 18446744073707453470 0 >> 15661 0 40976798 30191 0 3816924 0 >> 14885 0 40763491 28572 0 1794493 0 >> 14554 0 47191162 28140 0 18446744073703905316 0 >> 16620 0 43843276 32154 0 3277056 0 >> 11800 0 38234856 22832 0 18446744073704976762 0 >> 14640 0 37771926 28340 0 3720383 0 >> 12230 0 37078829 23631 0 18446744073707401669 0 >> >> Is this normal? Or, is there something strange about my network environment, >> and if so, are there any suggestions to help me narrow down the issue? >> > Have you tried running tcpdump -i ix0 to see what the 42 packets were > when its "idle?" > > -aps > > I'm pretty sure that was ssh traffic, I don't have a serial or direct console access so unfortunately I have to ssh in. Attached is the output of netstat and 'tcpdump -i ix0'; I see what I would consider 'normal' network traffic (ssh, syslog, and dns)... Thanks for the reply! Mike C --------------040203050901030107050900 Content-Type: text/plain; name="ix0-tcpdump.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ix0-tcpdump.txt" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ix0, link-type EN10MB (Ethernet), capture size 96 bytes 10:19:48.070835 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 197801402, win 130, options [nop,nop,TS val 3976951004 ecr 137645182], length 192 10:19:48.071021 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 192, win 603, options [nop,nop,TS val 137645183 ecr 3976951004], length 0 10:19:48.150740 IP server-a.local.syslog > st-splunk.local.syslog: SYSLOG kernel.info, length: 56 10:19:48.908236 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1203398615, win 130, options [nop,nop,TS val 3563735615 ecr 137645166], length 112 10:19:48.908435 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 112, win 501, options [nop,nop,TS val 137645266 ecr 3563735615], length 0 10:19:49.071568 IP server-a.local.12553 > dns-a.local.domain: 4296+ PTR? 135.197.9.10.in-addr.arpa. (44) 10:19:49.072319 IP dns-a.local.domain > server-a.local.12553: 4296* 1/3/3 (184) 10:19:49.072427 IP server-a.local.28865 > dns-a.local.domain: 4297+ PTR? 56.6.115.192.in-addr.arpa. (43) 10:19:49.073102 IP dns-a.local.domain > server-a.local.28865: 4297* 1/3/3 (185) 10:19:49.073194 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976953009 ecr 137645183], length 208 10:19:49.073212 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976953009 ecr 137645183], length 192 10:19:49.073218 IP server-a.local.34630 > dns-a.local.domain: 4298+ PTR? 208.132.115.192.in-addr.arpa. (46) 10:19:49.073413 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 400, win 603, options [nop,nop,TS val 137645283 ecr 3976953009], length 0 10:19:49.073445 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 592, win 602, options [nop,nop,TS val 137645283 ecr 3976953009], length 0 10:19:49.073950 IP dns-a.local.domain > server-a.local.34630: 4298* 1/3/3 (190) 10:19:49.074015 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976953010 ecr 137645283], length 144 10:19:49.074042 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976953010 ecr 137645283], length 352 10:19:49.074186 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 736, win 603, options [nop,nop,TS val 137645283 ecr 3976953010], length 0 10:19:49.074230 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 1088, win 603, options [nop,nop,TS val 137645283 ecr 3976953010], length 0 10:19:49.208700 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:1e:7a:7b:5f:80.8002, length 43 10:19:49.908766 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563737616 ecr 137645266], length 112 10:19:49.908969 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 224, win 501, options [nop,nop,TS val 137645366 ecr 3563737616], length 0 10:19:50.074477 IP server-a.local.57614 > dns-a.local.domain: 4299+ PTR? 1.54.115.192.in-addr.arpa. (43) 10:19:50.075271 IP dns-a.local.domain > server-a.local.57614: 4299* 1/3/3 (177) 10:19:50.075356 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976955013 ecr 137645283], length 160 10:19:50.075376 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976955013 ecr 137645283], length 240 10:19:50.075399 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976955013 ecr 137645283], length 432 10:19:50.075424 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976955013 ecr 137645283], length 560 10:19:50.075552 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 1248, win 603, options [nop,nop,TS val 137645383 ecr 3976955013], length 0 10:19:50.075584 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 1488, win 603, options [nop,nop,TS val 137645383 ecr 3976955013], length 0 10:19:50.075617 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 1920, win 603, options [nop,nop,TS val 137645383 ecr 3976955013], length 0 10:19:50.075626 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976955013 ecr 137645383], length 1152 10:19:50.075649 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 2480, win 603, options [nop,nop,TS val 137645383 ecr 3976955013], length 0 10:19:50.075861 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 3632, win 603, options [nop,nop,TS val 137645383 ecr 3976955013], length 0 10:19:50.376071 ARP, Request who-has client-bm1.local tell dsr01.192-115-6-254.local, length 46 10:19:50.529226 ARP, Request who-has nde-jessie.local tell dsr01.192-115-6-254.local, length 46 10:19:50.740332 IP nde-hp4600.local.1230 > 255.255.255.255.ntp: NTPv3, Client, length 48 10:19:50.756626 ARP, Request who-has server-b.local tell dsr01.192-115-6-254.local, length 46 10:19:50.908290 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563739615 ecr 137645366], length 112 10:19:50.908483 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 336, win 501, options [nop,nop,TS val 137645466 ecr 3563739615], length 0 10:19:51.076239 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976957014 ecr 137645383], length 240 10:19:51.076261 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976957015 ecr 137645383], length 192 10:19:51.076280 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976957015 ecr 137645383], length 656 10:19:51.076331 IP server-a.local.61895 > dns-a.local.domain: 4300+ PTR? 30.6.115.192.in-addr.arpa. (43) 10:19:51.076456 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 3872, win 603, options [nop,nop,TS val 137645483 ecr 3976957014], length 0 10:19:51.076488 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 4720, win 603, options [nop,nop,TS val 137645483 ecr 3976957015], length 0 10:19:51.076497 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976957015 ecr 137645483], length 864 10:19:51.076716 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 5584, win 603, options [nop,nop,TS val 137645483 ecr 3976957015], length 0 10:19:51.076991 IP dns-a.local.domain > server-a.local.61895: 4300* 1/3/3 (191) 10:19:51.077064 IP server-a.local.45046 > dns-a.local.domain: 4301+ PTR? 254.6.115.192.in-addr.arpa. (44) 10:19:51.077727 IP dns-a.local.domain > server-a.local.45046: 4301* 1/3/3 (198) 10:19:51.077791 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3976957018 ecr 137645483], length 144 10:19:51.077818 IP server-a.local.27651 > dns-a.local.domain: 4302+ PTR? 50.6.115.192.in-addr.arpa. (43) 10:19:51.077972 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 5728, win 603, options [nop,nop,TS val 137645483 ecr 3976957018], length 0 10:19:51.078024 IP client-a.local.59985 > server-a.local.ssh: Flags [P.], ack 5728, win 603, options [nop,nop,TS val 137645483 ecr 3976957018], length 48 10:19:51.078033 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976957018 ecr 137645483], length 0 10:19:51.078606 IP dns-a.local.domain > server-a.local.27651: 4302* 1/3/3 (188) 10:19:51.078665 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976957019 ecr 137645483], length 144 10:19:51.078693 IP server-a.local.34496 > dns-a.local.domain: 4303+ PTR? 255.255.255.255.in-addr.arpa. (46) 10:19:51.079484 IP dns-a.local.domain > server-a.local.34496: 4303* 0/1/0 (81) 10:19:51.079558 IP server-a.local.47414 > dns-a.local.domain: 4304+ PTR? 137.6.115.192.in-addr.arpa. (44) 10:19:51.080222 IP dns-a.local.domain > server-a.local.47414: 4304* 1/3/3 (189) 10:19:51.080285 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976957023 ecr 137645483], length.192 10:19:51.080299 IP server-a.local.18748 > dns-a.local.domain: 4305+ PTR? 14.6.115.192.in-addr.arpa. (43) 10:19:51.080479 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 6000, win 603, options [nop,nop,TS val 137645484 ecr 3976957019], length 0 10:19:51.080952 IP dns-a.local.domain > server-a.local.18748: 4305* 1/3/3 (188) 10:19:51.081017 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976957024 ecr 137645484], length 144 10:19:51.081032 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976957024 ecr 137645484], length 192 10:19:51.081044 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976957024 ecr 137645484], length 192 10:19:51.081237 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 6336, win 603, options [nop,nop,TS val 137645484 ecr 3976957024], length 0 10:19:51.120977 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 6528, win 603, options [nop,nop,TS val 137645488 ecr 3976957024], length 0 10:19:51.208962 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:1e:7a:7b:5f:80.8002, length 43 10:19:51.908848 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563741616 ecr 137645466], length 112 10:19:51.909044 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 448, win 501, options [nop,nop,TS val 137645566 ecr 3563741616], length 0 10:19:52.081817 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976959026 ecr 137645488], length 192 10:19:52.081833 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976959026 ecr 137645488], length 352 10:19:52.081849 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976959026 ecr 137645488], length 464 10:19:52.081865 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976959026 ecr 137645488], length 432 10:19:52.082037 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 7072, win 601, options [nop,nop,TS val 137645584 ecr 3976959026], length 0 10:19:52.082065 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 7968, win 600, options [nop,nop,TS val 137645584 ecr 3976959026], length 0 10:19:52.082071 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976959026 ecr 137645584], length 1448 10:19:52.082322 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 9416, win 603, options [nop,nop,TS val 137645584 ecr 3976959026], length 0 10:19:52.082330 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976959027 ecr 137645584], length 1448 10:19:52.082334 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976959027 ecr 137645584], length 992 10:19:52.082588 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 10864, win 603, options [nop,nop,TS val 137645584 ecr 3976959027], length 0 10:19:52.082620 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 11856, win 599, options [nop,nop,TS val 137645584 ecr 3976959027], length 0 10:19:52.908404 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563743615 ecr 137645566], length 112 10:19:52.908605 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 560, win 501, options [nop,nop,TS val 137645666 ecr 3563743615], length 0 10:19:53.082501 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976961027 ecr 137645584], length 192 10:19:53.082520 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976961027 ecr 137645584], length 192 10:19:53.082539 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976961027 ecr 137645584], length 656 10:19:53.082723 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 12048, win 603, options [nop,nop,TS val 137645684 ecr 3976961027], length 0 10:19:53.082755 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack.19296, win 597, options [nop,nop,TS val 137645684 ecr 3976961027], length 0 10:19:53.082765 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976961027 ecr 137645684], length 1376 10:19:53.083010 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 14272, win 603, options [nop,nop,TS val 137645684 ecr 3976961027], length 0 10:19:53.209170 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:1e:7a:7b:5f:80.8002, length 43 10:19:53.908921 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563745616 ecr 137645666], length 112 10:19:53.909122 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 672, win 501, options [nop,nop,TS val 137645766 ecr 3563745616], length 0 10:19:54.083274 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976963028 ecr 137645684], length 192 10:19:54.083290 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976963028 ecr 137645684], length 352 10:19:54.083307 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976963028 ecr 137645684], length 352 10:19:54.083322 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976963028 ecr 137645684], length 464 10:19:54.083477 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 14464, win 603, options [nop,nop,TS val 137645784 ecr 3976963028], length 0 10:19:54.083487 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976963029 ecr 137645784], length 352 10:19:54.083510 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 15168, win 603, options [nop,nop,TS val 137645784 ecr 3976963028], length 0 10:19:54.083542 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 15632, win 600, options [nop,nop,TS val 137645784 ecr 3976963028], length 0 10:19:54.083672 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 15984, win 603, options [nop,nop,TS val 137645784 ecr 3976963029], length 0 10:19:54.908455 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563747615 ecr 137645766], length 112 10:19:54.908648 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 784, win 501, options [nop,nop,TS val 137645866 ecr 3563747615], length 0 10:19:55.083805 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976965029 ecr 137645784], length 192 10:19:55.083827 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976965029 ecr 137645784], length 352 10:19:55.083848 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976965029 ecr 137645784], length 512 10:19:55.084019 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 16176, win 603, options [nop,nop,TS val 137645884 ecr 3976965029], length 0 10:19:55.084050 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 17040, win 597, options [nop,nop,TS val 137645884 ecr 3976965029], length 0 10:19:55.084058 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976965030 ecr 137645884], length 864 10:19:55.084275 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 17904, win 603, options [nop,nop,TS val 137645884 ecr 3976965030], length 0 10:19:55.209409 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8001.00:1e:7a:7b:5f:80.8002, length 43 10:19:55.725648 IP server-a.local.39599 > dns-a.local.domain: 54266+ PTR? 30.47.115.192.in-addr.arpa. (44) 10:19:55.726563 IP dns-a.local.domain > server-a.local.39599: 54266* 1/3/3 (187) 10:19:55.726679 IP server-a.local.25462 > dns-a.local.domain: 54267+ A? client-c.local. (35) 10:19:55.727382 IP dns-a.local.domain > server-a.local.25462: 54267* 1/3/3 A.192.115.47.30 (163) 10:19:55.727427 IP server-a.local.65084 > dns-a.local.domain: 54268+ AAAA? client-c.local. (35) 10:19:55.728453 IP dns-a.local.domain > server-a.local.65084: 54268* 0/1/0 (87) 10:19:55.735204 IP server-a.local.37443 > dns-a.local.domain: 54269+ A? SERVER-A.local. (34) 10:19:55.735800 IP dns-a.local.domain > server-a.local.37443: 54269* 1/3/3 A.192.115.6.56 (162) 10:19:55.736691 IP server-a.local.18091 > dns-a.local.domain: 54270+ A? the-lab.local. (34) 10:19:55.737518 IP dns-a.local.domain > server-a.local.18091: 54270 3/3/3 A.192.115.3.5,[|domain] 10:19:55.737560 IP server-a.local.46829 > dns-a.local.domain: 54271+ AAAA? the-lab.local. (34) 10:19:55.739453 IP dns-a.local.domain > server-a.local.46829: 54271 0/1/0 (97) 10:19:55.739554 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [S], seq 3518086552, win 65535, options [mss 9154,nop,wscale 9,sackOK,TS val 988958817 ecr 0], length 0 10:19:55.739821 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [S.], seq 1510212780, ack 3518086553, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 58006692 ecr 988958817], length 0 10:19:55.739837 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 1, win 130, options [nop,nop,TS val 988958817 ecr 58006692], length 0 10:19:55.739856 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 1, win 130, options [nop,nop,TS val 988958817 ecr 58006692], length 31 10:19:55.740230 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 32, win 260, options [nop,nop,TS val 58006692 ecr 988958817], length 46 10:19:55.740242 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 47, win 130, options [nop,nop,TS val 988958818 ecr 58006692], length 0 10:19:55.740407 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 47, win 130, options [nop,nop,TS val 988958818 ecr 58006692], length 136 10:19:55.740922 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [.], ack 168, win 259, options [nop,nop,TS val 58006692 ecr 988958818], length 1448 10:19:55.740934 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 1495, win 127, options [nop,nop,TS val 988958819 ecr 58006692], length 0 10:19:55.740952 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [.], ack 168, win 259, options [nop,nop,TS val 58006692 ecr 988958818], length 1448 10:19:55.740960 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 2943, win 124, options [nop,nop,TS val 988958820 ecr 58006692], length 0 10:19:55.7.1929 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [.], ack 168, win 259, options [nop,nop,TS val 58006692 ecr 988958820], length 1448 10:19:55.741299 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 4391, win 127, options [nop,nop,TS val 988958820 ecr 58006692], length 0 10:19:55.741322 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [.], ack 168, win 259, options [nop,nop,TS val 58006692 ecr 988958820], length 1902 10:19:55.741331 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 6293, win 126, options [nop,nop,TS val 988958820 ecr 58006692], length 0 10:19:55.742175 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 6293, win 130, options [nop,nop,TS val 988958822 ecr 58006692], length 338 10:19:55.747240 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 506, win 258, options [nop,nop,TS val 58006692 ecr 988958822], length 59 10:19:55.747251 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 6352, win 129, options [nop,nop,TS val 988958832 ecr 58006692], length 0 10:19:55.747345 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 6352, win 130, options [nop,nop,TS val 988958832 ecr 58006692], length 170 10:19:55.748631 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 676, win 257, options [nop,nop,TS val 58006692 ecr 988958832], length 53 10:19:55.748642 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 6405, win 129, options [nop,nop,TS val 988958835 ecr 58006692], length 0 10:19:55.748697 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 6405, win 130, options [nop,nop,TS val 988958835 ecr 58006692], length 122 10:19:55.749040 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 798, win 257, options [nop,nop,TS val 58006692 ecr 988958835], length 789 10:19:55.749052 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7194, win.192, options [nop,nop,TS val 988958836 ecr 58006692], length 0 10:19:55.749143 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7194, win 130, options [nop,nop,TS val 988958836 ecr 58006692], length 266 10:19:55.749586 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 1064, win 256, options [nop,nop,TS val 58006692 ecr 988958836], length 149 10:19:55.749598 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7343, win 129, options [nop,nop,TS val 988958837 ecr 58006692], length 0 10:19:55.749813 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7343, win 130, options [nop,nop,TS val 988958837 ecr 58006692], length 778 10:19:55.750364 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 1842, win 260, options [nop,nop,TS val 58006692 ecr 988958837], length 149 10:19:55.750376 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7492, win 129, options [nop,nop,TS val 988958838 ecr 58006692], length 0 10:19:55.750483 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7492, win 130, options [nop,nop,TS val 988958839 ecr 58006692], length 298 10:19:55.750960 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 2140, win 259, options [nop,nop,TS val 58006692 ecr 988958839], length 149 10:19:55.750972 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7641, win 129, options [nop,nop,TS val 988958840 ecr 58006692], length 0 10:19:55.751642 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7641, win 130, options [nop,nop,TS val 988958841 ecr 58006692], length 778 10:19:55.752168 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 2918, win 255, options [nop,nop,TS val 58006692 ecr 988958841], length 149 10:19:55.752180 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7790, win 129, options [nop,nop,TS val 988958842 ecr 58006692], length 0 10:19:55.752278 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7790, win 130, options [nop,nop,TS val 988958842 ecr 58006692], length 298 10:19:55.752709 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 3216, win 254, options [nop,nop,TS val 58006692 ecr 988958842], length 149 10:19:55.752721 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 7939, win 129, options [nop,nop,TS val 988958843 ecr 58006692], length 0 10:19:55.753063 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 7939, win 130, options [nop,nop,TS val 988958844 ecr 58006692], length 778 10:19:55.753584 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 3994, win 260, options [nop,nop,TS val 58006692 ecr 988958844], length 149 10:19:55.753595 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 8088, win 129, options [nop,nop,TS val 988958845 ecr 58006692], length 0 10:19:55.753687 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 8088, win 130, options [nop,nop,TS val 988958845 ecr 58006692], length 298 10:19:55.754053 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 4292, win 259, options [nop,nop,TS val 58006692 ecr 988958845], length 149 10:19:55.754065 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 8237, win 129, options [nop,nop,TS val 988958846 ecr 58006692], length 0 10:19:55.754912 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 8237, win 130, options [nop,nop,TS val 988958847 ecr 58006692], length 778 10:19:55.755329 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 5070, win 255, options [nop,nop,TS val 58006692 ecr 988958847], length 149 10:19:55.755341 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 8386, win 129, options [nop,nop,TS val 988958848 ecr 58006692], length 0 10:19:55.755430 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [P.], ack 8386, win 130, options [nop,nop,TS val 988958848 ecr 58006692], length 298 10:19:55.755819 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [P.], ack 5368, win 254, options [nop,nop,TS val 58006692 ecr 988958848], length 149 10:19:55.755831 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [.], ack 8535, win 129, options [nop,nop,TS val 988958849 ecr 58006692], length 0 10:19:55.760781 IP server-a.local.49251 > adinst-1.the-lab.local.3268: Flags [F.], seq 5368, ack 8535, win 130, options [nop,nop,TS val 988958859 ecr 58006692], length 0 10:19:55.761060 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [.], ack 5369, win 254, options [nop,nop,TS val 58006694 ecr 988958859], length 0 10:19:55.761093 IP adinst-1.the-lab.local.3268 > server-a.local.49251: Flags [R.], seq 8535, ack 5369, win 0, length 0 10:19:55.909066 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 1, win 130, options [nop,nop,TS val 3563749616 ecr 137645866], length 112 10:19:55.909268 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 896, win 501, options [nop,nop,TS val 137645966 ecr 3563749616], length 0 10:19:56.084137 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967030 ecr 137645884], length 192 10:19:56.084154 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967030 ecr 137645884], length 512 10:19:56.084171 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967030 ecr 137645884], length 512 10:19:56.084264 IP server-a.local.52183 > dns-a.local.domain: 4306+ PTR? 5.3.115.192.in-addr.arpa. (42) 10:19:56.084354 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 18096, win 603, options [nop,nop,TS val 137645984 ecr 3976967030], length 0 10:19:56.084385 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 19120, win 599, options [nop,nop,TS val 137645984 ecr 3976967030], length 0 10:19:56.084393 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976967030 ecr 137645984], length 1448 10:19:56.084398 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967030 ecr 137645984], length 152 10:19:56.084648 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 20568, win 603, options [nop,nop,TS val 137645984 ecr 3976967030], length 0 10:19:56.084678 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 20720, win 603, options [nop,nop,TS val 137645984 ecr 3976967030], length 0 10:19:56.085057 IP dns-a.local.domain > server-a.local.52183: 4306* 1/3/3 PTR[|domain] 10:19:56.085133 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 224 10:19:56.085160 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 416 10:19:56.085183 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 368 10:19:56.085211 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 704 10:19:56.085232 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 880 10:19:56.085249 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 544 10:19:56.085268 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 544 10:19:56.085285 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 544 10:19:56.085310 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 20944, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085366 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 21360, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085399 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 21728, win 601, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085406 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 1448 10:19:56.085432 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 22432, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085438 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 1448 10:19:56.085483 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 23312, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085489 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 1448 10:19:56.085520 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 24944, win 599, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085528 IP server-a.local.ssh > client-a.local.59985: Flags [.], ack 49, win 130, options [nop,nop,TS val 3976967032 ecr 137645984], length 1448 10:19:56.085533 IP server-a.local.ssh > client-a.local.59985: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3976967033 ecr 137645984], length 464 10:19:56.085657 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 26392, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085690 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 27840, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085739 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 29288, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.085800 IP client-a.local.59985 > server-a.local.ssh: Flags [.], ack 31200, win 603, options [nop,nop,TS val 137645984 ecr 3976967032], length 0 10:19:56.468552 IP 192.168.2.1.netbios-ns > 192.168.2.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 10:19:56.641949 IP client-a.local.42207 > server-a.local.ssh: Flags [P.], ack 896, win 501, options [nop,nop,TS val 137646040 ecr 3563749616], length 48 10:19:56.641964 IP server-a.local.ssh > client-a.local.42207: Flags [.], ack 49, win 130, options [nop,nop,TS val 3563751081 ecr 137646040], length 0 10:19:56.642002 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3563751081 ecr 137646040], length 48 10:19:56.64.192 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3563751082 ecr 137646040], length 48 10:19:56.642174 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 944, win 501, options [nop,nop,TS val 137646040 ecr 3563751081], length 0 10:19:56.642228 IP server-a.local.ssh > client-a.local.42207: Flags [P.], ack 49, win 130, options [nop,nop,TS val 3563751082 ecr 137646040], length 48 10:19:56.642292 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 992, win 501, options [nop,nop,TS val 137646040 ecr 3563751082], length 0 10:19:56.642385 IP client-a.local.42207 > server-a.local.ssh: Flags [.], ack 1040, win 501, options [nop,nop,TS val 137646040 ecr 3563751082], length 0 ^C 228 packets captured 262 packets received by filter 0 packets dropped by kernel --------------040203050901030107050900 Content-Type: text/plain; name="netstat.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netstat.txt" # netstat -I ix0 -w 1 input (ix0) output packets errs bytes packets errs bytes colls 2 0 768 1 0 18446744073709551240 0 5 0 616 5 0 376 0 4 0 906 5 0 160 0 9 0 1825 8 0 883 0 11 0 2550 7 0 1540 0 17 0 5198 18 0 1178 0 8 0 4917 8 0 1653 0 6 0 6488 5 0 18446744073709548506 0 6 0 3298 6 0 18446744073709550978 0 33 0 13661 45 0 8229 0 ^C --------------040203050901030107050900-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 1 02:01:02 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C140F106566C for ; Thu, 1 Jul 2010 02:01:02 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F50F8FC17 for ; Thu, 1 Jul 2010 02:01:02 +0000 (UTC) Received: by qwg5 with SMTP id 5so629903qwg.13 for ; Wed, 30 Jun 2010 19:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ROEzDjwnArVeJtwXLrBJecJ739DFvU6FBptbY5G9F9Q=; b=kewiii30r+Be8SfO99tyJBN3om9mcyKFogeRGiPYPcdqBVtKMfIdxVQN+hZ6zQwlVf 5k+jcezEwhc+JZ50ZsRPt95gGea5uZxzY3ieqGkUEMmRJ77Ysj09Lr+CGMqGHHNxCZXY gxr0HfaeDOr8dDRZ3gTNrAsDbF9VQRMbQfkBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jCCAzKYdLAWnjPlhHOt2APwap6yyLFAn4IUdJjl4+qky4CJ7GA1QZ5QubeAMC/IXW5 H1v2svRDNFaykv75zVJfmUqe7CueEJRW/QJ5tBdcrS2ECnSiHtDQ4o75ENKkFMtTNFbo FHx7TGZ84OMVczuBQt9dE4IoHoKIEUHnMnu40= MIME-Version: 1.0 Received: by 10.224.35.229 with SMTP id q37mr6761806qad.163.1277949653074; Wed, 30 Jun 2010 19:00:53 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 19:00:53 -0700 (PDT) Date: Wed, 30 Jun 2010 19:00:53 -0700 Message-ID: From: Garrett Cooper To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 02:01:02 -0000 Hi, Just an observation I made while transferring a file: # time scp floppy.img somehost: Password: floppy.img 100% 1440KB 13.7KB/s 01:45 real 1m59.400s user 0m0.031s sys 0m0.028s # sysctl net.inet.tcp.tso=0 net.inet.tcp.tso: 1 -> 0 # time scp floppy.img somehost: floppy.img 100% 1440KB 1.4MB/s 00:00 real 0m0.712s user 0m0.018s sys 0m0.018s Going ISDN speeds transferring a 1.44MB file is sad when you have a gigabit uplink :(... natd seems to be doing a LOT of spinning when TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core machine). Here are some other details: # ipfw list 00050 divert 8668 ip4 from any to any via bce1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 65000 allow ip from any to any 65535 deny ip from any to any # ls /etc/natd* ls: /etc/natd*: No such file or directory # uname -a FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0 r209169: Mon Jun 14 12:41:49 PDT 2010 root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE amd64 # pciconf -lv | grep -A 4 bce bce1@pci0:7:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' class = network subclass = ethernet -- bce0@pci0:3:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' class = network subclass = ethernet Let me know what other info is required. Thanks, -Garrett PS Please keep me CCed in all emails. From owner-freebsd-net@FreeBSD.ORG Thu Jul 1 07:16:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BE8D1065672 for ; Thu, 1 Jul 2010 07:16:21 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id E3D7D8FC1B for ; Thu, 1 Jul 2010 07:16:20 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1OUDbB-000CfC-1I; Thu, 01 Jul 2010 10:50:13 +0400 From: "Alexander Zagrebin" To: , Date: Thu, 1 Jul 2010 10:50:12 +0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0777_01CB190B.2ECBBD70" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcsY6aeKEQR+kuwLTz2oEVxLaSoioA== Cc: Subject: 8.1-RC2: bug in ng_ipfw (ng_ipfw doesn't return a packet back to ipfw) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 07:16:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0777_01CB190B.2ECBBD70 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit After upgrading from RELENG_8_0 to RELENG_8_1 (8.1-RC2) I have noticed that ng_ipfw doesn't return a packet back to ipfw after `ipfw add ... netgraph ...` due to the bug in the sys/netgraph/ng_ipfw.c The attached patch solves the problem. -- Alexander ------=_NextPart_000_0777_01CB190B.2ECBBD70 Content-Type: application/octet-stream; name="patch-sys-netgraph-ng_ipfw.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-sys-netgraph-ng_ipfw.c" --- sys/netgraph/ng_ipfw.c.orig 2010-06-16 08:55:21.021628270 +0400=0A= +++ sys/netgraph/ng_ipfw.c 2010-07-01 10:29:09.561958484 +0400=0A= @@ -221,20 +221,21 @@=0A= static int=0A= ng_ipfw_rcvdata(hook_p hook, item_p item)=0A= {=0A= - struct ipfw_rule_ref *tag;=0A= + struct m_tag *tag;=0A= + struct ipfw_rule_ref *r;=0A= struct mbuf *m;=0A= =0A= NGI_GET_M(item, m);=0A= NG_FREE_ITEM(item);=0A= =0A= - tag =3D (struct ipfw_rule_ref *)=0A= - m_tag_locate(m, MTAG_IPFW_RULE, 0, NULL);=0A= + tag =3D m_tag_locate(m, MTAG_IPFW_RULE, 0, NULL);=0A= if (tag =3D=3D NULL) {=0A= NG_FREE_M(m);=0A= return (EINVAL); /* XXX: find smth better */=0A= };=0A= =0A= - if (tag->info & IPFW_INFO_IN) {=0A= + r =3D (struct ipfw_rule_ref *)(tag + 1);=0A= + if (r->info & IPFW_INFO_IN) {=0A= ip_input(m);=0A= return (0);=0A= } else {=0A= ------=_NextPart_000_0777_01CB190B.2ECBBD70-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 1 22:41:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDAFA106564A for ; Thu, 1 Jul 2010 22:41:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id ADC0C8FC08 for ; Thu, 1 Jul 2010 22:41:33 +0000 (UTC) Received: by pvb32 with SMTP id 32so1107636pvb.13 for ; Thu, 01 Jul 2010 15:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=JgXIp59c+ldmFbIc4xW4dAf/CycXuyBjo91ASgD3Vzo=; b=H327NH99C0/IIYzyw+XFjY2VKD74VdhXBq+QqRYAYP2kneCXkXv0GZWkljJ4HK8Jr/ eHR3ZXrzSycORlX160BDLPfE+0kKtt1DTvDU+2BanV+vLqwhgvzFzjPz8Ir4ynLblPrR CfvdxNo/6Eeot8YBd+wSSjxQH/UnmE+NA0wcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=v6N3Psdm15Y9JWG8pcbWShBt0WkzlwMTQm9k39g3On0GSng16bTTKrrXVLmb8/3LZ4 97UV/AniwTN4VYjCnck+72vMf6KGzxIsw0V4/nrzAi/2jix8ucEevLdxdNTGnybtXEk7 rSHz2zG7BzVvMxoB9ASSGFueWIrx2CaZgSVFM= Received: by 10.114.113.16 with SMTP id l16mr145720wac.210.1278024088229; Thu, 01 Jul 2010 15:41:28 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 33sm1721320wad.18.2010.07.01.15.41.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 15:41:27 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 1 Jul 2010 15:41:00 -0700 From: Pyun YongHyeon Date: Thu, 1 Jul 2010 15:41:00 -0700 To: Andrea Venturoli Message-ID: <20100701224100.GG7090@michelle.cdnetworks.com> References: <4C209C22.7080900@netfence.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C209C22.7080900@netfence.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Atheros ale problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 22:41:33 -0000 On Tue, Jun 22, 2010 at 01:18:58PM +0200, Andrea Venturoli wrote: > Hello. > > I'm having problems with 8.0/amd64 with the following card: > > ale0@pci0:1:0:0: class=0x020000 card=0x83041043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > > This is connected to a 100Mb/s Full Duplex switch with no fancy features. > > > > Sometimes, while connected through ssh to this box, I get kicked out with: > Disconnecting: Corrupted MAC on input. > or: > Disconnecting: Bad packet length 1686869659. > > At the same time on the server's log and console, I see: > > kernel: ale0: watchdog timeout -- resetting > kernel: ale0: could not disable Tx/Rx MAC(0x00000008)! > kernel: ale0: link state changed to DOWN > kernel: ale0: link state changed to UP > > I'm setting up this box, so I can't speak of other > protocols/applications yet. > > > > I saw some threads about this dating back to 2008 and related to EEEPCs, > but this was supposed to be fixed. > > Any help? > Show me the output of "ifconfig ale0" and "sysctl dev.ale.0.stats". And see whether your switch also agrees on resolved speed/duplex of established link. From owner-freebsd-net@FreeBSD.ORG Thu Jul 1 23:08:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B0EF106564A for ; Thu, 1 Jul 2010 23:08:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6198FC14 for ; Thu, 1 Jul 2010 23:08:22 +0000 (UTC) Received: by pvb32 with SMTP id 32so1115208pvb.13 for ; Thu, 01 Jul 2010 16:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=hBFcE649odcH7iJC15b9Kv3/uqA6aHPonehwfZYVYCg=; b=YRJnvugXXJZ7HRXxV38aEf/pJWcUaDFy8mPv/tCMiJw/utZU8lb6sGA/7aARWe3xyj 18zQTWcBXpr6JZO4d7ZLf6qMJBdIcKx7Sf81bqa1VSBR6vE5eyNPdSWe9iyH0ZlmwlA3 OSeCeL/ejtuBgIB0u+xeWjqyu1bK/1kxXGXls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=LSC86Mc9iJ85nRlgG76y7TiL99+ucUK2oWiCYBqtkyJc0HjeKOQoe+N/OEamGqT/Ao xxjMEg0bN5bx0eloZjSZ24rrJLVKIbuTebOBtOmxp3poPa3tbrEUr5wMUnuLvSM10922 cyNQAWz6MiN/J3DG3H5paHRxBQj+GKxAIcoQY= Received: by 10.114.61.12 with SMTP id j12mr230521waa.19.1278025698459; Thu, 01 Jul 2010 16:08:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d39sm2430034wam.16.2010.07.01.16.08.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 16:08:17 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 1 Jul 2010 16:07:46 -0700 From: Pyun YongHyeon Date: Thu, 1 Jul 2010 16:07:46 -0700 To: Michael Monashev Message-ID: <20100701230745.GH7090@michelle.cdnetworks.com> References: <1476665685.20100623023003@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1476665685.20100623023003@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: can't disable VLAN_MTU and VLAN_HWCSUM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:08:22 -0000 On Wed, Jun 23, 2010 at 02:30:03AM +0400, Michael Monashev wrote: > Hi > > FreeBSD 8.0-RELEASE-p3 > > $ ifconfig > em0: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > media: Ethernet autoselect (1000baseT ) > status: active > em1: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > lagg0: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > inet 89.208.146.215 netmask 0xffffff00 broadcast 89.208.146.255 > inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255 > inet 89.208.145.139 netmask 0xffffff00 broadcast 89.208.145.255 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em1 flags=1c > laggport: em0 flags=1c > vlan2: flags=8843 metric 0 mtu 9216 > ether 00:15:17:35:1c:76 > inet 10.0.143.5 netmask 0xffffff00 broadcast 10.0.143.255 > media: Ethernet autoselect > status: active > vlan: 2 parent interface: lagg0 > lo1: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.1.1 netmask 0xffffff00 > inet 127.0.1.2 netmask 0xffffffff > inet 127.0.1.3 netmask 0xffffffff > inet 127.0.1.4 netmask 0xffffffff > inet 127.0.1.5 netmask 0xffffffff > inet 127.0.1.6 netmask 0xffffffff > inet 127.0.1.7 netmask 0xffffffff > inet 127.0.1.8 netmask 0xffffffff > inet 127.0.1.9 netmask 0xffffffff > inet 127.0.1.10 netmask 0xffffffff > inet 127.0.1.11 netmask 0xffffffff > inet 127.0.1.12 netmask 0xffffffff > inet 127.0.1.13 netmask 0xffffffff > inet 127.0.1.14 netmask 0xffffffff > inet 127.0.1.15 netmask 0xffffffff > inet 127.0.1.16 netmask 0xffffffff > inet 127.0.1.17 netmask 0xffffffff > inet 127.0.1.18 netmask 0xffffffff > inet 127.0.1.19 netmask 0xffffffff > inet 127.0.1.20 netmask 0xffffffff > > $ sudo ifconfig em0 -vlanmtu > $ sudo ifconfig em1 -vlanmtu > $ sudo ifconfig em0 -vlanhwfilter > $ sudo ifconfig em1 -vlanhwfilter > > $ ifconfig > em0: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > media: Ethernet autoselect (1000baseT ) > status: active > em1: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > lagg0: flags=8843 metric 0 mtu 9216 > options=18b > ether 00:15:17:35:1c:76 > inet 89.208.146.215 netmask 0xffffff00 broadcast 89.208.146.255 > inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255 > inet 89.208.145.139 netmask 0xffffff00 broadcast 89.208.145.255 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em1 flags=1c > laggport: em0 flags=1c > vlan2: flags=8843 metric 0 mtu 9216 > ether 00:15:17:35:1c:76 > inet 10.0.143.5 netmask 0xffffff00 broadcast 10.0.143.255 > media: Ethernet autoselect > status: active > vlan: 2 parent interface: lagg0 > lo1: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.1.1 netmask 0xffffff00 > inet 127.0.1.2 netmask 0xffffffff > inet 127.0.1.3 netmask 0xffffffff > inet 127.0.1.4 netmask 0xffffffff > inet 127.0.1.5 netmask 0xffffffff > inet 127.0.1.6 netmask 0xffffffff > inet 127.0.1.7 netmask 0xffffffff > inet 127.0.1.8 netmask 0xffffffff > inet 127.0.1.9 netmask 0xffffffff > inet 127.0.1.10 netmask 0xffffffff > inet 127.0.1.11 netmask 0xffffffff > inet 127.0.1.12 netmask 0xffffffff > inet 127.0.1.13 netmask 0xffffffff > inet 127.0.1.14 netmask 0xffffffff > inet 127.0.1.15 netmask 0xffffffff > inet 127.0.1.16 netmask 0xffffffff > inet 127.0.1.17 netmask 0xffffffff > inet 127.0.1.18 netmask 0xffffffff > inet 127.0.1.19 netmask 0xffffffff > inet 127.0.1.20 netmask 0xffffffff > > As you can see, ifconfig didn`t change anything. > How to disable VLAN_MTU and VLAN_HWCSUM flags? > Why you need to disable VLAN_MTU/VLAN_HWCSUM? Unlike other capabilities, VLAN_MTU capability is just an indicator for oversized frame capability. If hardware supports VLAN oversized frame there is no reason to disable it. Of course, some drivers (e.g. fxp(4)) allow enabling/disabling VLAN_MTU but it's for enabling software workaround for old controller that lacks receiving VLAN oversized frames. Many controllers can't selectively disable checksum offloading on VLAN frames while still allowing checksum offloading on non-VLAN frames. And vlan(4) requires VLAN hardware tagging to make checksum offloading for VLAN frames work. So disabling VLAN hardware tagging will disable checksum offloading on VLAN frames. From owner-freebsd-net@FreeBSD.ORG Thu Jul 1 23:55:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B04106566B for ; Thu, 1 Jul 2010 23:55:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 904308FC0C for ; Thu, 1 Jul 2010 23:55:29 +0000 (UTC) Received: by pwj9 with SMTP id 9so415367pwj.13 for ; Thu, 01 Jul 2010 16:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=MyuTj023ESn5FvjjTd+lb0jgYUUFwC3jmw3za+E6fOk=; b=gP2uo4i9xTGuXXJ8WRwMySDgI1tkMly0A39XEWcUB0mng+xBSjQXvnCOMkKujEi5tr hOtgh1rHKrbpmtiC/rb3WUJhnvAYdOWThMdAQRudhXwmqlOddFCJLcgwPG9abN+hvTJZ cvlgq0y+FBXui6IWh+0rqqhcBushqio0ybAYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=D2zGyoCfjbj0A/2dPNtD6Zw6j61PRNl9TlzKyX3unnZRzWOGQ+5j7Lx4bQjb8sEbvx SA4oVIyg7r17zgm+h1//MHpyI6fT6Ykvwgq0UBPDx/s/StizoBcY1x8SSFBRo8T0RrPQ 2uho8diLvM3sCmZPgFG+iDswSm29Hnr9VCHwc= Received: by 10.115.59.1 with SMTP id m1mr300534wak.99.1278028513929; Thu, 01 Jul 2010 16:55:13 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q6sm380028waj.22.2010.07.01.16.55.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 16:55:13 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 1 Jul 2010 16:54:47 -0700 From: Pyun YongHyeon Date: Thu, 1 Jul 2010 16:54:47 -0700 To: Garrett Cooper Message-ID: <20100701235447.GJ7090@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:55:29 -0000 On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: > Hi, > Just an observation I made while transferring a file: > > # time scp floppy.img somehost: > Password: > floppy.img 100% 1440KB 13.7KB/s 01:45 > > real 1m59.400s > user 0m0.031s > sys 0m0.028s > # sysctl net.inet.tcp.tso=0 > net.inet.tcp.tso: 1 -> 0 > # time scp floppy.img somehost: > floppy.img 100% 1440KB 1.4MB/s 00:00 > > real 0m0.712s > user 0m0.018s > sys 0m0.018s > > Going ISDN speeds transferring a 1.44MB file is sad when you have > a gigabit uplink :(... natd seems to be doing a LOT of spinning when > TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core > machine). I would use pf(4) if I have to handle lots of NAT rules. > Here are some other details: > > # ipfw list > 00050 divert 8668 ip4 from any to any via bce1 > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 deny ip from any to ::1 > 00500 deny ip from ::1 to any > 00600 allow ipv6-icmp from :: to ff02::/16 > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 > 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > 65000 allow ip from any to any > 65535 deny ip from any to any > # ls /etc/natd* > ls: /etc/natd*: No such file or directory > # uname -a > FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0 > r209169: Mon Jun 14 12:41:49 PDT 2010 > root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE amd64 > # pciconf -lv | grep -A 4 bce > bce1@pci0:7:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 > rev=0x12 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' > class = network > subclass = ethernet > -- > bce0@pci0:3:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 > rev=0x12 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' > class = network > subclass = ethernet > > Let me know what other info is required. Can you reproduce this issue on other TSO capable drivers? I'm not aware of any TSO issues on bce(4). From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 01:19:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 484BD1065679 for ; Fri, 2 Jul 2010 01:19:25 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1E498FC13 for ; Fri, 2 Jul 2010 01:19:24 +0000 (UTC) Received: by vws6 with SMTP id 6so2449859vws.13 for ; Thu, 01 Jul 2010 18:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9b50kiQmMKr8clkv8K84v1X0z4grWEHeof9A0cEBQQM=; b=I7VoB0VZLC+Fkf3QLKmwjCkdP1jxx58dvj7Ids8gIuWZ50rqpPm0ZKlHHbc8miYgPZ Soo0oWbe0+cHLEjlXJA9kL0G0/B/X+/cZ3z8e9EHc3Bcbtz2Asugzh3cgiUj3D57gXQ3 8lcMcJHwiceCHWgdq4m5r/Ur8bFfFVMGt1hSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JE8v6KVR0cMTacjQEnqTf5D225TMPbpRBfOYYjri2CboFw7FkPyqVuvRWCGJmSVsjo H7xl3LfwVSk/yFM9+odLPPoZE1Lk5DVl0aNHEFOQk6X0FPTJ3Puasxplfsjgqghqyv6v Q7aSOY/vc8F14Lf5Z6wINqA3rmo3n+T5tpEzg= MIME-Version: 1.0 Received: by 10.229.236.132 with SMTP id kk4mr226622qcb.117.1278033553400; Thu, 01 Jul 2010 18:19:13 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Thu, 1 Jul 2010 18:19:13 -0700 (PDT) In-Reply-To: <20100701235447.GJ7090@michelle.cdnetworks.com> References: <20100701235447.GJ7090@michelle.cdnetworks.com> Date: Thu, 1 Jul 2010 18:19:13 -0700 Message-ID: From: Garrett Cooper To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 01:19:25 -0000 On Thu, Jul 1, 2010 at 4:54 PM, Pyun YongHyeon wrote: > On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: >> Hi, >> =A0 =A0 Just an observation I made while transferring a file: >> >> # time scp floppy.img somehost: >> Password: >> floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0100% 1440KB =A013.7KB/s =A0 01:45 >> >> real =A01m59.400s >> user =A00m0.031s >> sys =A0 0m0.028s >> # sysctl net.inet.tcp.tso=3D0 >> net.inet.tcp.tso: 1 -> 0 >> # time scp floppy.img somehost: >> floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0100% 1440KB =A0 1.4MB/s =A0 00:00 >> >> real =A00m0.712s >> user =A00m0.018s >> sys =A0 0m0.018s >> >> =A0 =A0 Going ISDN speeds transferring a 1.44MB file is sad when you hav= e >> a gigabit uplink :(... natd seems to be doing a LOT of spinning when >> TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core >> machine). > > I would use pf(4) if I have to handle lots of NAT rules. > >> =A0 =A0 Here are some other details: >> >> # ipfw list >> 00050 divert 8668 ip4 from any to any via bce1 >> 00100 allow ip from any to any via lo0 >> 00200 deny ip from any to 127.0.0.0/8 >> 00300 deny ip from 127.0.0.0/8 to any >> 00400 deny ip from any to ::1 >> 00500 deny ip from ::1 to any >> 00600 allow ipv6-icmp from :: to ff02::/16 >> 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 >> 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 >> 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 >> 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 >> 65000 allow ip from any to any >> 65535 deny ip from any to any >> # ls /etc/natd* >> ls: /etc/natd*: No such file or directory >> # uname -a >> FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0 >> r209169: Mon Jun 14 12:41:49 PDT 2010 >> root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE =A0amd64 >> # pciconf -lv | grep -A 4 bce >> bce1@pci0:7:0:0: =A0 =A0 =A0class=3D0x020000 card=3D0x01b21028 chip=3D0x= 164c14e4 >> rev=3D0x12 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Broadcom Corporation' >> =A0 =A0 device =A0 =A0 =3D 'Broadcom NetXtreme II Gigabit Ethernet Adapt= er (BCM5708)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> -- >> bce0@pci0:3:0:0: =A0 =A0 =A0class=3D0x020000 card=3D0x01b21028 chip=3D0x= 164c14e4 >> rev=3D0x12 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Broadcom Corporation' >> =A0 =A0 device =A0 =A0 =3D 'Broadcom NetXtreme II Gigabit Ethernet Adapt= er (BCM5708)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> >> =A0 =A0 Let me know what other info is required. > > Can you reproduce this issue on other TSO capable drivers? > I'm not aware of any TSO issues on bce(4). Hi Pyun! I'll have to pop in a Copper Intel card that we have laying around in the lab. I think it's em(4) compatible.. I forget... I have a few things to test network wise this weekend, so I'll try and repro a few things this weekend (say, Sunday?). I also have my msk(4) enabled machine in the lab I can test with, but I'll have to install the machine to spec with the Poweredge 2950 I have in the lab. I'm using ipfw because it was easy to setup according to the handbook, but in reality if ipfw is this bad dealing with nat rules, then I need to work with someone to improve how it scales. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 02:36:10 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ECF9106564A for ; Fri, 2 Jul 2010 02:36:10 +0000 (UTC) (envelope-from babolo@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1DE8FC18 for ; Fri, 2 Jul 2010 02:36:09 +0000 (UTC) Received: from cicuta.babolo.ru (cicuta.babolo.ru [85.30.229.5] (may be forged)) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id o622GaxY065264; Fri, 2 Jul 2010 06:16:36 +0400 (MSD) (envelope-from babolo@babolo.ru) Received: (nullmailer pid 32597 invoked by uid 136); Fri, 02 Jul 2010 02:20:59 -0000 Date: Fri, 2 Jul 2010 06:20:58 +0400 From: Aleksandr A Babaylov <.@babolo.ru> To: Pyun YongHyeon Message-ID: <20100702022058.GA32531@babolo.ru> References: <20100701235447.GJ7090@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100701235447.GJ7090@michelle.cdnetworks.com> Cc: Garrett Cooper , net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 02:36:10 -0000 On Thu, Jul 01, 2010 at 04:54:47PM -0700, Pyun YongHyeon wrote: > On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: > > Hi, > > Just an observation I made while transferring a file: > > > > # time scp floppy.img somehost: > > Password: > > floppy.img 100% 1440KB 13.7KB/s 01:45 > > > > real 1m59.400s > > user 0m0.031s > > sys 0m0.028s > > # sysctl net.inet.tcp.tso=0 > > net.inet.tcp.tso: 1 -> 0 > > # time scp floppy.img somehost: > > floppy.img 100% 1440KB 1.4MB/s 00:00 > > > > real 0m0.712s > > user 0m0.018s > > sys 0m0.018s > > > > Going ISDN speeds transferring a 1.44MB file is sad when you have > > a gigabit uplink :(... natd seems to be doing a LOT of spinning when > > TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core > > machine). > I would use pf(4) if I have to handle lots of NAT rules. Or ipfw nat. man ipfw | grep nat From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 04:20:05 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5FC6106564A for ; Fri, 2 Jul 2010 04:20:05 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 306788FC0C for ; Fri, 2 Jul 2010 04:20:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o624Jv2k038049; Fri, 2 Jul 2010 14:19:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 2 Jul 2010 14:19:56 +1000 (EST) From: Ian Smith To: Garrett Cooper In-Reply-To: Message-ID: <20100702133537.L9227@sola.nimnet.asn.au> References: <20100701235447.GJ7090@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1236089349-1278044396=:9227" Cc: pyunyh@gmail.com, net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 04:20:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1236089349-1278044396=:9227 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 1 Jul 2010, Garrett Cooper wrote: > On Thu, Jul 1, 2010 at 4:54 PM, Pyun YongHyeon wrote: > > On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: > >> Hi, > >>     Just an observation I made while transferring a file: > >> > >> # time scp floppy.img somehost: > >> Password: > >> floppy.img                                    100% 1440KB  13.7KB/s   01:45 > >> > >> real  1m59.400s > >> user  0m0.031s > >> sys   0m0.028s > >> # sysctl net.inet.tcp.tso=0 > >> net.inet.tcp.tso: 1 -> 0 > >> # time scp floppy.img somehost: > >> floppy.img                                    100% 1440KB   1.4MB/s   00:00 > >> > >> real  0m0.712s > >> user  0m0.018s > >> sys   0m0.018s > >> > >>     Going ISDN speeds transferring a 1.44MB file is sad when you have > >> a gigabit uplink :(... natd seems to be doing a LOT of spinning when > >> TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core > >> machine). > > > > I would use pf(4) if I have to handle lots of NAT rules. There's only one NAT rule here, not clear how many active NAT sessions are involved. I'm tending to doubt this is really a natd issue; natd has no interaction with interface issues like TSO, that I know of, hopefully someone will correct me if I'm wrong about that. > >>     Here are some other details: > >> > >> # ipfw list > >> 00050 divert 8668 ip4 from any to any via bce1 > >> 00100 allow ip from any to any via lo0 > >> 00200 deny ip from any to 127.0.0.0/8 > >> 00300 deny ip from 127.0.0.0/8 to any > >> 00400 deny ip from any to ::1 > >> 00500 deny ip from ::1 to any > >> 00600 allow ipv6-icmp from :: to ff02::/16 > >> 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > >> 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > >> 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 > >> 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > >> 65000 allow ip from any to any > >> 65535 deny ip from any to any > >> # ls /etc/natd* > >> ls: /etc/natd*: No such file or directory I assume that's the 'open' rc.firewall ruleset? So you have no natd.conf, and are taking all defaults? Just to check the config: # grep natd_ /etc/rc.conf # ps axw | grep "[n]atd" Do you have options IPFIREWALL and IPDIVERT in kernel, or are you loading these as modules? > >> # uname -a > >> FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0 > >> r209169: Mon Jun 14 12:41:49 PDT 2010 > >> root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE  amd64 > >> # pciconf -lv | grep -A 4 bce > >> bce1@pci0:7:0:0:      class=0x020000 card=0x01b21028 chip=0x164c14e4 > >> rev=0x12 hdr=0x00 > >>     vendor     = 'Broadcom Corporation' > >>     device     = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' > >>     class      = network > >>     subclass   = ethernet > >> -- > >> bce0@pci0:3:0:0:      class=0x020000 card=0x01b21028 chip=0x164c14e4 > >> rev=0x12 hdr=0x00 > >>     vendor     = 'Broadcom Corporation' > >>     device     = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' > >>     class      = network > >>     subclass   = ethernet > >> > >>     Let me know what other info is required. > > > > Can you reproduce this issue on other TSO capable drivers? > > I'm not aware of any TSO issues on bce(4). > > Hi Pyun! > > I'll have to pop in a Copper Intel card that we have laying around in > the lab. I think it's em(4) compatible.. I forget... I have a few > things to test network wise this weekend, so I'll try and repro a few > things this weekend (say, Sunday?). > > I also have my msk(4) enabled machine in the lab I can test with, but > I'll have to install the machine to spec with the Poweredge 2950 I > have in the lab. > > I'm using ipfw because it was easy to setup according to the handbook, > but in reality if ipfw is this bad dealing with nat rules, then I need > to work with someone to improve how it scales. Unless there's something weird with tagging or something going on with divert sockets, this looks like something else; natd usually works fine at much higher rates, but I can't talk about gigabit. Though in-kernel NAT should be better at the higher throughput end, your 'ISDN' rate and the high CPU usage for natd is certainly not typical. Does this box have a public IP address on bce1? It's not clear whether you're doing this transfer from this box, or from another, through it, ie what address translation is expected? Where is 'somehost'? Hence, knowing natd's config options and net topology might be helpful. cheers, Ian --0-1236089349-1278044396=:9227-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 05:30:41 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73F12106566B for ; Fri, 2 Jul 2010 05:30:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2173D8FC1B for ; Fri, 2 Jul 2010 05:30:40 +0000 (UTC) Received: by vws6 with SMTP id 6so2700822vws.13 for ; Thu, 01 Jul 2010 22:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QQQQMlAM2u/K4OzUlroaqVZpxUgqFwNJ1zpUNrF5h3A=; b=xb1w3wq2s1mbix+T2MwZWw+npbkfGbbATMZcbgOUv0Zo9zizHhbcXeKxDi/rf+7XtV 9pEbZCEGEqTNPmGwNuDvISFsao8SAFR1kW3st647be9kbsV8JqEkPBTyYQWsOZdPZ26w D+fqmwgWuwUOeKyfr/d5b1up0Tj8QD7vMpQ8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DhjYq6rGR1SGTS07yqx47d48HU9kOKkOkPzXvzsFfPJngEcZWDV3PmaHprP6Pf5+e+ boL/SZye7kKXF024daxXEiv9RyMr2kmatmfaGNzDGc5pssUgNTLvVlhWCkcS93/ZJOvT lYLATKPa8id9S1JciS3zBTBxK32Bjc9pJ713I= MIME-Version: 1.0 Received: by 10.229.99.145 with SMTP id u17mr113384qcn.185.1278048634448; Thu, 01 Jul 2010 22:30:34 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Thu, 1 Jul 2010 22:30:34 -0700 (PDT) In-Reply-To: <20100702133537.L9227@sola.nimnet.asn.au> References: <20100701235447.GJ7090@michelle.cdnetworks.com> <20100702133537.L9227@sola.nimnet.asn.au> Date: Thu, 1 Jul 2010 22:30:34 -0700 Message-ID: From: Garrett Cooper To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 05:30:41 -0000 On Thu, Jul 1, 2010 at 9:19 PM, Ian Smith wrote: > On Thu, 1 Jul 2010, Garrett Cooper wrote: > =A0> On Thu, Jul 1, 2010 at 4:54 PM, Pyun YongHyeon wr= ote: > =A0> > On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: > =A0> >> Hi, > =A0> >> =A0 =A0 Just an observation I made while transferring a file: > =A0> >> > =A0> >> # time scp floppy.img somehost: > =A0> >> Password: > =A0> >> floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0100% 1440KB =A013.7KB/s =A0 01:45 > =A0> >> > =A0> >> real =A01m59.400s > =A0> >> user =A00m0.031s > =A0> >> sys =A0 0m0.028s > =A0> >> # sysctl net.inet.tcp.tso=3D0 > =A0> >> net.inet.tcp.tso: 1 -> 0 > =A0> >> # time scp floppy.img somehost: > =A0> >> floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0100% 1440KB =A0 1.4MB/s =A0 00:00 > =A0> >> > =A0> >> real =A00m0.712s > =A0> >> user =A00m0.018s > =A0> >> sys =A0 0m0.018s > =A0> >> > =A0> >> =A0 =A0 Going ISDN speeds transferring a 1.44MB file is sad when = you have > =A0> >> a gigabit uplink :(... natd seems to be doing a LOT of spinning w= hen > =A0> >> TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core > =A0> >> machine). > =A0> > > =A0> > I would use pf(4) if I have to handle lots of NAT rules. > > There's only one NAT rule here, not clear how many active NAT sessions > are involved. =A0I'm tending to doubt this is really a natd issue; natd > has no interaction with interface issues like TSO, that I know of, > hopefully someone will correct me if I'm wrong about that. > > =A0> >> =A0 =A0 Here are some other details: > =A0> >> > =A0> >> # ipfw list > =A0> >> 00050 divert 8668 ip4 from any to any via bce1 > =A0> >> 00100 allow ip from any to any via lo0 > =A0> >> 00200 deny ip from any to 127.0.0.0/8 > =A0> >> 00300 deny ip from 127.0.0.0/8 to any > =A0> >> 00400 deny ip from any to ::1 > =A0> >> 00500 deny ip from ::1 to any > =A0> >> 00600 allow ipv6-icmp from :: to ff02::/16 > =A0> >> 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > =A0> >> 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > =A0> >> 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 > =A0> >> 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > =A0> >> 65000 allow ip from any to any > =A0> >> 65535 deny ip from any to any > =A0> >> # ls /etc/natd* > =A0> >> ls: /etc/natd*: No such file or directory > > I assume that's the 'open' rc.firewall ruleset? Yes. $ grep ^firewall /etc/rc.conf firewall_type=3D"open" > So you have no > natd.conf, and are taking all defaults? =A0Just to check the config: Correct. $ ls /etc/natd.conf ls: /etc/natd.conf: No such file or directory > # grep natd_ /etc/rc.conf $ grep ^natd_ /etc/rc.conf natd_enable=3D"YES" natd_interface=3D"bce1" > # ps axw | grep "[n]atd" > > Do you have options IPFIREWALL and IPDIVERT in kernel, or are you > loading these as modules? Modules. $ egrep 'IPDIVERT|IPFIREWALL' /root/TAMESHI_STABLE $ make -VMODULES_OVERRIDE -f /etc/src.conf foo bce bge em bridgestp if_bridge ipdivert ipfw ipfw_nat libalias i2c/smbus ipmi ipmi/ipmi_linux linprocfs linsysfs linux > =A0> >> # uname -a > =A0> >> FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #= 0 > =A0> >> r209169: Mon Jun 14 12:41:49 PDT 2010 > =A0> >> root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE =A0am= d64 > =A0> >> # pciconf -lv | grep -A 4 bce > =A0> >> bce1@pci0:7:0:0: =A0 =A0 =A0class=3D0x020000 card=3D0x01b21028 ch= ip=3D0x164c14e4 > =A0> >> rev=3D0x12 hdr=3D0x00 > =A0> >> =A0 =A0 vendor =A0 =A0 =3D 'Broadcom Corporation' > =A0> >> =A0 =A0 device =A0 =A0 =3D 'Broadcom NetXtreme II Gigabit Etherne= t Adapter (BCM5708)' > =A0> >> =A0 =A0 class =A0 =A0 =A0=3D network > =A0> >> =A0 =A0 subclass =A0 =3D ethernet > =A0> >> -- > =A0> >> bce0@pci0:3:0:0: =A0 =A0 =A0class=3D0x020000 card=3D0x01b21028 ch= ip=3D0x164c14e4 > =A0> >> rev=3D0x12 hdr=3D0x00 > =A0> >> =A0 =A0 vendor =A0 =A0 =3D 'Broadcom Corporation' > =A0> >> =A0 =A0 device =A0 =A0 =3D 'Broadcom NetXtreme II Gigabit Etherne= t Adapter (BCM5708)' > =A0> >> =A0 =A0 class =A0 =A0 =A0=3D network > =A0> >> =A0 =A0 subclass =A0 =3D ethernet > =A0> >> > =A0> >> =A0 =A0 Let me know what other info is required. > =A0> > > =A0> > Can you reproduce this issue on other TSO capable drivers? > =A0> > I'm not aware of any TSO issues on bce(4). > =A0> > =A0> Hi Pyun! > =A0> > =A0> I'll have to pop in a Copper Intel card that we have laying around i= n > =A0> the lab. I think it's em(4) compatible.. I forget... I have a few > =A0> things to test network wise this weekend, so I'll try and repro a fe= w > =A0> things this weekend (say, Sunday?). > =A0> > =A0> I also have my msk(4) enabled machine in the lab I can test with, bu= t > =A0> I'll have to install the machine to spec with the Poweredge 2950 I > =A0> have in the lab. > =A0> > =A0> I'm using ipfw because it was easy to setup according to the handboo= k, > =A0> but in reality if ipfw is this bad dealing with nat rules, then I ne= ed > =A0> to work with someone to improve how it scales. > > Unless there's something weird with tagging or something going on with > divert sockets, this looks like something else; Ok. > natd usually works fine > at much higher rates, but I can't talk about gigabit. =A0Though in-kernel > NAT should be better at the higher throughput end, But this panics deterministically as I've shown in another thread on 8-STABLE, so unfortunately I can't use this. > your 'ISDN' rate and the high CPU usage for natd is certainly not typical= . That I wouldn't doubt. > Does this box have a public IP address on bce1? Nope. > It's not clear whether you're doing this transfer from this box, or from = another, through it, ie what address translation is expected? I'm doing the transfer from tameshi.cisco.com to ironport1.cisco.com via (what I would hope) is the public interface -- bce1 -- because my routes are setup that way: $ netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 173.37.10.1 UGS 0 42504770 bce1 127.0.0.1 link#1 UH 0 2052 lo0 173.37.10.0/24 link#4 U 38 2752472 bce1 173.37.10.6 link#4 UHS 0 20258228 lo0 192.168.20.0/22 link#3 U 3 5570413 bce0 192.168.20.1 link#3 UHS 0 2572 lo0 192.168.21.1 link#3 UHS 0 0 lo0 192.168.22.1 link#3 UHS 0 0 lo0 192.168.23.1 link#3 UHS 0 0 lo0 192.168.24.0/22 link#3 U 0 0 bce0 192.168.24.1 link#3 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH = lo0 fe80::%lo0/64 link#1 U = lo0 fe80::1%lo0 link#1 UHS = lo0 ff01:1::/32 fe80::1%lo0 U = lo0 ff02::%lo0/32 fe80::1%lo0 U = lo0 $ ifconfig lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D3 ipfw0: flags=3D8800 metric 0 mtu 65536 bce0: flags=3D8943 metric 0 mtu 1500 options=3Dc01bb ether 00:1e:4f:38:65:ab inet 192.168.20.1 netmask 0xfffffc00 broadcast 192.168.23.255 inet 192.168.21.1 netmask 0xfffffc00 broadcast 192.168.23.255 inet 192.168.22.1 netmask 0xfffffc00 broadcast 192.168.23.255 inet 192.168.23.1 netmask 0xfffffc00 broadcast 192.168.23.255 inet 192.168.24.1 netmask 0xfffffc00 broadcast 192.168.27.255 media: Ethernet autoselect (1000baseT ) status: active bce1: flags=3D8843 metric 0 mtu 150= 0 options=3Dc01bb ether 00:1e:4f:38:65:ad inet 173.37.10.6 netmask 0xffffff00 broadcast 173.37.10.255 media: Ethernet autoselect (1000baseT ) status: active I would expect bce1 -> bce0 to hop a vlan, but apart from that transfer speeds should be reasonably fast. It (ironport1) is a semi-ancient Sparc machine, so I don't expect the speeds to be blazing fast, but I've gotten up to 15 MBps on a good day. > Where is 'somehost'? Ok, bleh... turns out that someone internally used somehost as a CNAME, so rather than obfuscating things I'll just divulge the real hostname because it's needed: $ host ironport1.cisco.com ; host tameshi.cisco.com ironport1.cisco.com has address 173.37.5.41 tameshi.cisco.com has address 173.37.10.6 > Hence, knowing natd's config options and net topology might be helpful. Fair enough .. security by obscurity isn't going to do any difference because all of this crud is behind the corporate firewall anyhow :). Another weird thing I noticed when I looked at it further is that dhcpcd's usage is spiking up to 33% instead of remaining near idle, and I had no idea why; so I truss'ed the process and there's a lot of chatter on 127.0.0.1:0 with recvfrom, so it looks like the traffic is being broadcast to all ports instead of port 67/68, and something looks horribly broken in the networking stack with TSO on. Turning off TSO shows that _no_ traffic is being intercepted via lo0 by dhcpd when I scp the file, which I would expect to occur. I'll see whether or not there are any firmware upgrades for the NIC on this machine because there might be some sort of hardware errata that I need to take into consideration. I'll get back to you guys after I do that because I'm concerned that that might be an issue. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 05:32:56 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF4C1065672 for ; Fri, 2 Jul 2010 05:32:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36D788FC15 for ; Fri, 2 Jul 2010 05:32:55 +0000 (UTC) Received: by qwg5 with SMTP id 5so1246863qwg.13 for ; Thu, 01 Jul 2010 22:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iixZnUzJYZ+PpugQ18Rql7POzeyMTxax/vgWRotJKrQ=; b=WvoQ0clIP4/57dcJtmhyulQ1hgXIKi5qTpLDKBh9Jka/Duh/2EgOZWuKvyw119JWz3 mTHtEbZacsmg06zmsSUDk1VsoLQCyNocXIrRicOPaJAtiztBuNx6+uGEr+lL9lwABylE yURlwnm6pvvqxYaBBuK3/jTnGmPe2/EYiwXQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VAdjx56e1H+zDJyh4pHo+DPc2MxwD9mVtUG9T3LgUEi1gHOCNWhcNYAlAYJkA0R+Mb yMydvnZR1OHkuUqJuUBs7sl99tZ9I9xWEd1Ap7enbzfiupfBaeRJ1Qd5oErCv7tNUZ/c ig080OPowfz0OdD3SuQzTHkGokU0EXtqM6qR0= MIME-Version: 1.0 Received: by 10.229.96.213 with SMTP id i21mr112218qcn.198.1278048757263; Thu, 01 Jul 2010 22:32:37 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Thu, 1 Jul 2010 22:32:37 -0700 (PDT) In-Reply-To: <20100702022058.GA32531@babolo.ru> References: <20100701235447.GJ7090@michelle.cdnetworks.com> <20100702022058.GA32531@babolo.ru> Date: Thu, 1 Jul 2010 22:32:37 -0700 Message-ID: From: Garrett Cooper To: Aleksandr A Babaylov <.@babolo.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pyun YongHyeon , net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 05:32:56 -0000 On Thu, Jul 1, 2010 at 7:20 PM, Aleksandr A Babaylov <.@babolo.ru> wrote: > On Thu, Jul 01, 2010 at 04:54:47PM -0700, Pyun YongHyeon wrote: >> On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: >> > Hi, >> > =A0 =A0 Just an observation I made while transferring a file: >> > >> > # time scp floppy.img somehost: >> > Password: >> > floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0100% 1440KB =A013.7KB/s =A0 01:45 >> > >> > real =A0 =A0 =A0 =A01m59.400s >> > user =A0 =A0 =A0 =A00m0.031s >> > sys 0m0.028s >> > # sysctl net.inet.tcp.tso=3D0 >> > net.inet.tcp.tso: 1 -> 0 >> > # time scp floppy.img somehost: >> > floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0100% 1440KB =A0 1.4MB/s =A0 00:00 >> > >> > real =A0 =A0 =A0 =A00m0.712s >> > user =A0 =A0 =A0 =A00m0.018s >> > sys 0m0.018s >> > >> > =A0 =A0 Going ISDN speeds transferring a 1.44MB file is sad when you h= ave >> > a gigabit uplink :(... natd seems to be doing a LOT of spinning when >> > TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core >> > machine). >> I would use pf(4) if I have to handle lots of NAT rules. > Or ipfw nat. > man ipfw | grep nat That uses the kernel module though, and that's horribly broken on my machine with 8-STABLE/9-CURRENT (see: http://www.mail-archive.com/freebsd-net@freebsd.org/msg33518.html ). I wonder if that's related to the TSO issue. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 08:40:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB8C8106564A; Fri, 2 Jul 2010 08:40:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 855238FC08; Fri, 2 Jul 2010 08:40:09 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C963341C752; Fri, 2 Jul 2010 10:40:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 9GMqwI4nVmFR; Fri, 2 Jul 2010 10:40:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D90CA41C7A5; Fri, 2 Jul 2010 10:40:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A547E4448EC; Fri, 2 Jul 2010 08:39:43 +0000 (UTC) Date: Fri, 2 Jul 2010 08:39:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Chao Shin In-Reply-To: Message-ID: <20100702083902.D14969@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Sam Leffler , Qing Li Subject: Re: panic: rtqkill route really not free on freebsd 8.0-release update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 08:40:09 -0000 On Sat, 5 Jun 2010, Chao Shin wrote: Hey, > We add kdb/ddb and extra panic info printing into kernel and catch this panic > again. > > We have instrumented the kernel and found that this panic happens when > draining == 1, > but seems to be confused with the fact that all access to radix trees are > protected > by locks. Can anyone familiar with these code shed us some light on this? > > below is url to screenshot in ddb: > http://www.delphij.net/zhao/1.png > http://www.delphij.net/zhao/2.png Did anyone pick this up? /bz -- Bjoern A. Zeeb From August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 14:29:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1504F106566C for ; Fri, 2 Jul 2010 14:29:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7868FC15 for ; Fri, 2 Jul 2010 14:29:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o62ETNHf066199; Sat, 3 Jul 2010 00:29:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Jul 2010 00:29:23 +1000 (EST) From: Ian Smith To: Garrett Cooper In-Reply-To: Message-ID: <20100702234212.B54166@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Deterministic lockup / panic in networking stack with ipfw / natd enabled on recent amd64 STABLE / CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:29:33 -0000 On Tue, 15 Jun 2010, Garrett Cooper wrote: > Hi, > I'm experiencing a deterministic situation on a development box I > manage when I do the following to enable ipfw and natd to bridge a > network with two bce(4) enabled NICs, where if I do the following > steps below, then try to push a few tcp frames through, the kernel > either hardlocks, or panics in the bce(4) code, ipfw(4) code or > networking stack code. > My kernel is relatively vanilla (I just turned off a number of > drivers that I don't use because the hardware support isn't there), > and all of the networking options available in GENERIC are enabled as > well. I have ipfw, ipfw_nat, and libalias built as modules, along with > bce and em. > I've included the stats on the machine. Note that it is a dual > SMT-enabled quad core machine with 8GB of RAM. I haven't done anything > to pimp the box settings via make.conf whatsoever. I would provide a > crashdump, but dumpon is broken on the box (which is extremely > annoying). Please note that pf doesn't have any issues pushing packets > with similar rules. > This has occurred on both 8-STABLE (r209169), and 9-CURRENT (r208809). > Here's the manual procedure for reproducing the issue: > > # Do the following steps (this isn't automated apparently as it > completely blocks off a running box, when using ipfw restart is run). > > # Copy the 8.0-RELEASE copy of rc.firewall over > cp -p /usr/src/etc/rc.firewall /etc > > # Make sure you have access via ssh being redirected via natd. > echo "redirect_port tcp 192.168.10.1:22 22" > /etc/natd.conf > > # Enable all of the required services and knobs > cat >> /etc/rc.conf < firewall_enable="YES" > firewall_logging="YES" > firewall_nat_enable="YES" > firewall_nat_interface="bce1" > firewall_type="open" > gateway_enable="YES" > ipfw_enable="YES" > natd_enable="YES" > natd_interface="bce1" > natd_flags="-dynamic -d -m" > EOF Garrett I missed this earlier; here from your ref in the TSO thread. If you enable both firewall_nat and natd as above, on that config you should have wound up with two of ipfw rule 50, like 50 divert 8668 ip4 from any to any via bce1 50 nat 123 ip4 from any to any via bce1 but I don't think you really wanted to run natd then firewall_nat again like that? Also I'm pretty sure you'd need to include '-f /etc/natd.conf' in your natd_flags for your redirect_port config, here's no default configfile for natd (AFAIK) > # Add the needed firewall rule after `Allow setup of incoming email'. > echo '${fwcmd} add 10 allow tcp from any to me 22 keep-state' >> > /etc/rc.firewall > > # Start ipfw. > /etc/rc.d/ipfw start > > # > # To cause either a panic or lockup, you can also do something simple like > # open up an ssh connection beforehand, and just open a textfile (say > rc.firewall), > # then page up and page down the textfile. > # > # My recommendation for absolute determinism though is to transfer a > large file via > # scp, like so: > # > # dd if=/dev/zero of=largefile bs=10m count=20 > # scp largefile : > # > # The scp was how the issue was discovered originally. > # If it's really running both natd and kernel nat at once, I'm not too surprised if it comes unstuck .. (the possible TSO issue as well aside) I guess rc.firewall ought to be checking that natd_enable and firewall_nat_enable aren't both YES .. cheers, Ian > I'm poking around with the box to get a textdump and kernel core, > because it appears to be alluding me at the moment. I'll track down > whether or not the MFC via r205511 had anything to do with this by > using a GENERIC kernel. I've also pruned all of the awesome settings > that someone else set in loader.conf to see if that is fubaring up the > system. > If you need any more details or need for me to test this problem > out in my environment, please let me know. > Thanks, > -Garrett > > PS Please CC me in all emails as I'm not subscribed to this list. > > $ kldstat -v > Id Refs Address Size Name > 1 7 0xffffffff80100000 822f70 kernel (/boot/kernel/kernel) > Contains modules: > Id Name > 64 ataraid > 167 if_lo > 215 elf32 > 155 elf64 > 156 shell > 141 pseudofs > 171 mld > 170 igmp > 169 if_vlan > 165 if_faith > 166 if_gif > 168 if_tun > 160 sysvmsg > 163 sem > 161 sysvsem > 162 sysvshm > 178 krpc > 176 nfssvc > 175 nfsserver > 177 nfslockd > 172 nfs_common > 179 ufs > 173 nfs > 154 cd9660 > 140 procfs > 139 msdosfs > 138 devfs > 35 ata > 7 cam > 15 pass > 11 probe > 150 g_part_mbr > 149 g_part_gpt > 148 g_part_ebr > 147 g_part_bsd > 13 ada > 8 xpt > 14 da > 12 cd > 9 aprobe > 10 pmp > 125 at91_udp/usbus > 124 uss820/usbus > 123 pci/uhci > 122 pci/ohci > 121 pci/ehci > 41 pci/ata_acard > 120 pci/uart > 119 isa/uart > 118 acpi/uart > 40 pci/ata_ahci > 39 atapci/ata_ahci_ata > 117 random > 116 pci/ppc > 115 isa/ppc > 114 acpi/ppc > 113 ppbus/ppi > 174 nfslock > 23 acpi/acpi_isab > 112 ppc/ppbus > 111 ppbus/lpt > 38 pci/atapci > 110 pci/vgapci > 109 pci/pcib > 108 pcib/pci > 37 atapci/ata > 36 isa/ata > 29 cpu/acpi_perf > 18 acpi/acpi_button > 219 cpu/p4tcc > 218 cpu/hwpstate > 28 pci/acpi_pcib > 27 acpi/acpi_pcib > 217 cpu/est > 216 cpu/powernow > 22 acpi/acpi_hpet > 20 acpi/cpu > 107 pci/isab > 106 pci/ignore_pci > 105 pci/hostb > 214 isa/vga > 213 vgapci/vgapm > 104 pci/fixup_pci > 212 isa/sc > 211 isa/atrtc > 210 acpi/atrtc > 103 null > 209 scrndr-vga > 208 scterm-scteken > 207 io > 102 miibus/xmphy > 101 miibus/ukphy > 206 atkbdc/psm > 205 isa/psmcpnp > 204 acpi/psmcpnp > 100 miibus/truephy > 203 isa/atkbdc > 202 acpi/atkbdc > 201 atkbdc/atkbd > 200 hostb/agp_via > 199 hostb/agp_intel > 198 vgapci/agp_i810 > 197 hostb/agp_amd64 > 157 cpu/cpufreq > 99 miibus/tlphy > 196 legacy/pcib > 195 isa/pcibus_pnp > 194 isa/atdma > 193 acpi/atdma > 192 legacy/isa > 98 miibus/tdkphy > 97 miibus/smcphy > 191 isa/attimer > 190 acpi/attimer > 96 miibus/ruephy > 95 miibus/rlphy > 189 root/nexus > 188 nexus/ram > 187 isa/sysresource > 94 miibus/rgephy > 93 miibus/qsphy > 92 miibus/pnaphy > 91 miibus/nsphyter > 90 miibus/nsphy > 89 miibus/nsgphy > 88 miibus/mlphy > 87 miibus/lxtphy > 86 miibus/jmphy > 85 miibus/ip1000phy > 84 miibus/inphy > 83 miibus/icsphy > 153 isa/orm > 186 nexus/legacy > 185 legacy/cpu > 82 miibus/gentbi > 152 isab/isa > 184 pci/ioapic > 183 nexus/apic > 151 eisab/isa > 182 acpi/fpupnp > 81 miibus/xlphy > 80 miibus/e1000phy > 79 miibus/ciphy > 78 miibus/brgphy > 77 miibus/bmtphy > 76 miibus/axphy > 75 miibus/atphy > 74 miibus/amphy > 73 miibus/acphy > 72 mfi/mfid > 181 root/nexus_acpi > 71 pci/mfi > 16 nexus/acpi > 17 acpi/acpi_acad > 26 acpi/acpi_pci_link > 34 acpi/acpi_timer > 70 mem > 33 cpu/acpi_throttle > 32 acpi/acpi_tz > 19 acpi/acpi_cmbat > 25 pcib/acpi_pci > 31 acpi/acpi_smbat > 68 kbdmux > 67 cpu/ichss > 30 acpi/acpi_sysresource > 66 ata/acd > 21 acpi/acpi_ec > 65 ad/subdisk > 24 acpi/acpi_lid > 63 ata/ad > 62 pci/ata_via > 61 pci/ata_sis > 60 pci/ata_sii > 59 pci/ata_serverworks > 58 pci/ata_promise > 57 pci/ata_nvidia > 56 pci/ata_netcell > 55 pci/ata_national > 137 watchdog > 54 pci/ata_micron > 136 uhub/ums > 135 uhub/ukbd > 134 uhub/uhid > 53 pci/ata_marvell > 52 pci/ata_jmicron > 51 pci/ata_ite > 133 uhub/ulpt > 132 usbus/uhub > 131 uhub/uhub > 50 pci/ata_intel > 49 pci/ata_highpoint > 48 pci/ata_cyrix > 47 pci/ata_cypress > 46 pci/ata_cenatek > 45 pci/ata_ati > 44 pci/ata_amd > 43 pci/ata_adaptec > 130 uhub/usb_linux > 129 uhub/umass > 42 pci/ata_ali > 128 ohci/usbus > 127 uhci/usbus > 126 ehci/usbus > 144 g_vfs > 146 g_part > 180 g_class > 143 g_disk > 142 g_dev > 158 rootbus > 69 g_md > 159 firmware > 145 g_label > 164 ether > 220 x86bios > 2 1 0xffffffff80923000 50680 if_bce.ko (/boot/kernel/if_bce.ko) > Contains modules: > Id Name > 2 pci/bce > 1 bce/miibus > $ uname -a > FreeBSD tameshi.cisco.com 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0 > r209169: Mon Jun 14 12:41:49 PDT 2010 > root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE amd64 > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.1-PRERELEASE #0 r209169: Mon Jun 14 12:41:49 PDT 2010 > root@:/usr/obj/data/scratch/src/stable/8/sys/TAMESHI_STABLE amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU X5460 @ 3.16GHz (3158.76-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 > Features=0xbfebfbff > Features2=0xce3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 8589934592 (8192 MB) > avail memory = 8289869824 (7905 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci4: on pcib1 > pcib2: at device 0.0 on pci4 > pci5: on pcib2 > pcib3: at device 0.0 on pci5 > pci6: on pcib3 > pcib4: at device 0.0 on pci6 > pci7: on pcib4 > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 > miibus0: on bce0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bce0: Ethernet address: 00:1e:4f:38:65:ad > bce0: [ITHREAD] > bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (3.5.12); Flags (MSI|MFW); MFW (ipms 1.6.0) > pcib5: at device 1.0 on pci5 > pci8: on pcib5 > pcib6: at device 0.3 on pci4 > pci9: on pcib6 > pcib7: at device 3.0 on pci0 > pci1: on pcib7 > mfi0: port 0xec00-0xecff mem > 0xfc480000-0xfc4bffff,0xfc440000-0xfc47ffff irq 16 at device 0.0 on > pci1 > mfi0: Megaraid SAS driver Ver 3.00 > mfi0: 18149 (329945474s/0x0020/info) - Shutdown command received from host > mfi0: 18150 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/1f0c/1028) > mfi0: 18151 (boot + 3s/0x0020/info) - Firmware version 1.21.02-0528 > mfi0: 18152 (boot + 3s/0x0008/info) - Battery Present > mfi0: 18153 (boot + 3s/0x0020/info) - Controller hardware revision ID (0x0) > mfi0: 18154 (boot + 3s/0x0020/info) - Package version 6.1.1-0047 > mfi0: 18155 (boot + 3s/0x0020/info) - Board Revision > mfi0: 18156 (boot + 32s/0x0002/info) - Unexpected sense: Encl PD 20 > Path 5001e0f03434f000, CDB: 12 00 00 00 04 00, Sense: 6/29/00 > mfi0: 18157 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > communication restored > mfi0: 18158 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18159 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18160 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18161 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18162 (boot + 33s/0x0002/info) - Inserted: Encl PD 20 > mfi0: 18163 (boot + 33s/0x0002/info) - Inserted: PD 20(c None/p0) > Info: enclPd=20, scsiType=d, portMap=09, > sasAddr=5001e0f03434f000,0000000000000000 > mfi0: 18164 (boot + 33s/0x0002/info) - Inserted: PD 00(e0x20/s0) > mfi0: 18165 (boot + 33s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: > enclPd=20, scsiType=0, portMap=00, > sasAddr=5000c50008fe5169,0000000000000000 > mfi0: 18166 (boot + 33s/0x0002/info) - Inserted: PD 01(e0x20/s1) > mfi0: 18167 (boot + 33s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: > enclPd=20, scsiType=0, portMap=01, > sasAddr=5000c50008fe538d,0000000000000000 > mfi0: 18168 (boot + 33s/0x0002/info) - Inserted: PD 02(e0x20/s2) > mfi0: 18169 (boot + 33s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: > enclPd=20, scsiType=0, portMap=02, > sasAddr=5000c50008fe3999,0000000000000000 > mfi0: 18170 (boot + 33s/0x0002/info) - Inserted: PD 03(e0x20/s3) > mfi0: 18171 (boot + 33s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: > enclPd=20, scsiType=0, portMap=03, > sasAddr=5000c50008fe36c9,0000000000000000 > mfi0: 18172 (329945552s/0x0020/info) - Time established as 06/15/10 > 19:32:32; (36 seconds since power on) > mfi0: 18173 (329945584s/0x0008/info) - Battery temperature is normal > mfi0: 18174 (329945584s/0x0008/info) - Battery started charging > mfi0: 18175 (329945584s/0x0008/info) - Current capacity of the battery > is above threshold > mfi0: 18176 (329946819s/0x0008/info) - Battery charge complete > mfi0: 18177 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/1f0c/1028) > mfi0: 18178 (boot + 3s/0x0020/info) - Firmware version 1.21.02-0528 > mfi0: 18179 (boot + 3s/0x0008/info) - Battery Present > mfi0: 18180 (boot + 3s/0x0020/info) - Controller hardware revision ID (0x0) > mfi0: 18181 (boot + 3s/0x0020/info) - Package version 6.1.1-0047 > mfi0: 18182 (boot + 3s/0x0020/info) - Board Revision > mfi0: 18183 (boot + 32s/0x0002/info) - Unexpected sense: Encl PD 20 > Path 5001e0f03434f000, CDB: 12 00 00 00 04 00, Sense: 6/29/00 > mfi0: 18184 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > communication restored > mfi0: 18185 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18186 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18187 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18188 (boot + 33s/0x0004/info) - Enclosure PD 20(c None/p0) > element (SES code 0x17) status changed > mfi0: 18189 (boot + 33s/0x0002/info) - Inserted: Encl PD 20 > mfi0: 18190 (boot + 33s/0x0002/info) - Inserted: PD 20(c None/p0) > Info: enclPd=20, scsiType=d, portMap=09, > sasAddr=5001e0f03434f000,0000000000000000 > mfi0: 18191 (boot + 33s/0x0002/info) - Inserted: PD 00(e0x20/s0) > mfi0: 18192 (boot + 33s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: > enclPd=20, scsiType=0, portMap=00, > sasAddr=5000c50008fe5169,0000000000000000 > mfi0: 18193 (boot + 33s/0x0002/info) - Inserted: PD 01(e0x20/s1) > mfi0: 18194 (boot + 33s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: > enclPd=20, scsiType=0, portMap=01, > sasAddr=5000c50008fe538d,0000000000000000 > mfi0: 18195 (boot + 33s/0x0002/info) - Inserted: PD 02(e0x20/s2) > mfi0: 18196 (boot + 33s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: > enclPd=20, scsiType=0, portMap=02, > sasAddr=5000c50008fe3999,0000000000000000 > mfi0: 18197 (boot + 33s/0x0002/info) - Inserted: PD 03(e0x20/s3) > mfi0: 18198 (boot + 33s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: > enclPd=20, scsiType=0, portMap=03, > sasAddr=5000c50008fe36c9,0000000000000000 > mfi0: 18199 (329947433s/0x0020/info) - Time established as 06/15/10 > 20:03:53; (36 seconds since power on) > mfi0: 18200 (329947465s/0x0008/info) - Battery temperature is normal > mfi0: 18201 (329947465s/0x0008/info) - Battery started charging > mfi0: 18202 (329947465s/0x0008/info) - Current capacity of the battery > is above threshold > mfi0: 18203 (329947595s/0x0008/info) - Battery charge complete > mfi0: 18204 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/1f0c/1028) > mfi0: 18205 (boot + 3s/0x0020/info) - Firmware version 1.21.02-0528 > mfi0: 18206 (boot + 3s/0x0008/info) - Battery Present > mfi0: 18207 (boot + 3s/0x0020/info) - Controller hardware revision ID (0x0) > mfi0: 18208 (boot + 3s/0x0020/info) - Package version 6.1.1-0047 > mfi0: 18209 (boot + 3s/0x0020/info) - Board Revision > mfi0: 18210 (boot + 21s/0x0004/info) - Enclosure PD 20(c None/p0) > communication restored > mfi0: 18211 (boot + 21s/0x0002/info) - Inserted: Encl PD 20 > mfi0: 18212 (boot + 21s/0x0002/info) - Inserted: PD 20(c None/p0) > Info: enclPd=20, scsiType=d, portMap=09, > sasAddr=5001e0f03434f000,0000000000000000 > mfi0: 18213 (boot + 21s/0x0002/info) - Inserted: PD 00(e0x20/s0) > mfi0: 18214 (boot + 21s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: > enclPd=20, scsiType=0, portMap=00, > sasAddr=5000c50008fe5169,0000000000000000 > mfi0: 18215 (boot + 22s/0x0002/info) - Inserted: PD 01(e0x20/s1) > mfi0: 18216 (boot + 22s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: > enclPd=20, scsiType=0, portMap=01, > sasAddr=5000c50008fe538d,0000000000000000 > mfi0: 18217 (boot + 22s/0x0002/info) - Inserted: PD 02(e0x20/s2) > mfi0: 18218 (boot + 22s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: > enclPd=20, scsiType=0, portMap=02, > sasAddr=5000c50008fe3999,0000000000000000 > mfi0: 18219 (boot + 22s/0x0002/info) - Inserted: PD 03(e0x20/s3) > mfi0: 18220 (boot + 22s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: > enclPd=20, scsiType=0, portMap=03, > sasAddr=5000c50008fe36c9,0000000000000000 > mfi0: 18221 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/1f0c/1028) > mfi0: 18222 (boot + 3s/0x0020/info) - Firmware version 1.21.02-0528 > mfi0: 18223 (boot + 3s/0x0008/info) - Battery Present > mfi0: 18224 (boot + 3s/0x0020/info) - Controller hardware revision ID (0x0) > mfi0: 18225 (boot + 3s/0x0020/info) - Package version 6.1.1-0047 > mfi0: 18226 (boot + 3s/0x0020/info) - Board Revision > mfi0: 18227 (boot + 21s/0x0004/info) - Enclosure PD 20(c None/p0) > communication restored > mfi0: 18228 (boot + 21s/0x0002/info) - Inserted: Encl PD 20 > mfi0: 18229 (boot + 21s/0x0002/info) - Inserted: PD 20(c None/p0) > Info: enclPd=20, scsiType=d, portMap=09, > sasAddr=5001e0f03434f000,0000000000000000 > mfi0: 18230 (boot + 21s/0x0002/info) - Inserted: PD 00(e0x20/s0) > mfi0: 18231 (boot + 21s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: > enclPd=20, scsiType=0, portMap=00, > sasAddr=5000c50008fe5169,0000000000000000 > mfi0: 18232 (boot + 22s/0x0002/info) - Inserted: PD 01(e0x20/s1) > mfi0: 18233 (boot + 22s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: > enclPd=20, scsiType=0, portMap=01, > sasAddr=5000c50008fe538d,0000000000000000 > mfi0: 18234 (boot + 22s/0x0002/info) - Inserted: PD 02(e0x20/s2) > mfi0: 18235 (boot + 22s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: > enclPd=20, scsiType=0, portMap=02, > sasAddr=5000c50008fe3999,0000000000000000 > mfi0: 18236 (boot + 22s/0x0002/info) - Inserted: PD 03(e0x20/s3) > mfi0: 18237 (boot + 22s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: > enclPd=20, scsiType=0, portMap=03, > sasAddr=5000c50008fe36c9,0000000000000000 > mfi0: [ITHREAD] > pcib8: at device 4.0 on pci0 > pci10: on pcib8 > pcib9: at device 5.0 on pci0 > pci11: on pcib9 > pcib10: at device 6.0 on pci0 > pci12: on pcib10 > pcib11: at device 7.0 on pci0 > pci13: on pcib11 > pci0: at device 8.0 (no driver attached) > pcib12: at device 28.0 on pci0 > pci2: on pcib12 > pcib13: at device 0.0 on pci2 > pci3: on pcib13 > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 > miibus1: on bce1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bce1: Ethernet address: 00:1e:4f:38:65:ab > bce1: [ITHREAD] > bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (3.5.12); Flags (MSI|MFW); MFW (ipms 1.6.0) > uhci0: port > 0xcce0-0xccff irq 21 at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port > 0xccc0-0xccdf irq 20 at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port > 0xcca0-0xccbf irq 21 at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port > 0xcc80-0xcc9f irq 20 at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xfc500000-0xfc5003ff > irq 21 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib14: at device 30.0 on pci0 > pci14: on pcib14 > vgapci0: port 0xdc00-0xdcff mem > 0xd8000000-0xdfffffff,0xfc2d0000-0xfc2dffff irq 19 at device 13.0 on > pci14 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atrtc0: port 0x70-0x7f irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > orm0: at iomem > 0xc0000-0xc8fff,0xc9000-0xc9fff,0xec000-0xeffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > est4: on cpu4 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est4 attach returned 6 > p4tcc4: on cpu4 > est5: on cpu5 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est5 attach returned 6 > p4tcc5: on cpu5 > est6: on cpu6 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est6 attach returned 6 > p4tcc6: on cpu6 > est7: on cpu7 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 4921492106004921 > device_attach: est7 attach returned 6 > p4tcc7: on cpu7 > Timecounters tick every 10.000 msec > mfi0: 18238 (329948437s/0x0020/info) - Time established as 06/15/10 > 20:20:37; (24 seconds since power on) > mfi0: 18239 (329948481s/0x0008/info) - Battery temperature is normal > mfi0: 18240 (329948481s/0x0008/info) - Current capacity of the battery > is above threshold > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > mfid0: on mfi0 > mfid0: 571136MB (1169686528 sectors) RAID volume '' is optimal > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #6 Launched! > ugen3.1: at usbus3ugen0.1: at usbus0ugen2.1: > at usbus2ugen1.1: at usbus1 > uhub0: > on usbus3 > > uhub1: > on usbus0 > uhub2: on usbus2 > uhub3: on usbus1 > ugen4.1: at usbus4 > uhub4: on usbus4 > Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > uhub4: 8 ports with 8 removable, self powered > Root mount waiting for: usbus4 > ugen4.2: at usbus4 > uhub5: 2> on usbus4 > uhub5: 4 ports with 4 removable, self powered > Root mount waiting for: usbus4 > ugen4.3: at usbus4 > uhub6: on usbus4 > Root mount waiting for: usbus4 > uhub6: 3 ports with 2 removable, bus powered > ugen4.4: at usbus4 > ukbd0: on usbus4 > kbd2 at ukbd0 > uhid0: on usbus4 > Trying to mount root from ufs:/dev/mfid0s1a > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 14:32:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AA33106566B for ; Fri, 2 Jul 2010 14:32:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52B128FC15 for ; Fri, 2 Jul 2010 14:32:29 +0000 (UTC) Received: by gyd8 with SMTP id 8so473162gyd.13 for ; Fri, 02 Jul 2010 07:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+kLBdSjvUnAHuubAvFYboXCB3hNyOc4gA9McEvhMSZQ=; b=QwerhVa57KqYf/9cyxVYkuQLYkz4RFmO8OrHjFDR3aySP1YF3WmmosOKWbHt2+C3pN 5in5uU5dECBC2UZT5/gzAZnMcub5yWdRTx+TWmswatdGKPS/iQx1njA66EAfDNBuOGku psWm5L3nJlMUc+1lzkEDlaKLG0hIyW/osZWps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qersaNnHJpfl/lPKUwXgVQetUysPXD3eXp9wKCs7BhF7FyjqK2YsCiVMk8ezbGHSn6 ERGI2m4c4wUM85hR/at+tuS+FR1/U65mzgkvHdTEvuxFHPfLOcQE+MhFotmDB8JL0Rbo P89qqiWAbIxxC5NQgodTMeC3OuPpjT6RNKC9s= MIME-Version: 1.0 Received: by 10.229.230.65 with SMTP id jl1mr576796qcb.15.1278081145412; Fri, 02 Jul 2010 07:32:25 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Fri, 2 Jul 2010 07:32:25 -0700 (PDT) In-Reply-To: References: <20100701235447.GJ7090@michelle.cdnetworks.com> <20100702022058.GA32531@babolo.ru> Date: Fri, 2 Jul 2010 07:32:25 -0700 Message-ID: From: Garrett Cooper To: Aleksandr A Babaylov <.@babolo.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pyun YongHyeon , net@freebsd.org Subject: Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:32:29 -0000 On Thu, Jul 1, 2010 at 10:32 PM, Garrett Cooper wrote: > On Thu, Jul 1, 2010 at 7:20 PM, Aleksandr A Babaylov <.@babolo.ru> wrote: >> On Thu, Jul 01, 2010 at 04:54:47PM -0700, Pyun YongHyeon wrote: >>> On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: >>> > Hi, >>> > =A0 =A0 Just an observation I made while transferring a file: >>> > >>> > # time scp floppy.img somehost: >>> > Password: >>> > floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0100% 1440KB =A013.7KB/s =A0 01:45 >>> > >>> > real =A0 =A0 =A0 =A01m59.400s >>> > user =A0 =A0 =A0 =A00m0.031s >>> > sys 0m0.028s >>> > # sysctl net.inet.tcp.tso=3D0 >>> > net.inet.tcp.tso: 1 -> 0 >>> > # time scp floppy.img somehost: >>> > floppy.img =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0100% 1440KB =A0 1.4MB/s =A0 00:00 >>> > >>> > real =A0 =A0 =A0 =A00m0.712s >>> > user =A0 =A0 =A0 =A00m0.018s >>> > sys 0m0.018s >>> > >>> > =A0 =A0 Going ISDN speeds transferring a 1.44MB file is sad when you = have >>> > a gigabit uplink :(... natd seems to be doing a LOT of spinning when >>> > TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core >>> > machine). >>> I would use pf(4) if I have to handle lots of NAT rules. >> Or ipfw nat. >> man ipfw | grep nat > > =A0 =A0That uses the kernel module though, and that's horribly broken on > my machine with 8-STABLE/9-CURRENT (see: > http://www.mail-archive.com/freebsd-net@freebsd.org/msg33518.html ). I > wonder if that's related to the TSO issue. As Vitezslav pointed out to me off-list, this is a known issue with libalias and IPFW: Due to the architecture of libalias(3), ipfw nat is not compatible wit= h the TCP segmentation offloading (TSO). Thus, to reliably nat your net= - work traffic, please disable TSO on your NICs using ifconfig(8). Both the ipfw kernel based nat'ing and natd use libalias, so both will be affected by this issue. This needs to be fixed (I'll see what I can do to help expedite this). Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 19:03:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31DE10656EF for ; Fri, 2 Jul 2010 19:03:31 +0000 (UTC) (envelope-from jdixon@omniti.com) Received: from edge.omniti.com (smtp.omniti.com [8.8.38.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9866D8FC14 for ; Fri, 2 Jul 2010 19:03:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; d=omniti.com; s=s1024; c=relaxed/relaxed; q=dns/txt; i=@omniti.com; t=1278096045; h=From:Subject:Date:To; bh=5mW/o0Yolk6i0ziVhBG6Cou4Hi1vnQwwKX1QuEi5AVE=; b=GuLc+IEKmSVW6o79mqF5RdGZoQZzmtATe3rTTpakZ34Xy1QQ+4WD4RhvKE/ccLzE Nv6h1J6ck38zjONBdX233pwtyZz1qKPmJgbfOBAzJZH6RIq3qTqFHph9ZNlZC/K3 vnWW/QhebaxG+VHte78Z49ICXM/TtR04hoJRGxoUkTU=; Authentication-Results: edge smtp.user=jdixon@omniti.com; auth=pass (LOGIN) Received: from [68.55.0.29] ([68.55.0.29:56620] helo=omniti.com) by edge (envelope-from ) (ecelerity 2.2.2.35 r(26636M)) with ESMTPSA (cipher=AES256-SHA) id D2/88-17327-DA23E2C4; Fri, 02 Jul 2010 14:40:45 -0400 Date: Fri, 2 Jul 2010 14:40:41 -0400 From: Jason Dixon To: freebsd-net@freebsd.org Message-ID: <20100702184041.GB29381@omniti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: CFP for Surge Scalability Conference 2010 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 19:03:31 -0000 A quick reminder that there's one week left to submit your abstract for this year's Surge Scalability Conference. The event is taking place on Sept 30 and Oct 1, 2010 in Baltimore, MD. Surge focuses on case studies that address production failures and the re-engineering efforts that led to victory in Web Applications or Internet Architectures. Our Keynote speakers include John Allspaw and Theo Schlossnagle. We are currently accepting submissions for the Call For Papers through July 9th. You can find more information, including suggested topics and our current list of speakers, online: http://omniti.com/surge/2010 I'd also like to urge folks who are planning to attend, to get your session passes sooner rather than later. We have limited seating and we are on track to sell out early. For more information, including the CFP, sponsorship of the event, or participating as an exhibitor, please visit the Surge website or contact us at surge@omniti.com. Thanks, -- Jason Dixon OmniTI Computer Consulting, Inc. jdixon@omniti.com 443.325.1357 x.241 From owner-freebsd-net@FreeBSD.ORG Fri Jul 2 21:26:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E1B1065689; Fri, 2 Jul 2010 21:26:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id D47EE8FC12; Fri, 2 Jul 2010 21:26:54 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 7F9CBA5A397; Sat, 3 Jul 2010 05:26:53 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id W2Ktkzo7Dq+W; Sat, 3 Jul 2010 05:26:46 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id DA7CDA58F63; Sat, 3 Jul 2010 05:26:42 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=FZkEJRtcTKigXyjKQD25o5iHxnXPZlRo9kdVhOsGeZWo7T19sHQmEGizzx4/GHaB4 KUiIMyc9URYCu44mB6D+w== Message-ID: <4C2E598D.2000201@delphij.net> Date: Fri, 02 Jul 2010 14:26:37 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20100702083902.D14969@maildrop.int.zabbadoz.net> In-Reply-To: <20100702083902.D14969@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------020702050108020907030608" Cc: "freebsd-net@freebsd.org" , Sam Leffler , Chao Shin , Qing Li Subject: Re: panic: rtqkill route really not free on freebsd 8.0-release update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:26:56 -0000 This is a multi-part message in MIME format. --------------020702050108020907030608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Bjoern, On 2010/07/02 01:39, Bjoern A. Zeeb wrote: > On Sat, 5 Jun 2010, Chao Shin wrote: > > Hey, > >> We add kdb/ddb and extra panic info printing into kernel and catch >> this panic again. >> >> We have instrumented the kernel and found that this panic happens when >> draining == 1, >> but seems to be confused with the fact that all access to radix trees >> are protected >> by locks. Can anyone familiar with these code shed us some light on >> this? >> >> below is url to screenshot in ddb: >> http://www.delphij.net/zhao/1.png >> http://www.delphij.net/zhao/2.png > > Did anyone pick this up? I don't think so. Currently we believe that there is some call paths that would exhibit the following: Thread A Thread B (...) RTLOCK(rt) rt->ref--; [ref drops to 0 now] (obtain rnh_lock) (in in_matroute) saw rt->ref == 0 rt->rt_flags & RTPRF_OURS == 0 (return from in_matroute()) RT_LOCK(rt) <-- blocks here rt->rt_flags |= OURS RT_UNLOCK(rt); RT_LOCK(rt) <-- got a wakeup rt->ref++ (ref == 1 && rt->rt_flags & RTPRF_OURS) With the attached workaround they have not see this type of panics so far but that doesn't seem ideal. Kip and Qing's paper titled "Optimizing the BSD routing system for parallel processing" suggests copying the route entry rather than referencing it but I didn't yet on how should I implement that and do benchmark... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMLlmNAAoJEATO+BI/yjfBzvAIANjmEXX54lryJ6Qq37yUFdmd BQqw7r/Q7IYD6gOBU0/iMUySa4x6H3U+8TPUK8Rf+ARkG8CP3JsRMPJtLkFs5Eby lmvQDRcfcKzFCAC40m/FmdlCl0c2Q/mz5H4PYve3zuU+BEDN0NOEIUtnYVmOJK1U 4O5XXZcAzNT1BXKKwbogwQq0t4dhT/3+4inH6vC3w8HpzwDfXS2GogFSOYlSurvC h7b2wjrD7sgTPZZj1DN7qWjGSRNAao+AGzlzvQR6tNCqWV+bn8qF+QaNoFepev+g ITeUh9IXffn646WCRF5whKUjz+M9IvSPhqGiFyWfhcGj8DbDt074XMsHiBLh7nc= =lHSK -----END PGP SIGNATURE----- --------------020702050108020907030608 Content-Type: text/plain; name="in_rmx-v2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="in_rmx-v2.diff" Index: in_rmx.c =================================================================== --- in_rmx.c (revision 208681) +++ in_rmx.c (working copy) @@ -121,12 +121,12 @@ struct radix_node *rn = rn_match(v_arg, head); struct rtentry *rt = (struct rtentry *)rn; - /*XXX locking? */ - if (rt && rt->rt_refcnt == 0) { /* this is first reference */ - if (rt->rt_flags & RTPRF_OURS) { - rt->rt_flags &= ~RTPRF_OURS; - rt->rt_rmx.rmx_expire = 0; - } + if (rt && rt->rt_refcnt == 0 && /* this is first reference */ + rt->rt_flags & RTPRF_OURS) { + RT_LOCK(rt); + rt->rt_flags &= ~RTPRF_OURS; + rt->rt_rmx.rmx_expire = 0; + RT_UNLOCK(rt); } return rn; } @@ -206,6 +206,7 @@ RADIX_NODE_HEAD_WLOCK_ASSERT(ap->rnh); + RT_LOCK(rt); if (rt->rt_flags & RTPRF_OURS) { ap->found++; @@ -234,6 +235,7 @@ rt->rt_rmx.rmx_expire); } } + RT_UNLOCK(rt); return 0; } --------------020702050108020907030608-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 3 00:27:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE9E1065673 for ; Sat, 3 Jul 2010 00:27:30 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 846758FC1C for ; Sat, 3 Jul 2010 00:27:30 +0000 (UTC) Received: by ewy26 with SMTP id 26so1347552ewy.13 for ; Fri, 02 Jul 2010 17:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=gnyjBs28Sjg8RjkGYjJOT9CZFbDdFt3KM4RipVVrK1M=; b=iolhynCNro6F+71kaYaqQICOZyPfd+OdVc1huSOyN5O9gPc6HgtT05JhHyXaC0SEdl E26+Cnu6g8mNC3tJOBytCP0AOc07zWJTefj2VFuigsCdvtT8BTjDb4SGZVaH7bLJJ5lv pWJC7yiOSlHMAbi2t223l8A1qQrP/BmAgIrlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=czOVpoAQRWNMeOfoVrDwc8qhYk1V4SZ/Z2f5EBOnx6MrVleIuixxzpdaTtJUWCBKSo F1IWDNMasH/lACyPShNn0ql/t2z/LmMEnb62xpQohVXAmD4NhONpIvkEP7gDynXu9aIu ZzFZ/OGflHsxFpAeUIlgud7ScJlBB+qaLq8TU= MIME-Version: 1.0 Received: by 10.213.108.203 with SMTP id g11mr4704981ebp.35.1278116844596; Fri, 02 Jul 2010 17:27:24 -0700 (PDT) Received: by 10.213.35.10 with HTTP; Fri, 2 Jul 2010 17:27:24 -0700 (PDT) Date: Fri, 2 Jul 2010 20:27:24 -0400 Message-ID: From: Ryan Stone To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Any work being done on ath9k/athn WiFi support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:27:31 -0000 I just bought a laptop with a Atheros AR9XXX and as far as I can tell there is no driver support yet in FreeBSD. Some googling has seemed to indicate that there is a driver in OpenBSD(athn) that supports this family of cards. I was wondering if there was any work underway to port this to FreeBSD. I'm willing to help out in any way possible. If I can find the time I'm willing to work on the port itself. Any information about the current state of athn would be helpful. Thanks, Ryan From owner-freebsd-net@FreeBSD.ORG Sat Jul 3 03:26:38 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48178106564A; Sat, 3 Jul 2010 03:26:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2508FC14; Sat, 3 Jul 2010 03:26:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o633QTca003664; Sat, 3 Jul 2010 13:26:29 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Jul 2010 13:26:29 +1000 (EST) From: Ian Smith To: Garrett Cooper In-Reply-To: <20100702234212.B54166@sola.nimnet.asn.au> Message-ID: <20100703125804.P54166@sola.nimnet.asn.au> References: <20100702234212.B54166@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Deterministic lockup / panic in networking stack with ipfw / natd enabled on recent amd64 STABLE / CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 03:26:38 -0000 On Sat, 3 Jul 2010, Ian Smith wrote: > On Tue, 15 Jun 2010, Garrett Cooper wrote: > > Hi, > > I'm experiencing a deterministic situation on a development box I > > manage when I do the following to enable ipfw and natd to bridge a > > network with two bce(4) enabled NICs, where if I do the following > > steps below, then try to push a few tcp frames through, the kernel > > either hardlocks, or panics in the bce(4) code, ipfw(4) code or > > networking stack code. > > My kernel is relatively vanilla (I just turned off a number of > > drivers that I don't use because the hardware support isn't there), > > and all of the networking options available in GENERIC are enabled as > > well. I have ipfw, ipfw_nat, and libalias built as modules, along with > > bce and em. > > I've included the stats on the machine. Note that it is a dual > > SMT-enabled quad core machine with 8GB of RAM. I haven't done anything > > to pimp the box settings via make.conf whatsoever. I would provide a > > crashdump, but dumpon is broken on the box (which is extremely > > annoying). Please note that pf doesn't have any issues pushing packets > > with similar rules. > > This has occurred on both 8-STABLE (r209169), and 9-CURRENT (r208809). > > Here's the manual procedure for reproducing the issue: > > > > # Do the following steps (this isn't automated apparently as it > > completely blocks off a running box, when using ipfw restart is run). > > > > # Copy the 8.0-RELEASE copy of rc.firewall over > > cp -p /usr/src/etc/rc.firewall /etc > > > > # Make sure you have access via ssh being redirected via natd. > > echo "redirect_port tcp 192.168.10.1:22 22" > /etc/natd.conf > > > > # Enable all of the required services and knobs > > cat >> /etc/rc.conf < > firewall_enable="YES" > > firewall_logging="YES" > > firewall_nat_enable="YES" > > firewall_nat_interface="bce1" > > firewall_type="open" > > gateway_enable="YES" > > ipfw_enable="YES" > > natd_enable="YES" > > natd_interface="bce1" > > natd_flags="-dynamic -d -m" > > EOF > > Garrett I missed this earlier; here from your ref in the TSO thread. > > If you enable both firewall_nat and natd as above, on that config you > should have wound up with two of ipfw rule 50, like > > 50 divert 8668 ip4 from any to any via bce1 > 50 nat 123 ip4 from any to any via bce1 > > but I don't think you really wanted to run natd then firewall_nat again > like that? Oh, sorry .. that's not right; I quite forgot the discussions in ipfw@ about this a while ago, until I re-browsed natd(8): After translation by natd, packets re-enter the firewall at the rule number following the rule number that caused the diversion (not the next rule if there are several at the same number). so in this case only natd should be invoked and the ipfw nat skipped. > Also I'm pretty sure you'd need to include '-f /etc/natd.conf' in your > natd_flags for your redirect_port config, here's no default configfile > for natd (AFAIK) I think that's right - or you can specify -redirect_port in natd_flags. > I guess rc.firewall ought to be checking that natd_enable and > firewall_nat_enable aren't both YES .. .. and that becomes irrelevant, though it's still an ambiguous config. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Jul 3 03:53:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D3C1065670; Sat, 3 Jul 2010 03:53:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7D28FC13; Sat, 3 Jul 2010 03:53:35 +0000 (UTC) Received: by qyk30 with SMTP id 30so774158qyk.13 for ; Fri, 02 Jul 2010 20:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SuwLmyOrBZTrsrVYXW47k/sf2WZHfs3pcyjMg+X1oEI=; b=Dx7I9z8llEkeIOKcMp38pJIWJGONLRdnUeD/t/UrH+pPyf84fAFmQ6LZ3BdLelbuw7 Za4iwzGrgi4/esXJ7U8XYq4NDZE4Q8o3bAm+E7z6MRs43krJMQwiN650B7yrs8HMGntD HmUX2bbW1SqFvdUuMS+OsZAvJxKyFp0ZcmSV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HkfDqU7hnXzinTn2XCwrW2Bfv+OZtWGpvXh2IyNHs449aCBts7Jl4IR6Uo6BgEB+MV w1tJdfEJU01NSLvCrulcUqpSHMI2aQnN3XEqlQdAWqZtUAB2Yqq2mh8P5g3kUkNgybd6 aFOtgxVY0X8GZJaGDD1Lq5DHGujg6zzUvigH0= MIME-Version: 1.0 Received: by 10.224.19.198 with SMTP id c6mr967380qab.127.1278129205105; Fri, 02 Jul 2010 20:53:25 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Fri, 2 Jul 2010 20:53:25 -0700 (PDT) In-Reply-To: <20100703125804.P54166@sola.nimnet.asn.au> References: <20100702234212.B54166@sola.nimnet.asn.au> <20100703125804.P54166@sola.nimnet.asn.au> Date: Fri, 2 Jul 2010 20:53:25 -0700 Message-ID: From: Garrett Cooper To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Deterministic lockup / panic in networking stack with ipfw / natd enabled on recent amd64 STABLE / CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 03:53:36 -0000 On Fri, Jul 2, 2010 at 8:26 PM, Ian Smith wrote: > On Sat, 3 Jul 2010, Ian Smith wrote: > =A0> On Tue, 15 Jun 2010, Garrett Cooper wrote: > =A0> =A0> Hi, > =A0> =A0> =A0 =A0 I'm experiencing a deterministic situation on a develop= ment box I > =A0> =A0> manage when I do the following to enable ipfw and natd to bridg= e a > =A0> =A0> network with two bce(4) enabled NICs, where if I do the followi= ng > =A0> =A0> steps below, then try to push a few tcp frames through, the ker= nel > =A0> =A0> either hardlocks, or panics in the bce(4) code, ipfw(4) code or > =A0> =A0> networking stack code. > =A0> =A0> =A0 =A0 My kernel is relatively vanilla (I just turned off a nu= mber of > =A0> =A0> drivers that I don't use because the hardware support isn't the= re), > =A0> =A0> and all of the networking options available in GENERIC are enab= led as > =A0> =A0> well. I have ipfw, ipfw_nat, and libalias built as modules, alo= ng with > =A0> =A0> bce and em. > =A0> =A0> =A0 =A0 I've included the stats on the machine. Note that it is= a dual > =A0> =A0> SMT-enabled quad core machine with 8GB of RAM. I haven't done a= nything > =A0> =A0> to pimp the box settings via make.conf whatsoever. I would prov= ide a > =A0> =A0> crashdump, but dumpon is broken on the box (which is extremely > =A0> =A0> annoying). Please note that pf doesn't have any issues pushing = packets > =A0> =A0> with similar rules. > =A0> =A0> =A0 =A0 This has occurred on both 8-STABLE (r209169), and 9-CUR= RENT (r208809). > =A0> =A0> =A0 =A0 Here's the manual procedure for reproducing the issue: > =A0> =A0> > =A0> =A0> # Do the following steps (this isn't automated apparently as it > =A0> =A0> completely blocks off a running box, when using ipfw restart is= run). > =A0> =A0> > =A0> =A0> # Copy the 8.0-RELEASE copy of rc.firewall over > =A0> =A0> cp -p /usr/src/etc/rc.firewall /etc > =A0> =A0> > =A0> =A0> # Make sure you have access via ssh being redirected via natd. > =A0> =A0> echo "redirect_port tcp 192.168.10.1:22 22" > /etc/natd.conf > =A0> =A0> > =A0> =A0> # Enable all of the required services and knobs > =A0> =A0> cat >> /etc/rc.conf < =A0> =A0> firewall_enable=3D"YES" > =A0> =A0> firewall_logging=3D"YES" > =A0> =A0> firewall_nat_enable=3D"YES" > =A0> =A0> firewall_nat_interface=3D"bce1" > =A0> =A0> firewall_type=3D"open" > =A0> =A0> gateway_enable=3D"YES" > =A0> =A0> ipfw_enable=3D"YES" > =A0> =A0> natd_enable=3D"YES" > =A0> =A0> natd_interface=3D"bce1" > =A0> =A0> natd_flags=3D"-dynamic -d -m" > =A0> =A0> EOF > =A0> > =A0> Garrett I missed this earlier; here from your ref in the TSO thread. > =A0> > =A0> If you enable both firewall_nat and natd as above, on that config yo= u > =A0> should have wound up with two of ipfw rule 50, like > =A0> > =A0> =A050 divert 8668 ip4 from any to any via bce1 > =A0> =A050 nat 123 ip4 from any to any via bce1 > =A0> > =A0> but I don't think you really wanted to run natd then firewall_nat ag= ain > =A0> like that? > > Oh, sorry .. that's not right; I quite forgot the discussions in ipfw@ > about this a while ago, until I re-browsed natd(8): > > =A0 =A0 =A0 =A0 =A0After translation by natd, packets re-enter the firewa= ll at the rule > =A0 =A0 =A0 =A0 =A0number following the rule number that caused the diver= sion (not the > =A0 =A0 =A0 =A0 =A0next rule if there are several at the same number). > > so in this case only natd should be invoked and the ipfw nat skipped. > > =A0> Also I'm pretty sure you'd need to include '-f /etc/natd.conf' in yo= ur > =A0> natd_flags for your redirect_port config, here's no default configfi= le > =A0> for natd (AFAIK) > > I think that's right - or you can specify -redirect_port in natd_flags. > > =A0> I guess rc.firewall ought to be checking that natd_enable and > =A0> firewall_nat_enable aren't both YES .. > > .. and that becomes irrelevant, though it's still an ambiguous config. I'll look into this more closely on Sunday when I come in to repro the issue. Thanks for the feedback :)! -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Jul 3 11:16:16 2010 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 A6609106564A; Sat, 3 Jul 2010 11:16:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFC88FC0A; Sat, 3 Jul 2010 11:16:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o63BGGN6062772; Sat, 3 Jul 2010 11:16:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o63BGG8p062768; Sat, 3 Jul 2010 11:16:16 GMT (envelope-from linimon) Date: Sat, 3 Jul 2010 11:16:16 GMT Message-Id: <201007031116.o63BGG8p062768@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148322: [ath] Triggering atheros wifi beacon misses in hostap mode under no radio traffic load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 11:16:16 -0000 Old Synopsis: Triggering atheros wifi beacon misses in hostap mode under no radio traffic load New Synopsis: [ath] Triggering atheros wifi beacon misses in hostap mode under no radio traffic load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jul 3 11:16:04 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148322