From jonathan at kc8onw.net Thu May 1 02:26:31 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Thu May 1 02:26:35 2008 Subject: em1: Unable to allocate bus resource: memory Message-ID: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> (Please CC as I'm not subscribed to net@) I bought a new PCIe NIC a few months ago and was working with Jack Vogel on getting it to work but he was busy, then I got busy and things stalled. Does anyone else have any idea what might be wrong here? The card is recognized but the em driver fails to initialize it for some reason. I'm running 7-STABLE and the standard information is below. uname -a (system csuped within a couple hours of build time): FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30 14:20:32 ADT 2008 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE i386 dmesg lines for em1 (full dmesg available if needed): em1: port 0xdc00-0xdc1f mem 0xfe8e0000-0xfe8fffff,0xfe8c0000-0xfe8dffff irq 16 at device 0.0 on pci3 em1: Unable to allocate bus resource: memory em1: Allocation of PCI resources failed pciconf -lv for em 1: em1@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' class = network subclass = ethernet Thank you, Jonathan From andrew at modulus.org Thu May 1 02:39:25 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 1 02:39:28 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> Message-ID: <48192D55.2080604@modulus.org> > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > on getting it to work but he was busy, then I got busy and things stalled. > Does anyone else have any idea what might be wrong here? The card is > recognized but the em driver fails to initialize it for some reason. I'm > running 7-STABLE and the standard information is below. I experience the same problem with an Intel PCIe gigabit NIC. I don't know of any workaround, my cards are sitting on the shelf until someone works it out... - Andrew From brde at optusnet.com.au Thu May 1 03:22:57 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Thu May 1 03:23:02 2008 Subject: misc/123066: kernel trap with ipsec In-Reply-To: <200804250550.m3P5o4f1010354@freefall.freebsd.org> References: <200804250550.m3P5o4f1010354@freefall.freebsd.org> Message-ID: <20080501130050.A93454@delplex.bde.org> On Fri, 25 Apr 2008, Kris Kennaway wrote: > Unfortunately we need the rest of the stack. Can you either try to > reproduce with DDB in the kernel and obtain a stack trace from there, > or if this is not possible then try recompiling the kernel with -O > instead of -O2 which tends to produce better stack traces. I wonder why there haven't been more reports of gcc-4.2 -O[2] breaking things (I probably read the wrong lists). -O2 almost completely breaks kernel profiling and debugging using ddb, mainly by inlining functions that are only used once. Even -O is documented as enabling -funit-at-a-time, which is documented as enabling -finline-functions-called-once. -funit-at-a-time gives the possibility of inlining functions that are instantiated before they are used, and then -finline-functions-called-once tends to inline them. However, this doesn't seem to happen very often with only -O. Maybe -O only inlines small functions, but -O2 inlines all functions that are only called once. Losing the symbols and frames for large inlined functions is especially annoying. I started using -O2 for kernels about a year ago because although it it has little effect (usually negative) in normal use, it gave an optimization of a whole 1 to 5% in network microbenchmarks that I was working on. Bruce From jfvogel at gmail.com Thu May 1 04:16:23 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 04:16:25 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <48192D55.2080604@modulus.org> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> Message-ID: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> On Wed, Apr 30, 2008 at 7:39 PM, Andrew Snow wrote: > > > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > > on getting it to work but he was busy, then I got busy and things > stalled. > > Does anyone else have any idea what might be wrong here? The card is > > recognized but the em driver fails to initialize it for some reason. I'm > > running 7-STABLE and the standard information is below. > > > I experience the same problem with an Intel PCIe gigabit NIC. I don't know > of any workaround, my cards are sitting on the shelf until someone works it > out... > You won't know if its still a problem if you don't take them off the shelf and try it :) I can't fix problems that I cannot reproduce... well, unless I get REAL lucky and fix something along the way, but that means that if you don't help me it likely won't get fixed :) Sometimes its frustrating, you can try hard... I can try hard, and we still can't solve something, but its the only way to proceed. I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful to me, and to everyone, if as many get out and test that driver as possible. Cheers, Jack From jfvogel at gmail.com Thu May 1 04:30:33 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 04:30:36 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> Message-ID: <2a41acea0804302104u5479be90t6089d42049df3c4c@mail.gmail.com> Try the driver in HEAD, it might even just build and work on 7, if not let me know. Jack On Wed, Apr 30, 2008 at 7:11 PM, wrote: > (Please CC as I'm not subscribed to net@) > > I bought a new PCIe NIC a few months ago and was working with Jack Vogel > on getting it to work but he was busy, then I got busy and things stalled. > Does anyone else have any idea what might be wrong here? The card is > recognized but the em driver fails to initialize it for some reason. I'm > running 7-STABLE and the standard information is below. > > uname -a (system csuped within a couple hours of build time): > FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30 > 14:20:32 ADT 2008 root@storage.kc8onw.net:/usr/obj/usr/src/sys/STORAGE > i386 > > dmesg lines for em1 (full dmesg available if needed): > em1: port > 0xdc00-0xdc1f mem 0xfe8e0000-0xfe8fffff,0xfe8c0000-0xfe8dffff irq 16 at > device 0.0 on pci3 > em1: Unable to allocate bus resource: memory > em1: Allocation of PCI resources failed > > pciconf -lv for em 1: > em1@pci0:3:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' > class = network > subclass = ethernet > > Thank you, > Jonathan > > > > _______________________________________________ > 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 jonathan at kc8onw.net Thu May 1 04:49:27 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Thu May 1 04:49:32 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> Message-ID: <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> On Thu, May 1, 2008 00:09, Jack Vogel wrote: > I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful > to me, and to everyone, if as many get out and test that driver as > possible. Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are there other changes that need to happen as well? Jonathan From jfvogel at gmail.com Thu May 1 04:55:12 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 04:55:15 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> Message-ID: <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> On Wed, Apr 30, 2008 at 9:49 PM, wrote: > On Thu, May 1, 2008 00:09, Jack Vogel wrote: > > I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful > > to me, and to everyone, if as many get out and test that driver as > > possible. > > Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are > there other changes that need to happen as well? > > Jonathan hmmm, I'm not sure, I don't usually do that on a small directory, there are changes to files and Makefile. It depends if you are going to build as a module or static in the kernel? Jack From andrew at modulus.org Thu May 1 05:10:58 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 1 05:11:03 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> Message-ID: <481950DB.80808@modulus.org> Jack Vogel wrote: > You won't know if its still a problem if you don't take them off the > shelf and try it :) Good point. I wasn't trying to point the finger at you, I think you are doing a fantastic job overall :) The card in question is a Pro/1000PT desktop adapter on PCIe 1x bus. I had used some other cards in the meantime and forgot all about my PCIe card. Just got it out to try it again. While it didnt work in 6.2 (all packets would get silently dropped), it now works fine for me in 7.0! Thanks for all your good work. - Andrew From andrew at modulus.org Thu May 1 05:22:18 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 1 05:22:23 2008 Subject: Some odd behaviour of vmstat and vmtotal... In-Reply-To: <20080501045736.GU30325@elvis.mu.org> References: <20080501045736.GU30325@elvis.mu.org> Message-ID: <48195384.5030204@modulus.org> > In deploying 7.0 at work we were finding a persistent problem when > running "vmstat 1" on systems. The problem shows up as a 10ms "pause" > in processing, usually packet stamping and forwarding by a user level > process. Thats interesting. I once did some quick and dirty profiling of vmtotal and found it runs extremely quickly. Are you running on slow machines (embedded perhaps)? Or do you have a situation where you perhaps have alot more VM objects created than normal? I can't think of a good example where this would be the case.. - Andrew From linimon at FreeBSD.org Thu May 1 05:53:10 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 1 05:53:13 2008 Subject: kern/122989: [swi] [panic] 6.3 kernel panic in swi1: net Message-ID: <200805010553.m415r9jM048609@freefall.freebsd.org> Synopsis: [swi] [panic] 6.3 kernel panic in swi1: net Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 1 05:52:44 UTC 2008 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=122989 From jonathan at kc8onw.net Thu May 1 08:17:11 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Thu May 1 08:17:16 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> Message-ID: <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> On Thu, May 1, 2008 00:55, Jack Vogel wrote: > On Wed, Apr 30, 2008 at 9:49 PM, wrote: > >> On Thu, May 1, 2008 00:09, Jack Vogel wrote: >> >>> I am hoping to MFC the em/igb drivers in HEAD soon, it would be >>> helpful to me, and to everyone, if as many get out and test that >>> driver as possible. >> >> Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or >> are there other changes that need to happen as well? >> >> Jonathan >> > > hmmm, I'm not sure, I don't usually do that on a small directory, there > are changes to files and Makefile. It depends if you are going to build as > a module or static in the kernel? I grabbed the dev/em folder for current, commented out the missing file in the makefile and would up with a bunch of errors like ": undefined reference to `e1000_pci_set_mwi'". Not as simple as I hoped :P Any ideas short of migrating the entire system to -head? I'd rather stay on 7 with patches if needed as this system needs to be reliable for extended periods of time. Thanks, Jonathan From kris at FreeBSD.org Thu May 1 08:30:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu May 1 08:30:07 2008 Subject: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Message-ID: <200805010830.m418U4uT092112@freefall.freebsd.org> The following reply was made to PR kern/122875; it has been noted by GNATS. From: Kris Kennaway To: hotlips Internet admin Cc: bug-followup@FreeBSD.org Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) Date: Thu, 01 May 2008 10:22:39 +0200 hotlips Internet admin wrote: > On Mon, 28 Apr 2008, Kris Kennaway wrote: > |hotlips Internet admin wrote: > |> The following reply was made to PR kern/122875; it has been noted by GNATS. > |> > |> From: hotlips Internet admin > |> To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org > |> Cc: bug-followup@FreeBSD.org > |> Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable > |> (works ok in 7.0-release) > |> Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT) > |> > |> On Fri, 18 Apr 2008 FreeBSD-gnats-submit@FreeBSD.org wrote: > |> |Thank you very much for your problem report. > |> |It has the internal identification `kern/122875'. > |> |The individual assigned to look at your > |> |report is: freebsd-bugs. | > |> |You can access the state of your problem report at any time > |> |via this link: > |> | > |> |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 > |> | > |> |>Category: kern > |> |>Responsible: freebsd-bugs > |> |>Synopsis: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works > |> ok in 7.0-release) > |> |>Arrival-Date: Fri Apr 18 02:20:00 UTC 2008 > |> this also happens in FreeBSD 6.3-STABLE > |> I depend heavily on rpc.rstatd as a part of monitoring > |> servers and firewalls etc., so this is a serious issue > |> for me until I can get a fix or work-around > | > |Revert the recent commits by Peter until a fix is applied. > > > I'm not sure if this is something i should do locally, > or whether those commites are being reverted in the > FBSD source tree > > > if it's someting to do locally, I would need to know > what to do in detail ... > > > this also seems related to PR ports/123146 btw ... The easiest thing for you to do will be to revert to an older 6.3-STABLE (or 6.3-RELEASE) until it is resolved in CVS. Kris From suz at freebsd.org Thu May 1 11:20:00 2008 From: suz at freebsd.org (SUZUKI, Shinsuke) Date: Thu May 1 11:20:05 2008 Subject: Pim6sd daemon and global addresses In-Reply-To: References: Message-ID: Hello, On Fri, Apr 25, 2008 at 3:25 PM, Ian Brown wrote: > from man pim6sd: > "pim6sd requires the node running the daemon to have an IPv6 global > address.". > Does that mean that it must have an IPv6 address which > it address has a global type? > Namely, must it be an address which starts with a global prefix, like > 2001::....? Yes. That's because some of a PIM-SM protocol message (PIM-Register/Register-Stop) requires a global unicast address. #In some cases PIM-Register/Register-Stop is not used. As it is #not always so obvious, pim6sd requires a global unicast address. > Second: is there a way to prevent the pim6sd daemon to send the PIM > hello messages, which it does regularly ? Please specify the following command in your pim6sd.conf, where xxx is the interface name you want to disable PIM-SM. phyint xxx disable; Thanks. ---- SUZUKI, Shinsuke From lars at koellers.net Thu May 1 16:20:03 2008 From: lars at koellers.net (=?ISO-8859-15?Q?Lars_K=F6ller?=) Date: Thu May 1 16:20:06 2008 Subject: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) Message-ID: <200805011620.m41GK3b7059770@freefall.freebsd.org> The following reply was made to PR kern/122427; it has been noted by GNATS. From: =?ISO-8859-15?Q?Lars_K=F6ller?= To: bug-followup@FreeBSD.org, root@koellers.net Cc: Subject: Re: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) Date: Thu, 01 May 2008 18:12:27 +0200 Seems to be fixed in 6-STABLE with sys/netinet/in.c version 1.85.2.10 There seems to be other PR's which could be closed now. kern/108197 [panic] [gif] [ip6] if_delmulti reference counting panic kern/116077 [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client kern/120266 [panic] gnugk causes kernel panic when closing UDP sockets kern/120343 [panic] Reproducible Crash - network interface related (kgdb output included) Regards Lars From jfvogel at gmail.com Thu May 1 16:34:59 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 16:35:03 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> Message-ID: <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> On Thu, May 1, 2008 at 1:17 AM, wrote: > > On Thu, May 1, 2008 00:55, Jack Vogel wrote: > > On Wed, Apr 30, 2008 at 9:49 PM, wrote: > > > >> On Thu, May 1, 2008 00:09, Jack Vogel wrote: > >> > >>> I am hoping to MFC the em/igb drivers in HEAD soon, it would be > >>> helpful to me, and to everyone, if as many get out and test that > >>> driver as possible. > >> > >> Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or > >> are there other changes that need to happen as well? > >> > >> Jonathan > >> > > > > hmmm, I'm not sure, I don't usually do that on a small directory, there > > are changes to files and Makefile. It depends if you are going to build as > > a module or static in the kernel? > > I grabbed the dev/em folder for current, commented out the missing file in > the makefile and would up with a bunch of errors like ": undefined > reference to `e1000_pci_set_mwi'". > > Not as simple as I hoped :P Any ideas short of migrating the entire > system to -head? I'd rather stay on 7 with patches if needed as this > system needs to be reliable for extended periods of time. > > Thanks, > Jonathan If you can wait a week I should get to the MFC, if its urgent let me know and we can see, are you sure you got everything, that routine was something that got dropped out of osdep because the shared code no longer uses it. Jack From jfvogel at gmail.com Thu May 1 16:36:06 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 16:36:10 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <481950DB.80808@modulus.org> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <481950DB.80808@modulus.org> Message-ID: <2a41acea0805010936q57470427pa693f1ccfd72488b@mail.gmail.com> On Wed, Apr 30, 2008 at 10:10 PM, Andrew Snow wrote: > Jack Vogel wrote: > > > You won't know if its still a problem if you don't take them off the > > shelf and try it :) > > > > > Good point. I wasn't trying to point the finger at you, I think you are > doing a fantastic job overall :) > > The card in question is a Pro/1000PT desktop adapter on PCIe 1x bus. I had > used some other cards in the meantime and forgot all about my PCIe card. > Just got it out to try it again. > > While it didnt work in 6.2 (all packets would get silently dropped), it now > works fine for me in 7.0! > > > Thanks for all your good work. Awesome, nice to hear that its an improvement, and you're welcome :) Jack From jonathan at kc8onw.net Thu May 1 16:50:19 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Thu May 1 16:50:23 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> Message-ID: <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> On Thu, May 1, 2008 12:34, Jack Vogel wrote: > On Thu, May 1, 2008 at 1:17 AM, wrote: > >> I grabbed the dev/em folder for current, commented out the missing file >> in the makefile and would up with a bunch of errors like ": undefined >> reference to `e1000_pci_set_mwi'". >> >> Not as simple as I hoped :P Any ideas short of migrating the entire >> system to -head? I'd rather stay on 7 with patches if needed as this >> system needs to be reliable for extended periods of time. > > If you can wait a week I should get to the MFC, if its urgent let me know > and we can see, are you sure you got everything, that routine was > something that got dropped out of osdep because the shared code no longer > uses it. It's not urgent. I only grabbed the dev/em directory so something probably changed elsewhere. If you can give me a heads up when the MFC occurs I would appreciate it. If the MFC doesn't get it working would having remote access help at all? Jonathan From jfvogel at gmail.com Thu May 1 16:54:27 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu May 1 16:54:31 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> Message-ID: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> On Thu, May 1, 2008 at 9:50 AM, wrote: > On Thu, May 1, 2008 12:34, Jack Vogel wrote: > > On Thu, May 1, 2008 at 1:17 AM, wrote: > > > > >> I grabbed the dev/em folder for current, commented out the missing file > >> in the makefile and would up with a bunch of errors like ": undefined > >> reference to `e1000_pci_set_mwi'". > >> > >> Not as simple as I hoped :P Any ideas short of migrating the entire > >> system to -head? I'd rather stay on 7 with patches if needed as this > >> system needs to be reliable for extended periods of time. > > > > > If you can wait a week I should get to the MFC, if its urgent let me know > > and we can see, are you sure you got everything, that routine was > > something that got dropped out of osdep because the shared code no longer > > uses it. > > It's not urgent. I only grabbed the dev/em directory so something > probably changed elsewhere. If you can give me a heads up when the MFC > occurs I would appreciate it. If the MFC doesn't get it working would > having remote access help at all? Possibly, depends what I can do, we'll see when that time comes. Jack From stefan.lambrev at moneybookers.com Thu May 1 17:25:49 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu May 1 17:25:51 2008 Subject: TCP options order changed in FreeBSD 7, incompatible with some routers In-Reply-To: References: Message-ID: <4819F901.50202@moneybookers.com> Greetings, I'm little lost in this thread. Is there a solution for the problem and is it part of RELENG_7? If yes can someone tell me which version of which files fix this? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From bzeeb-lists at lists.zabbadoz.net Thu May 1 20:00:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu May 1 20:00:11 2008 Subject: TCP options order changed in FreeBSD 7, incompatible with some routers In-Reply-To: <4819F901.50202@moneybookers.com> References: <4819F901.50202@moneybookers.com> Message-ID: <20080501195433.Y47338@maildrop.int.zabbadoz.net> On Thu, 1 May 2008, Stefan Lambrev wrote: Hi, > I'm little lost in this thread. > Is there a solution for the problem and is it part of RELENG_7? yes, just update to RELENG_7 and you should be fine. > If yes can someone tell me which version of which files fix this? ufff. RELENG_7 as of those version should be fine. 1.141.2.4 sys/netinet/tcp_output.c 1.157.2.3 sys/netinet/tcp_var.h I cannot say if simply picking those two will work as there had been other changes as well. There are plans for fixing 7.0 but not firm date so far. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From davidch at broadcom.com Fri May 2 02:05:01 2008 From: davidch at broadcom.com (David Christensen) Date: Fri May 2 02:05:09 2008 Subject: Not All Symbols Present in a Loadable Kernel Module Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> I'm trying to build the "bce" driver as a kernel module under RELENG_7 but I'm finding that not all of the functions in the driver are exported as symbols. This makes it difficult to "call" a function from ddb because I get the error "Symbol not found". I'm building and loading the driver from /usr/src/sys/modules/bce. What am I doing wrong? How can I get all functions in the driver exported as symbols usable by the debugger? Dave From jhay at meraka.org.za Fri May 2 09:02:04 2008 From: jhay at meraka.org.za (John Hay) Date: Fri May 2 09:02:22 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <4818BC79.40605@elischer.org> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> Message-ID: <20080502090200.GA57055@zibbi.meraka.csir.co.za> > >This confuses me.... > > > >The whole point of a FIB is to decide the *next* hop for a > >given input packet. So questions. > >1) A packet arrives on an interface. If this interface is > > associated with more than one FIB, which FIB does it get > > given to? > > > > which ever one you select, using the policy of your choice. > > that's what policy routing is about. > if you don't WANT policy based routing, dont turn it on. > > > > >2) If that decision is taken by a a packet 'classifier', > > isn't it in effect doing the job of a FIB (deciding the > > next hop, which happens to be a local FIB)? Recall that > > basically a packet passes from a FIB to another FIB until > > it gets to its eventual destination. > > the packet classifier selects a FIB which in turn implements a > particular routing decision tree. > In the degenerate case where a FIB has only one route > then you are correct, but there are technical reasons why this is > superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From vwe at FreeBSD.org Fri May 2 09:47:57 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri May 2 09:47:59 2008 Subject: kern/120725: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow Message-ID: <200805020947.m429luC4054234@freefall.freebsd.org> Synopsis: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Fri May 2 09:47:48 UTC 2008 State-Changed-Why: We're sorry to not see any feedback received for quite some time. If you think this is still an issue which should be worked on, please provide the requested information and we'll be happy to reopen this ticket. Thank you for bringing this problem to attention! http://www.freebsd.org/cgi/query-pr.cgi?pr=120725 From petar at smokva.net Fri May 2 09:49:58 2008 From: petar at smokva.net (Petar Bogdanovic) Date: Fri May 2 09:50:00 2008 Subject: authentication timeouts with ath(4) in hostap mode Message-ID: <20080502093655.GA3535@pintail.smokva.net> Hi, I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and FreeBSD 7: ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux wpa_supplicant drops the connection and has to reassociate. This however does not work immediately; The supplicant fails a few times before reconnecting: <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Associated with 00:0b:0b:06:0d:09 <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] This happens more on the 11a than on the 11g network. When I'm next to the AP, the timeouts are almost gone but they still happen. (My laptop is just one room away from the AP). Here is the athstats-output of ath0 (11a): # ./athstats -i ath0 481546 data frames received 330669 data frames transmit 13395 tx frames with an alternate rate 78558 long on-chip tx retries 1431 tx failed 'cuz too many retries 36M current transmit rate 78 tx management frames 3 tx frames discarded prior to association 45 tx frames with no ack marked 2894 rx failed 'cuz of bad CRC 2 rx failed 'cuz decryption 92711 rx failed 'cuz of PHY err 92708 OFDM timing 3 OFDM restart 318332 beacons transmitted 1111 periodic calibrations 2 rfgain value change 22 rssi of last ack 23 avg recv rssi -96 rx noise floor 2530 switched default/rx antenna Antenna profile: [1] tx 173364 rx 123068 [2] tx 155874 rx 358671 All this is well known to me, since I had NetBSD running on this device for months and it suffered the same problems -- it was even worse, the timeouts occured every few minutes. Back then, it seemed that ath had some interrupt problems: ath0: device timeout as David Young from NetBSD noticed in his mail some time ago: http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html FreeBSD doesn't seem to have this `device timeouts'. I don't see any in /var/log/messages and there are none when I'm connected to the device over a serial port. I'm a bit lost here, but ready to debug if someone knows more. Thanks, Petar From bms at FreeBSD.org Fri May 2 15:44:23 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri May 2 15:44:27 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <20080502090200.GA57055@zibbi.meraka.csir.co.za> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> Message-ID: <481B36D4.3050103@FreeBSD.org> John Hay wrote: > The linux guys seems to have multiple fibs (or whatever they call them) > which they can chain together by giving them different priorities. The > effect seems to be that a packet will be matched through the highest > priority fib to the lowest until a route match is found en then is used. > Will something like that be possible? I came across that kind of use > with the olsr guys. They let olsrd twiddle one of the higher priority > fibs and then put fallback routes in a lower priority fib. That way > olsrd can override a route (even the default route) and when olsrd > exists and deltes all its routes, the original ones are still in the > lower priority fib and will be used. > XORP already does this without relying on any kernel support. Each routing protocol supplies an origin table of its own. The RIB makes the decision on which route to plumb to the kernel based on administrative distance. When xorp_olsr exits, its origin table is removed, and the winning routes are recalculated. You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. From jhay at meraka.org.za Fri May 2 17:43:01 2008 From: jhay at meraka.org.za (John Hay) Date: Fri May 2 17:43:08 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <481B36D4.3050103@FreeBSD.org> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B36D4.3050103@FreeBSD.org> Message-ID: <20080502174258.GA20244@zibbi.meraka.csir.co.za> On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote: > John Hay wrote: > >The linux guys seems to have multiple fibs (or whatever they call them) > >which they can chain together by giving them different priorities. The > >effect seems to be that a packet will be matched through the highest > >priority fib to the lowest until a route match is found en then is used. > >Will something like that be possible? I came across that kind of use > >with the olsr guys. They let olsrd twiddle one of the higher priority > >fibs and then put fallback routes in a lower priority fib. That way > >olsrd can override a route (even the default route) and when olsrd > >exists and deltes all its routes, the original ones are still in the > >lower priority fib and will be used. > > > > XORP already does this without relying on any kernel support. > > Each routing protocol supplies an origin table of its own. The RIB makes > the decision on which route to plumb to the kernel based on > administrative distance. When xorp_olsr exits, its origin table is > removed, and the winning routes are recalculated. > > You don't need to go to the kernel for this sort of thing unless you > specifically need to implement route policy based on which interface(s) > a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. To them it is unneeded complexity that the kernel already takes care of. :-/ In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From julian at elischer.org Fri May 2 18:02:28 2008 From: julian at elischer.org (Julian Elischer) Date: Fri May 2 18:02:33 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <20080502090200.GA57055@zibbi.meraka.csir.co.za> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> Message-ID: <481B5733.7020503@elischer.org> John Hay wrote: >>> This confuses me.... >>> >>> The whole point of a FIB is to decide the *next* hop for a >>> given input packet. So questions. >>> 1) A packet arrives on an interface. If this interface is >>> associated with more than one FIB, which FIB does it get >>> given to? >>> >> which ever one you select, using the policy of your choice. >> >> that's what policy routing is about. >> if you don't WANT policy based routing, dont turn it on. >> >> >> >>> 2) If that decision is taken by a a packet 'classifier', >>> isn't it in effect doing the job of a FIB (deciding the >>> next hop, which happens to be a local FIB)? Recall that >>> basically a packet passes from a FIB to another FIB until >>> it gets to its eventual destination. >> the packet classifier selects a FIB which in turn implements a >> particular routing decision tree. >> In the degenerate case where a FIB has only one route >> then you are correct, but there are technical reasons why this is >> superior to just using a fwd rule in the firewall. > > The linux guys seems to have multiple fibs (or whatever they call them) > which they can chain together by giving them different priorities. The > effect seems to be that a packet will be matched through the highest > priority fib to the lowest until a route match is found en then is used. > Will something like that be possible? I came across that kind of use > with the olsr guys. They let olsrd twiddle one of the higher priority > fibs and then put fallback routes in a lower priority fib. That way > olsrd can override a route (even the default route) and when olsrd > exists and deltes all its routes, the original ones are still in the > lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it. > > John From julian at elischer.org Fri May 2 19:47:28 2008 From: julian at elischer.org (Julian Elischer) Date: Fri May 2 19:47:33 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <481B5733.7020503@elischer.org> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B5733.7020503@elischer.org> Message-ID: <481B6FCE.2080605@elischer.org> Julian Elischer wrote: > John Hay wrote: >>>> This confuses me.... >>>> >>>> The whole point of a FIB is to decide the *next* hop for a >>>> given input packet. So questions. >>>> 1) A packet arrives on an interface. If this interface is >>>> associated with more than one FIB, which FIB does it get >>>> given to? >>>> >>> which ever one you select, using the policy of your choice. >>> >>> that's what policy routing is about. >>> if you don't WANT policy based routing, dont turn it on. >>> >>> >>> >>>> 2) If that decision is taken by a a packet 'classifier', >>>> isn't it in effect doing the job of a FIB (deciding the >>>> next hop, which happens to be a local FIB)? Recall that >>>> basically a packet passes from a FIB to another FIB until >>>> it gets to its eventual destination. >>> the packet classifier selects a FIB which in turn implements a >>> particular routing decision tree. >>> In the degenerate case where a FIB has only one route >>> then you are correct, but there are technical reasons why this is >>> superior to just using a fwd rule in the firewall. >> >> The linux guys seems to have multiple fibs (or whatever they call them) >> which they can chain together by giving them different priorities. The >> effect seems to be that a packet will be matched through the highest >> priority fib to the lowest until a route match is found en then is used. >> Will something like that be possible? I came across that kind of use >> with the olsr guys. They let olsrd twiddle one of the higher priority >> fibs and then put fallback routes in a lower priority fib. That way >> olsrd can override a route (even the default route) and when olsrd >> exists and deltes all its routes, the original ones are still in the >> lower priority fib and will be used. > > no we are going to do the simple thing.. > such enhancements can be done later if there is a call for it. > > We will just have a number of tables that you can associate a packet > with at a number of points in its path. having another table as the > 'default route' for a table (i.e. if you don't find something look in > another table) is something that would be relatively easy to do, but > I have not done it.hav Having been prodded to go look up OLSR i an say that this is exactly the kind of thing that multiple routing tables are useful for. OLSR is an overlay network and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. In this case you would set the overlay interfaces to work with FIB 1 so that packets are transported according to rules defined there and the application packets to the internet would be routed according to FIB 0 which would have entries for the overlay interfaces but not necessarily entries for the actual physical interfaces. (for example) From andre at freebsd.org Fri May 2 19:57:39 2008 From: andre at freebsd.org (Andre Oppermann) Date: Fri May 2 19:57:42 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> Message-ID: <481B7232.60608@freebsd.org> Mark Hills wrote: > On Wed, 23 Apr 2008, Andre Oppermann wrote: > >> http://people.freebsd.org/~andre/tcp_output-error-log.diff >> >> Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 >> and report any output. You likely get some (normal) noise from syncache. >> What we are looking for is reports from tcp_output. > > Hi Andre, I've applied the patch and tested. > > Aside from syncache noise, I get a constant stream of 'error 55' > (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. > > TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > > 192.168.5.40 is the IP address of this host, running the server. > > I tried to correlate the point of the application receiving ETIMEDOUT > with these messages, but that is tricky as it seems to be outputting a > lot of messages, and multiple messages over eachother (see below). > > Because of the mention of no buffer space available, I checked the > values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max > values with no effect. > > When I get time I will modify the kernel to print errors which aren't > ENOBUFS to see if there are any others. But in the meantime, this sounds > like a problem to me. Is that correct? > > Mark > > > :8080; tcp_output: error 55 while sending > TCP: [192.168.5.42]:57384T CtPo: > [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. > 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending > TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error 55 > while sending > TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error 55 > while sending After tracing through the code it seems you are indeed memory limited. Looking back at the netstat -m output: 12550/250/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) This shows that the supply of 4k jumbo clusters is pretty much exhausted. The cache may be allocated to different CPUs and the one making the request at a given point may be depleted and can't get any from the global pool. The big question is why the denied counter doesn't report anything. I've looked at the code paths and don't see any obvious reason why it doesn't get counted. Maybe Robert can give some insight here. Try doubling the amount of 4k page size jumbo mbufs. They are the primary workhorse in the kernel right now: sysctl kern.ipc.nmbjumbop=25600 This should get further. Still more may be necessary depending on workloads. -- Andre From pisymbol at gmail.com Fri May 2 20:15:43 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Fri May 2 20:15:47 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> On Thu, May 1, 2008 at 10:04 PM, David Christensen wrote: > I'm trying to build the "bce" driver as a kernel module under RELENG_7 but I'm > finding that not all of the functions in the driver are exported as symbols. This > makes it difficult to "call" a function from ddb because I get the error "Symbol > not found". I'm building and loading the driver from /usr/src/sys/modules/bce. > What am I doing wrong? How can I get all functions in the driver exported as > symbols usable by the debugger? Are you building a debug kernel or regular kernel? Have you turned on debug symbols? makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols Just a quick thought...I'm assuming these symbols are listed under your final kernel image (nm it etc.). -aps From linimon at FreeBSD.org Fri May 2 20:56:47 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri May 2 20:56:49 2008 Subject: kern/123330: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die Message-ID: <200805022056.m42Kukel010243@freefall.freebsd.org> Old Synopsis: Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die New Synopsis: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 2 20:55:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123330 From bms at FreeBSD.org Fri May 2 23:19:10 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri May 2 23:19:14 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <481B6FCE.2080605@elischer.org> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B5733.7020503@elischer.org> <481B6FCE.2080605@elischer.org> Message-ID: <481BA16B.9000803@FreeBSD.org> Julian Elischer wrote: > > OLSR is an overlay network Nope -- the express intention was that it could be used for basic IP connectivity, for mobile devices. In OLSR, every node is a potential IP forwarder unless it explicitly advertises itself as being unwilling to forward. > and any machine that participated must have a split personality. First > it must be able to think in terms of the basic local network, and it > must be able to think in terms > of the world from the perspective of the overlay. Applying routing policy gets more important at the border. The OLSR implementation in XORP is intended to give people a means of connectivity between MANET and non-MANET routing domains, by redistributing routes into the OLSR cloud. I daresay these capabilities will get more important, and relevant, to the MANET picture as time goes on, but it's best to leave them out of the operational picture for now, in my opinion. cheers BMS From bms at FreeBSD.org Fri May 2 23:26:15 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri May 2 23:26:21 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <20080502174258.GA20244@zibbi.meraka.csir.co.za> References: <20080430172705.2E3275AD6@mail.bitblocks.com> <4818BC79.40605@elischer.org> <20080502090200.GA57055@zibbi.meraka.csir.co.za> <481B36D4.3050103@FreeBSD.org> <20080502174258.GA20244@zibbi.meraka.csir.co.za> Message-ID: <481BA315.3000309@FreeBSD.org> John Hay wrote: >> You don't need to go to the kernel for this sort of thing unless you >> specifically need to implement route policy based on which interface(s) >> a packet came in on. >> > > Yes I know that. But in the world of adhoc wireless mesh networking > there are very few non-linux people, so they basically call the shots > and use the linux kernel features to the full. Not true. There's an awful lot going on behind closed doors in the MANET world, and from the sounds of the emanations, they might not be using Linux at all. > In a sense I can > understand them because their stuff also run on the small embedded > stuff like the linksys wireless boxes and it needs to scale. The > biggest adhoc olsr network is probably the Freifunk one that have > more than 600 wireless nodes, mostly consisting of linksys boxes. > The complexity of any system like that is still there, regardless of whether or not people choose to make it harder to debug code by prematurely pushing it into the kernel. > On some boxes that are also connected to different kinds of networks, > they run a different routing daemon into another fib and by setting > the priorities on the fibs, they can decide which daemon's routes > have the highest priority. And both routing daemons are happy because > the other is not stomping on its feet. > Yes, but this is largely to do with the fact that the Linux netlink socket allows daemons to coexist due to its use of a tag-length-value which captures that information, a different kettle of fish. The feature you describe is totally possible without adding complexity to Julian's current effort. cheers BMS From davidch at broadcom.com Sat May 3 00:07:00 2008 From: davidch at broadcom.com (David Christensen) Date: Sat May 3 00:07:03 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> > > I'm trying to build the "bce" driver as a kernel module under > RELENG_7 but I'm > > finding that not all of the functions in the driver are exported as > symbols. This > > makes it difficult to "call" a function from ddb because I get the > error "Symbol > > not found". I'm building and loading the driver from > /usr/src/sys/modules/bce. > > What am I doing wrong? How can I get all functions in the driver > exported as > > symbols usable by the debugger? > > Are you building a debug kernel or regular kernel? Have you turned on > debug symbols? > > makeoptions DEBUG=-g # Build kernel with gdb(1) > debug symbols > > Just a quick thought...I'm assuming these symbols are listed under > your final kernel image (nm it etc.). Yes, I'm building a debug kernel. I have the line listed above as well as the following: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Dave From sam at freebsd.org Sat May 3 00:25:11 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat May 3 00:25:15 2008 Subject: authentication timeouts with ath(4) in hostap mode In-Reply-To: <20080502093655.GA3535@pintail.smokva.net> References: <20080502093655.GA3535@pintail.smokva.net> Message-ID: <481BB0E5.8000803@freebsd.org> Petar Bogdanovic wrote: > Hi, > > I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and > FreeBSD 7: > > ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan > ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan > > > When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux > wpa_supplicant drops the connection and has to reassociate. This however > does not work immediately; The supplicant fails a few times before > reconnecting: > > <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] > <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Authentication with 00:0b:0b:06:0d:09 timed out. > <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) > <2>Associated with 00:0b:0b:06:0d:09 > <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] > <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] > > > This happens more on the 11a than on the 11g network. When I'm next to > the AP, the timeouts are almost gone but they still happen. (My laptop > is just one room away from the AP). Here is the athstats-output of ath0 > (11a): > > # ./athstats -i ath0 > 481546 data frames received > 330669 data frames transmit > 13395 tx frames with an alternate rate > 78558 long on-chip tx retries > 1431 tx failed 'cuz too many retries > 36M current transmit rate > 78 tx management frames > 3 tx frames discarded prior to association > 45 tx frames with no ack marked > 2894 rx failed 'cuz of bad CRC > 2 rx failed 'cuz decryption > 92711 rx failed 'cuz of PHY err > 92708 OFDM timing > 3 OFDM restart > 318332 beacons transmitted > 1111 periodic calibrations > 2 rfgain value change > 22 rssi of last ack > 23 avg recv rssi > -96 rx noise floor > 2530 switched default/rx antenna > Antenna profile: > [1] tx 173364 rx 123068 > [2] tx 155874 rx 358671 So the obvious question is whether your system config has enough isolation of the radios for them not to impact each other? I have no experience with Alix boards but it's not uncommon for there to be power and signal issues when operating multiple radios in an enclosure (and yes, even with the radios on different bands). You don't indicate what you've done to diagnose this problem. Have you verified the packets are present in the air? Have you traced packets and/or phy errors around the time of the problem? Does turning off one radio give you stable operation? Have you tried different channels? Have you tried different boards? > > > All this is well known to me, since I had NetBSD running on this device > for months and it suffered the same problems -- it was even worse, the > timeouts occured every few minutes. Back then, it seemed that ath had > some interrupt problems: > > ath0: device timeout > > as David Young from NetBSD noticed in his mail some time ago: > > http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html > > > FreeBSD doesn't seem to have this `device timeouts'. I don't see any in > /var/log/messages and there are none when I'm connected to the device > over a serial port. > > I'm a bit lost here, but ready to debug if someone knows more. netbsd's code base is many _years_ out of date wrt freebsd; comparing operation of the two systems is unlikely to be useful. Sam From paul.haddad at gmail.com Sat May 3 04:24:31 2008 From: paul.haddad at gmail.com (Paul Haddad) Date: Sat May 3 04:24:35 2008 Subject: Network Instability when upgrading to 4GB of RAM In-Reply-To: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> Message-ID: <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> All, As a follow up to myself I installed an Intel PCIe NIC and disabled the on board RTL based one and all my problems went away. Been running with 4GB installed for a couple days now with absolutely no network issues. So seems like there's some problem with RTL NICs and >= 4GB of RAM. -- Paul Haddad (paul.haddad@gmail.com paul@pth.com) From jfvogel at gmail.com Sat May 3 07:14:33 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 07:14:36 2008 Subject: MFC of em/igb drivers Message-ID: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! Jack From eugen at kuzbass.ru Sat May 3 08:33:36 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat May 3 08:33:39 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <20080503083332.GB2866@svzserv.kemerovo.su> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. [skip] > As ever, issues and bugs should be sent to me. Cheers everyone! It seems the MFC to RELENG_7 has broken build of static kernels having device em but not having device igb: linking kernel.debug e1000_api.o(.text+0xcc6): In function `e1000_setup_init_funcs': /usr/local/obj/src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Eugene Grosbein From edwin at mavetju.org Sat May 3 10:17:22 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Sat May 3 10:17:26 2008 Subject: IPPROTO_DIVERT and PF_INET6 Message-ID: <20080503100043.GA68835@k7.mavetju> Greetings, Before somebody shoots me down on it: I know that ipfw_divert() is not suitable for IPv6 packets. So, to the point. This code: struct sockaddr_in6 addr6; struct in6_addr ip6_any = IN6ADDR_ANY_INIT; sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); if (sin == -1) errx(1, "Unable to create sin socket."); if (sin > fdmax) fdmax = sin; addr6.sin6_family = AF_INET6; addr6.sin6_addr = ip6_any; addr6.sin6_port = htons(8669); if (bind(sin, (struct sockaddr *) &addr6, sizeof(addr6)) == -1) errx(1, "Unable to bind incoming divert socket: %s", strerror(errno)); compiles and run fine, but it gives me this in the lsof output: nat6to4d 67887 root 3u IPv6 0xc8b05000 0t0 HOPOPTS *:* HOPOPTS is "0" according to /etc/protocols. Making everything IPv4, it gives this: nat6to4d 67899 root 3u IPv4 0xc865421c 0t0 DIVERT *:8669 which is what I expected. So why doesn't this get displayed for the IPv6 sockets? Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From kostikbel at gmail.com Sat May 3 12:05:50 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat May 3 12:05:54 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > MSIX, there will be more server type enhancements in that driver as I get the > time. > > The em driver now will be client oriented, the latest hardware support however > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. > > As ever, issues and bugs should be sent to me. Cheers everyone! Besides the broken tinderbox, you did not connected the igb module to the module build. Is this intentional ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080503/2850b0c4/attachment.pgp From edwin at mavetju.org Sat May 3 13:52:54 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Sat May 3 13:52:59 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <20080503100043.GA68835@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> Message-ID: <20080503135252.GB3159@k7.mavetju> On Sat, May 03, 2008 at 08:00:43PM +1000, Edwin Groothuis wrote: > Before somebody shoots me down on it: I know that ipfw_divert() is > not suitable for IPv6 packets. Please note that the above statement is only partly true now: on my laptop ipfw_divert() can handle IPv6 forwards, but the problem described with opening prevents me from doing anything useful with it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From pisymbol at gmail.com Sat May 3 14:50:32 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Sat May 3 14:50:34 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> On Fri, May 2, 2008 at 8:06 PM, David Christensen wrote: > > > I'm trying to build the "bce" driver as a kernel module under > > RELENG_7 but I'm > > > finding that not all of the functions in the driver are exported as > > symbols. This > > > makes it difficult to "call" a function from ddb because I get the > > error "Symbol > > > not found". I'm building and loading the driver from > > /usr/src/sys/modules/bce. > > > What am I doing wrong? How can I get all functions in the driver > > exported as > > > symbols usable by the debugger? > > > > Are you building a debug kernel or regular kernel? Have you turned on > > debug symbols? > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) > > debug symbols > > > > Just a quick thought...I'm assuming these symbols are listed under > > your final kernel image (nm it etc.). > > Yes, I'm building a debug kernel. I have the line listed above as well > as the following: > > options KDB > options DDB > options GDB > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN Dave: What symbols can you not access exactly and how are you installing/setting up debugging? I just built a RELENG_7 with DDB and I'm able to access bce symbols without a problem. I can examine them and call them. I'm not using options GDB however, only KDB/DDB. I would: - Make sure you have the right if_bce.ko/if_bce.ko.symbols files generated/installed which contains the debug sections of your ko (from the objcopy calls during the build - the binary is stripped with a section pointer to the if_bce.ko.symbols file for debugging information I believe) - If you are using GDB, make sure its pointed to the right source base so it can retrieve symbol information correctly - If you are using GDB, stub it out and just use DDB to verify that your build is sane (it works for me!) - If all else fails, you can always build bce statically (just to move forward etc.) -aps From petar at smokva.net Sat May 3 15:00:14 2008 From: petar at smokva.net (Petar Bogdanovic) Date: Sat May 3 15:00:18 2008 Subject: authentication timeouts with ath(4) in hostap mode In-Reply-To: <481BB0E5.8000803@freebsd.org> References: <20080502093655.GA3535@pintail.smokva.net> <481BB0E5.8000803@freebsd.org> Message-ID: <20080503145906.GA3417@pintail.smokva.net> On Fri, May 02, 2008 at 05:25:09PM -0700, Sam Leffler wrote: > Petar Bogdanovic wrote: >> Hi, >> >> I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and >> FreeBSD 7: >> >> ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan >> ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan >> >> >> When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux >> wpa_supplicant drops the connection and has to reassociate. This however >> does not work immediately; The supplicant fails a few times before >> reconnecting: >> >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Associated with 00:0b:0b:06:0d:09 >> <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> >> >> This happens more on the 11a than on the 11g network. When I'm next to >> the AP, the timeouts are almost gone but they still happen. (My laptop >> is just one room away from the AP). Here is the athstats-output of ath0 >> (11a): >> >> # ./athstats -i ath0 >> 481546 data frames received >> 330669 data frames transmit >> 13395 tx frames with an alternate rate >> 78558 long on-chip tx retries >> 1431 tx failed 'cuz too many retries >> 36M current transmit rate >> 78 tx management frames >> 3 tx frames discarded prior to association >> 45 tx frames with no ack marked >> 2894 rx failed 'cuz of bad CRC >> 2 rx failed 'cuz decryption >> 92711 rx failed 'cuz of PHY err >> 92708 OFDM timing >> 3 OFDM restart >> 318332 beacons transmitted >> 1111 periodic calibrations >> 2 rfgain value change >> 22 rssi of last ack >> 23 avg recv rssi >> -96 rx noise floor >> 2530 switched default/rx antenna >> Antenna profile: >> [1] tx 173364 rx 123068 >> [2] tx 155874 rx 358671 > > So the obvious question is whether your system config has enough isolation > of the radios for them not to impact each other? Do you mean the isolation between the four (2x11a/2x11g) pigtail cables inside the box? Well, when I take a look at the product sheet: http://pcengines.ch/pigsma.htm it looks that the cables aren't shielded at all. Is this question based on the high PHY error rate? This value is steadily growing on both interfaces -- here are the stats of ath1 (11g): # ./athstats -i ath1 938627 data frames received 1727374 data frames transmit 7883 tx frames with an alternate rate 93209 long on-chip tx retries 2871 tx failed 'cuz too many retries 11M current transmit rate 7127 tx management frames 3 tx frames discarded prior to association 1998 tx frames with no ack marked 1718962 tx frames with short preamble 4363254 rx failed 'cuz of bad CRC 5115659 rx failed 'cuz of PHY err 23579 OFDM timing 5092074 CCK timing 6 CCK restart 713605 beacons transmitted 2460 periodic calibrations 2 rfgain value change 18 rssi of last ack 21 avg recv rssi -96 rx noise floor 102 cabq frames transmitted 26685 switched default/rx antenna Antenna profile: [1] tx 1416324 rx 1017871 [2] tx 308291 rx 2758 I assume this one is related to the high AP-density -- there are about 13-15 11g networks available in our living room. Yesterday I tried the same tests with a freesbie client (FreeBSD 6.2) and a Windows client. The link of the former was totally stable. No disconnects on 11a and transfer rates around 2.7MB/s. 11g was stable and fast (3.3MB/s) too but the ALIX board suddenly rebooted. (this seems to be an other issue) The Windows client was stable and fast (3MB/s) on 11a but slow and lossy due disconnects on 11g. After all I also booted an old Debian based live-cd with an old kernel, old madwifi drivers and wpa_supplicant 4.9. It started to disconnect again (both modes). > Does turning off one radio give you stable operation? I just did a `ifconfig ath1 txpower 0' but no luck. Is there a ifconfig way to completely turn off the radio or do I have to unplug ath1 to be sure? > Have you verified the packets are present in the air? Have you traced > packets and/or phy errors around the time of the problem? How do I do that? > Have you tried different channels? Yes. On 11a it makes no difference (I tried 36 and 64). On 11g I get the best result on channel 11. This makes sense, since a lot of the other networks operate on channel 1 or 6. > you tried different boards? Unfortunately, I only have one ALIX board. But maybe I'll try a generic PC just for the sake of certainty. Sorry for the lack of information in my first mail and thanks for your answer, Petar From bzeeb-lists at lists.zabbadoz.net Sat May 3 15:45:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat May 3 15:45:11 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <4816D1D2.7010603@elischer.org> References: <4816D1D2.7010603@elischer.org> Message-ID: <20080503154219.C47338@maildrop.int.zabbadoz.net> On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, > a kernel needs to be created with the option ROUTETABLES=N > > e.g. > +options ROUTETABLES=2 # max 16. 1 is back > compatible. > > leaving this out will result in just a single routing table as per normal. > > the max is 16 but I have an artificial (even lower) at 8 but that may > be gone by the time people try it :-) After reading through this thread and not looking at the patch again for the moment, where does this limit come from? Do you think this could be extended to more in the future? -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From jfvogel at gmail.com Sat May 3 16:39:57 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 16:40:02 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> Message-ID: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > messages. > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > > MSIX, there will be more server type enhancements in that driver as I get the > > time. > > > > The em driver now will be client oriented, the latest hardware support however > > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > > that actually also has MSIX. This first released support for it will > > use 3 interrupt > > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > > vectors, so I am planning to add support for another RX and TX queue as my > > schedule allows. > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > > provides init and an ioctl interface to use that facility, I hope we > > see software > > support follow on soon. This is an early announcement, I am not sure on > > exact dates for availability but they should be soon. > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Besides the broken tinderbox, you did not connected the igb module to > the module build. Is this intentional ? > No, not intentional, both issues are now fixed, sorry, was tired yesterday afternoon :) Jack From scottl at samsco.org Sat May 3 17:40:06 2008 From: scottl at samsco.org (Scott Long) Date: Sat May 3 17:40:12 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> Message-ID: <481C9FB1.4060407@samsco.org> Jack Vogel wrote: > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: >> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: >> >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >> > messages. >> > >> > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> > MSIX, there will be more server type enhancements in that driver as I get the >> > time. >> > >> > The em driver now will be client oriented, the latest hardware support however >> > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> > that actually also has MSIX. This first released support for it will >> > use 3 interrupt >> > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> > vectors, so I am planning to add support for another RX and TX queue as my >> > schedule allows. >> > >> > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> > provides init and an ioctl interface to use that facility, I hope we >> > see software >> > support follow on soon. This is an early announcement, I am not sure on >> > exact dates for availability but they should be soon. >> > >> > As ever, issues and bugs should be sent to me. Cheers everyone! >> >> Besides the broken tinderbox, you did not connected the igb module to >> the module build. Is this intentional ? >> > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > afternoon :) > Is it still true that support for the 575 moved from em to igb? If so, please put an entry in src/UPDATING about it and ask the re/docs team to make sure it's documented in the next release notes. Scott From tim at gebbettco.com Sat May 3 17:43:49 2008 From: tim at gebbettco.com (Tim Gebbett) Date: Sat May 3 17:43:54 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <481B7232.60608@freebsd.org> References: <20080420025010.GJ73016@server.vk2pj.dyndns.org> <480BBD7E.8010700@freebsd.org> <480C9AC6.8090802@freebsd.org> <480E7901.5000804@freebsd.org> <481B7232.60608@freebsd.org> Message-ID: <481CA0C4.2040001@gebbettco.com> Hi Andre, Just to introduce myself, I am now helping Mark Hills with testing. Thank you for your suggestion, here are the results from a similar system (RELENG-7) with increasing kern.ipc.nmbjumbop to 25600. at 1600 streams using approx 340mbit, netstat -m was reporting 12550/250/12800/12800 4k (page size) jumbo clusters in use After the read() returns ETIMEDOUT, 3857/10551/14408/25600 4k (page size) jumbo clusters in use sysctl kern.ipc.nmbjumbop=25600 > 51200 After the read() returns ETIMEDOUT, 200/25400/25600/51200 4k (page size) jumbo clusters in use (current/cache/total/max) netstat -m: 4140/26205/30345 mbufs in use (current/cache/total) 256/3482/3738/25600 mbuf clusters in use (current/cache/total/max) 256/3328 mbuf+clusters out of packet secondary zone in use (current/cache) 3882/21718/25600/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 17075K/100387K/117462K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Do you think we need to reel out further sysctls and should I apply the patch to see if tcp_output: error 55 is still occuring ? Thanks again, Tim Andre Oppermann wrote: > Mark Hills wrote: >> On Wed, 23 Apr 2008, Andre Oppermann wrote: >> >>> http://people.freebsd.org/~andre/tcp_output-error-log.diff >>> >>> Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 >>> and report any output. You likely get some (normal) noise from >>> syncache. >>> What we are looking for is reports from tcp_output. >> >> Hi Andre, I've applied the patch and tested. >> >> Aside from syncache noise, I get a constant stream of 'error 55' >> (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. >> >> TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> >> 192.168.5.40 is the IP address of this host, running the server. >> >> I tried to correlate the point of the application receiving ETIMEDOUT >> with these messages, but that is tricky as it seems to be outputting >> a lot of messages, and multiple messages over eachother (see below). >> >> Because of the mention of no buffer space available, I checked the >> values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max >> values with no effect. >> >> When I get time I will modify the kernel to print errors which aren't >> ENOBUFS to see if there are any others. But in the meantime, this >> sounds like a problem to me. Is that correct? >> >> Mark >> >> >> :8080; tcp_output: error 55 while sending >> TCP: [192.168.5.42]:57384T CtPo: >> [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. >> 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending >> TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending >> TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error >> 55 while sending > > After tracing through the code it seems you are indeed memory limited. > Looking back at the netstat -m output: > > 12550/250/12800/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > This shows that the supply of 4k jumbo clusters is pretty much exhausted. > The cache may be allocated to different CPUs and the one making the > request > at a given point may be depleted and can't get any from the global pool. > The big question is why the denied counter doesn't report anything. I've > looked at the code paths and don't see any obvious reason why it doesn't > get counted. Maybe Robert can give some insight here. > > Try doubling the amount of 4k page size jumbo mbufs. They are the > primary > workhorse in the kernel right now: > > sysctl kern.ipc.nmbjumbop=25600 > > This should get further. Still more may be necessary depending on > workloads. > From jfvogel at gmail.com Sat May 3 20:39:32 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 20:39:38 2008 Subject: MFC of em/igb drivers In-Reply-To: <481C9FB1.4060407@samsco.org> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> <481C9FB1.4060407@samsco.org> Message-ID: <2a41acea0805031339n3ff84f37i3aa815168d14dd94@mail.gmail.com> On Sat, May 3, 2008 at 10:24 AM, Scott Long wrote: > > Jack Vogel wrote: > > > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov > wrote: > > > > > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > > > > > > > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > > > > > > > messages. > > > > > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue > support and > > > > MSIX, there will be more server type enhancements in that driver as I > get the > > > > time. > > > > > > > > The em driver now will be client oriented, the latest hardware > support however > > > > is for 82574, Hartwell, which is a really nice low cost PCIE > dual-port adapter, > > > > that actually also has MSIX. This first released support for it will > > > > use 3 interrupt > > > > vectors, one for TX, one for RX, and Link. The hardware actually > supports 5 > > > > vectors, so I am planning to add support for another RX and TX queue > as my > > > > schedule allows. > > > > > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, > the driver > > > > provides init and an ioctl interface to use that facility, I hope we > > > > see software > > > > support follow on soon. This is an early announcement, I am not sure > on > > > > exact dates for availability but they should be soon. > > > > > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > > > > > Besides the broken tinderbox, you did not connected the igb module to > > > the module build. Is this intentional ? > > > > > > > > > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > > afternoon :) > > > > > > Is it still true that support for the 575 moved from em to igb? If so, > please put an entry in src/UPDATING about it and ask the re/docs team to > make sure it's documented in the next release notes. > > Scott > Ahhh yes, I forgot about that, will do Scott. Jack From oleksandr at samoylyk.sumy.ua Sat May 3 22:42:11 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 3 22:42:15 2008 Subject: Troubles with em on FreeBSD 7 Message-ID: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From pisymbol at gmail.com Sat May 3 22:51:18 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Sat May 3 22:51:22 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> Message-ID: <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> Oleksandr: Are you using DEVICE_POLLING by chance? If so, have you tried turning it off (ifconfig use -polling etc.)? Just curious. -aps On Sat, May 3, 2008 at 6:16 PM, Oleksandr Samoylyk wrote: > Hi! > > I'm running a SMP FreeBSD box with mpd5 on it. > > # uname -a > FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 > 12:40:02 EEST 2008 > xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 > > # mpd5 -v > Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > > Somehow em0 begins to eat all CPU time of one core. > > # top -S > last pid: 55827; load averages: 3.76, 3.42, 3.08 > up 0+03:27:38 16:24:20 > 104 processes: 11 running, 81 sleeping, 12 waiting > CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle > Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 > 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 > 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 > 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 > 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 > 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 > 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 > 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 > 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net > 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq > > Everything is OK with outbound interface - em1. > > Current bandwidth - ~ 80 Mbit/s > > There are a lot of input errors on em0 (but no on em1): > > # netstat -w 1 -I em0 > input (em0) output > packets errs bytes packets errs bytes colls > 8012 923 2838565 12504 0 7943345 0 > 7934 874 2469244 12555 0 7728764 0 > 7931 976 2712035 12482 0 8006760 0 > 8015 813 2694716 10669 0 7796656 0 > 7975 733 2475193 12306 0 8032129 0 > 7871 825 2548198 12269 0 7789452 0 > 8072 961 2647014 11924 0 7260788 0 > 7909 983 2576145 10552 0 7479881 0 > ^C > > And systat -v looks strange with no interrupts on em0: > > 2 users Load 1.34 1.61 1.62 May 3 14:04 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 68152 9452 231584 11936 7786368 count > All 108516 10676 4486380 15448 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total > 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 > ozfod ata0 irq14 > 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 > | | | | | | | | | | | daefr 2001 cpu0: time > =========+> 5699 prcfr 2 em0 irq256 > 55 dtbuf 12110 totfr 6695 em1 irq257 > Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time > Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time > 12005 12004 100 304 frevn pdpgs 2001 cpu2: time > 13 intrn 2001 cpu4: time > Disks ad4 232692 wire 2001 cpu5: time > KB/t 0.00 60640 act 2001 cpu7: time > tps 0 28784 inact 2001 cpu6: time > MB/s 0.00 336 cache > %busy 0 7786032 free > 219632 buf > > Latency grows up to 400 ms: > # ping 10.0.0.1 > PING 10.0.0.1 (10.0.0.1): 56 data bytes > 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms > 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms > 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms > 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms > 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms > ^C > --- 10.0.0.1 ping statistics --- > 6 packets transmitted, 5 packets received, 16.7% packet loss > round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms > > # top -S > last pid: 55827; load averages: 3.76, 3.42, 3.08 > up 0+03:27:38 16:24:20 > 104 processes: 11 running, 81 sleeping, 12 waiting > CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle > Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 > 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 > 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 > 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 > 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 > 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 > 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 > 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 > 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net > 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq > > # sysctl dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 > subdevice=0x0000 class=0x020000 > dev.em.0.%parent: pci6 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: -1 > > I've tried both: > options SCHED_ULE > options SCHED_4BSD > > I've added just the following lines in my kernel config: > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options NETGRAPH > options NETGRAPH_PPP > options NETGRAPH_PPTPGRE > > > My sysctls: > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > net.inet.ip.redirect=0 > net.inet.ip.random_id=1 > net.inet.ip.ttl=255 > net.inet.ip.intr_queue_maxlen=4096 > > kern.maxfiles=131072 > kern.maxfilesperproc=32768 > kern.maxprocperuid=32768 > > kern.ipc.somaxconn=65535 > kern.ipc.maxsockets=32768 > kern.ipc.maxsockbuf=16777216 > > net.inet.tcp.rfc1323=1 > net.inet.tcp.recvspace=65536 > net.inet.tcp.sendspace=32768 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcp.sendbuf_inc=8192 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=16384 > net.inet.tcp.maxtcptw=40960 > net.inet.tcp.msl=2500 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.nolocaltimewait=1 > > net.inet.udp.checksum=0 > net.inet.udp.recvspace=65535 > net.inet.udp.maxdgram=57344 > > net.inet.icmp.icmplim=30 > > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 > > net.isr.direct=1 > > kern.timecounter.hardware=TSC > > dev.em.0.rx_processing_limit=-1 > > If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a > core, but without errors: > # netstat -w 1 -I em0 > input (em0) output > packets errs bytes packets errs bytes colls > 6953 0 2860537 8703 0 4882814 0 > 6785 0 2587635 7683 0 4443958 0 > 7006 0 2576630 8718 0 4924591 0 > 6887 0 2652461 8272 0 4548049 0 > 6854 0 2610157 8689 0 5152459 0 > 6889 0 2586067 8265 0 5010795 0 > 6878 0 2586746 8255 0 4734959 0 > ^C > > Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. > > Please, help to solve the problem. Thanks! > > -- > Oleksandr Samoylyk > OVS-RIPE > _______________________________________________ > 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 oleksandr at samoylyk.sumy.ua Sat May 3 23:33:44 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 3 23:33:59 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> Message-ID: <481CF009.4050606@samoylyk.sumy.ua> Alexander Sack wrote: > Oleksandr: > > Are you using DEVICE_POLLING by chance? If so, have you tried turning > it off (ifconfig use -polling etc.)? Just curious. > Surely, no :) # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b I'm just trying the same configuration on i386. > > On Sat, May 3, 2008 at 6:16 PM, Oleksandr Samoylyk > wrote: >> Hi! >> >> I'm running a SMP FreeBSD box with mpd5 on it. >> >> # uname -a >> FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 >> 12:40:02 EEST 2008 >> xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 >> >> # mpd5 -v >> Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) >> >> Somehow em0 begins to eat all CPU time of one core. >> >> # top -S >> last pid: 55827; load averages: 3.76, 3.42, 3.08 >> up 0+03:27:38 16:24:20 >> 104 processes: 11 running, 81 sleeping, 12 waiting >> CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle >> Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq >> 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 >> 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 >> 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 >> 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 >> 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 >> 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 >> 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 >> 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 >> 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net >> 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq >> >> Everything is OK with outbound interface - em1. >> >> Current bandwidth - ~ 80 Mbit/s >> >> There are a lot of input errors on em0 (but no on em1): >> >> # netstat -w 1 -I em0 >> input (em0) output >> packets errs bytes packets errs bytes colls >> 8012 923 2838565 12504 0 7943345 0 >> 7934 874 2469244 12555 0 7728764 0 >> 7931 976 2712035 12482 0 8006760 0 >> 8015 813 2694716 10669 0 7796656 0 >> 7975 733 2475193 12306 0 8032129 0 >> 7871 825 2548198 12269 0 7789452 0 >> 8072 961 2647014 11924 0 7260788 0 >> 7909 983 2576145 10552 0 7479881 0 >> ^C >> >> And systat -v looks strange with no interrupts on em0: >> >> 2 users Load 1.34 1.61 1.62 May 3 14:04 >> >> Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER >> Tot Share Tot Share Free in out in out >> Act 68152 9452 231584 11936 7786368 count >> All 108516 10676 4486380 15448 pages >> Proc: Interrupts >> r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total >> 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 >> ozfod ata0 irq14 >> 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 >> | | | | | | | | | | | daefr 2001 cpu0: time >> =========+> 5699 prcfr 2 em0 irq256 >> 55 dtbuf 12110 totfr 6695 em1 irq257 >> Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time >> Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time >> 12005 12004 100 304 frevn pdpgs 2001 cpu2: time >> 13 intrn 2001 cpu4: time >> Disks ad4 232692 wire 2001 cpu5: time >> KB/t 0.00 60640 act 2001 cpu7: time >> tps 0 28784 inact 2001 cpu6: time >> MB/s 0.00 336 cache >> %busy 0 7786032 free >> 219632 buf >> >> Latency grows up to 400 ms: >> # ping 10.0.0.1 >> PING 10.0.0.1 (10.0.0.1): 56 data bytes >> 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms >> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms >> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms >> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms >> 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms >> ^C >> --- 10.0.0.1 ping statistics --- >> 6 packets transmitted, 5 packets received, 16.7% packet loss >> round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms >> >> # top -S >> last pid: 55827; load averages: 3.76, 3.42, 3.08 >> up 0+03:27:38 16:24:20 >> 104 processes: 11 running, 81 sleeping, 12 waiting >> CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle >> Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq >> 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 >> 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 >> 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 >> 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 >> 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 >> 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 >> 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 >> 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 >> 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net >> 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq >> >> # sysctl dev.em.0 >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=0 function=0 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 >> subdevice=0x0000 class=0x020000 >> dev.em.0.%parent: pci6 >> dev.em.0.debug: -1 >> dev.em.0.stats: -1 >> dev.em.0.rx_int_delay: 0 >> dev.em.0.tx_int_delay: 66 >> dev.em.0.rx_abs_int_delay: 66 >> dev.em.0.tx_abs_int_delay: 66 >> dev.em.0.rx_processing_limit: -1 >> >> I've tried both: >> options SCHED_ULE >> options SCHED_4BSD >> >> I've added just the following lines in my kernel config: >> >> options IPFIREWALL >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> >> options NETGRAPH >> options NETGRAPH_PPP >> options NETGRAPH_PPTPGRE >> >> >> My sysctls: >> net.inet.ip.forwarding=1 >> net.inet.ip.fastforwarding=1 >> net.inet.ip.redirect=0 >> net.inet.ip.random_id=1 >> net.inet.ip.ttl=255 >> net.inet.ip.intr_queue_maxlen=4096 >> >> kern.maxfiles=131072 >> kern.maxfilesperproc=32768 >> kern.maxprocperuid=32768 >> >> kern.ipc.somaxconn=65535 >> kern.ipc.maxsockets=32768 >> kern.ipc.maxsockbuf=16777216 >> >> net.inet.tcp.rfc1323=1 >> net.inet.tcp.recvspace=65536 >> net.inet.tcp.sendspace=32768 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet.tcp.sendbuf_auto=1 >> net.inet.tcp.sendbuf_inc=8192 >> net.inet.tcp.recvbuf_auto=1 >> net.inet.tcp.recvbuf_inc=16384 >> net.inet.tcp.maxtcptw=40960 >> net.inet.tcp.msl=2500 >> net.inet.tcp.delayed_ack=0 >> net.inet.tcp.nolocaltimewait=1 >> >> net.inet.udp.checksum=0 >> net.inet.udp.recvspace=65535 >> net.inet.udp.maxdgram=57344 >> >> net.inet.icmp.icmplim=30 >> >> net.inet.tcp.blackhole=2 >> net.inet.udp.blackhole=1 >> >> net.local.stream.recvspace=65535 >> net.local.stream.sendspace=65535 >> >> net.isr.direct=1 >> >> kern.timecounter.hardware=TSC >> >> dev.em.0.rx_processing_limit=-1 >> >> If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a >> core, but without errors: >> # netstat -w 1 -I em0 >> input (em0) output >> packets errs bytes packets errs bytes colls >> 6953 0 2860537 8703 0 4882814 0 >> 6785 0 2587635 7683 0 4443958 0 >> 7006 0 2576630 8718 0 4924591 0 >> 6887 0 2652461 8272 0 4548049 0 >> 6854 0 2610157 8689 0 5152459 0 >> 6889 0 2586067 8265 0 5010795 0 >> 6878 0 2586746 8255 0 4734959 0 >> ^C >> >> Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. >> >> Please, help to solve the problem. Thanks! >> >> -- >> Oleksandr Samoylyk >> OVS-RIPE >> _______________________________________________ >> 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" >> -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Sun May 4 00:42:26 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 00:42:33 2008 Subject: Troubles with em on FreeBSD 7 Message-ID: <481C84B7.6020205@samoylyk.sumy.ua> Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Sun May 4 00:42:26 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 00:42:34 2008 Subject: Troubles with em on FreeBSD 7 Message-ID: <481CCB3E.9070302@samoylyk.sumy.ua> Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From kip.macy at gmail.com Sun May 4 04:46:20 2008 From: kip.macy at gmail.com (Kip Macy) Date: Sun May 4 04:46:22 2008 Subject: Planned contrib/rdma import In-Reply-To: References: Message-ID: On Wed, Apr 16, 2008 at 5:47 PM, Kip Macy wrote: > I plan on committing the generic kernel level rdma verb and iwarp > infrastructure from OFED as well as the Chelsio iwarp driver to HEAD > next week. The RDMA infrastructure doesn't require any kernel changes > so I don't foresee any need for a lengthy discussion. For the most > part this does not include IB support. Nonetheless, for users that > want to add IB support this would be a good starting point. > > To optimally support user level RDMA would require some extension to > the mmap interface but this only supports rdma from the kernel at this > time. > > > The code in question that I plan to commit is at: > http://157.22.130.171/svn/branches/projects/iwarp/sys/contrib/rdma/ Due to some unforeseen events, I did not commit this when I intended to. I plan to finally commit this in the next day or two. -Kip From jonathan at kc8onw.net Sun May 4 09:13:01 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Sun May 4 09:13:09 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> Message-ID: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> [snip discussion] Sorry to all for the noise, turns out that with a motherboard BIOS update the card is recognized and initialized fine. For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I updated to the 1001 version. Jonathan Stewart From oleksandr at samoylyk.sumy.ua Sun May 4 11:25:14 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 11:25:17 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481CF009.4050606@samoylyk.sumy.ua> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> Message-ID: <481D9D13.1040505@samoylyk.sumy.ua> Oleksandr Samoylyk wrote: > Alexander Sack wrote: >> Oleksandr: >> >> Are you using DEVICE_POLLING by chance? If so, have you tried turning >> it off (ifconfig use -polling etc.)? Just curious. >> > > Surely, no :) > > # ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > options=19b > > > I'm just trying the same configuration on i386. > The same thing here (i386): PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 745 root 436 104 0 219M 67028K select 1 0:00 4845.65% mpd5 23 root 1 -68 - 0K 8K CPU1 0 333:40 100.00% em0 taskq -- Oleksandr Samoylyk OVS-RIPE From stefan.lambrev at moneybookers.com Sun May 4 13:48:30 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Sun May 4 13:48:33 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481D9D13.1040505@samoylyk.sumy.ua> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> Message-ID: <481DBEA7.3050309@moneybookers.com> Oleksandr Samoylyk wrote: > Oleksandr Samoylyk wrote: >> Alexander Sack wrote: >>> Oleksandr: >>> >>> Are you using DEVICE_POLLING by chance? If so, have you tried turning >>> it off (ifconfig use -polling etc.)? Just curious. >>> >> >> Surely, no :) >> >> # ifconfig em0 >> em0: flags=8843 metric 0 mtu 1500 >> >> options=19b >> >> >> I'm just trying the same configuration on i386. >> > > The same thing here (i386): > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 745 root 436 104 0 219M 67028K select 1 0:00 4845.65% mpd5 > 23 root 1 -68 - 0K 8K CPU1 0 333:40 100.00% em0 > taskq > how many packets per second ? I've seen this only during syn floods :) Can you show the output of netstat -I em0 2 ? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From oleksandr at samoylyk.sumy.ua Sun May 4 13:54:23 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 13:54:27 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481DBEA7.3050309@moneybookers.com> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> <481DBEA7.3050309@moneybookers.com> Message-ID: <481DC00E.6050705@samoylyk.sumy.ua> Stefan Lambrev wrote: > how many packets per second ? > I've seen this only during syn floods :) > > Can you show the output of netstat -I em0 2 ? > netstat -I em0 -w 1: input (em0) output packets errs bytes packets errs bytes colls 13440 0 5543030 17270 0 14214946 0 13330 0 5350865 16986 0 13916604 0 13802 0 5726053 17437 0 14234045 0 13383 0 5156923 17368 0 14865294 0 13526 0 5445259 16621 0 13465955 0 13034 0 5198973 16380 0 13649879 0 13562 0 5745386 17104 0 14474587 0 13606 0 5679775 16896 0 14090998 0 13204 0 5102628 16571 0 14323789 0 13266 0 5461232 16565 0 13667754 0 13598 0 5585068 16458 0 13642706 0 13427 0 5494987 16588 0 13605531 0 -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Sun May 4 18:40:42 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 18:40:46 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481DC00E.6050705@samoylyk.sumy.ua> References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> <481DBEA7.3050309@moneybookers.com> <481DC00E.6050705@samoylyk.sumy.ua> Message-ID: <481E031D.40300@samoylyk.sumy.ua> Moreover, here is a result of profiling: granularity: each sample hit covers 16 byte(s) for 0.00% of 221.50 seconds called/total parents index %time self descendents called+self name index called/total children [1] 68.5 0.00 151.71 taskqueue_thread_loop [1] 0.02 145.30 1391229/1391229 taskqueue_run [2] 0.03 6.37 1391229/1391229 msleep_spin [39] ----------------------------------------------- 0.02 145.30 1391229/1391229 taskqueue_thread_loop [1] [2] 65.6 0.02 145.30 1391229 taskqueue_run [2] 0.16 143.27 1395192/1395192 em_handle_rxtx [3] 0.00 0.96 1395192/1412690 wakeup [119] 0.91 0.00 1395192/93426961 spinlock_exit [12] 0.00 0.00 1395192/39782518 spinlock_enter [173] 0.00 0.00 3/93426961 _mtx_lock_spin [933] ----------------------------------------------- 0.16 143.27 1395192/1395192 taskqueue_run [2] [3] 64.8 0.16 143.27 1395192 em_handle_rxtx [3] 1.00 136.80 1395192/1395192 em_rxeof [4] 0.35 4.74 1395192/1398898 em_txeof [50] 0.30 0.02 12711/749987 _mtx_lock_sleep [21] 0.03 0.00 1395192/1395192 em_enable_intr [333] 0.02 0.01 72300/4819861 em_start_locked [109] 0.00 0.01 2175/1395706 taskqueue_enqueue [47] 0.00 0.00 7/176995 _mtx_unlock_sleep [114] ----------------------------------------------- 1.00 136.80 1395192/1395192 em_handle_rxtx [3] [4] 62.2 1.00 136.80 1395192 em_rxeof [4] 0.68 133.48 3338526/3338526 ether_input [5] 0.14 2.50 3338526/3338526 em_get_buf [79] ----------------------------------------------- 0.68 133.48 3338526/3338526 em_rxeof [4] [5] 60.6 0.68 133.48 3338526 ether_input [5] 0.10 132.73 3338526/3338526 ether_demux [6] 0.15 0.36 3338526/3338700 random_harvest [142] 0.13 0.00 3338526/8161034 bcmp [165] ----------------------------------------------- 0.10 132.73 3338526/3338526 ether_input [5] [6] 60.0 0.10 132.73 3338526 ether_demux [6] 0.18 132.50 3338526/3338526 netisr_dispatch [7] 0.04 0.00 3338526/9831758 m_adj [216] 0.02 0.00 3336226/3336226 ip_fastforward [345] ----------------------------------------------- 0.18 132.50 3338526/3338526 ether_demux [6] [7] 59.9 0.18 132.50 3338526 netisr_dispatch [7] 0.89 131.60 4859336/4860183 ip_input [8] 0.00 0.01 2300/2300 arpintr [486] ----------------------------------------------- 0.00 0.02 847/4860183 netisr_processqueue [343] 0.89 131.60 4859336/4860183 netisr_dispatch [7] [8] 59.8 0.89 131.62 4860183 ip_input [8] 0.13 110.45 1642617/1642617 encap4_input [9] 0.42 17.79 3192274/3192274 ip_forward [22] 0.12 2.55 4860142/11299824 pfil_run_hooks [43] 0.01 0.08 8736/8736 tcp_input [224] 0.00 0.05 2331/2331 icmp_input [272] 0.00 0.01 20490/20490 ip_reass [381] 0.00 0.00 897/897 udp_input [692] 0.00 0.00 16/16 igmp_input [833] 0.00 0.00 41/8214484 m_freem [34] 0.00 0.00 22/6451824 in_cksum_skip [163] ----------------------------------------------- 0.13 110.45 1642617/1642617 ip_input [8] [9] 49.9 0.13 110.45 1642617 encap4_input [9] 93.07 17.27 1642617/1643247 rip_input [10] 0.11 0.00 3285234/40183056 generic_bzero [113] 0.01 0.00 3285234/40183057 bzero [219] ----------------------------------------------- 0.00 0.00 16/1643247 igmp_input [833] 0.03 0.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10] 49.8 93.10 17.27 1643247 rip_input [10] 14.26 0.88 600796/749987 _mtx_lock_sleep [21] 0.16 1.70 1643863/1643863 raw_append [93] 0.00 0.24 36345/176995 _mtx_unlock_sleep [114] 0.01 0.00 1643863/5117962 jailed [278] 0.00 0.00 1292/1843 m_copym [666] 0.00 0.00 676/8214484 m_freem [34] ----------------------------------------------- [11] 27.5 60.76 0.11 93426961+50755313 [11] 60.29 0.00 39782516 spinlock_exit [12] 0.23 0.10 14907668 _thread_lock_flags [164] 0.23 0.00 80459841 critical_exit [180] 0.00 0.02 4486040 sched_switch [380] 0.00 0.00 59579 _mtx_lock_spin [933] 0.00 0.00 295 thread_zombie [1331] 0.00 0.00 4486040 mi_switch [1415] 0.00 0.00 295 thread_stash [1661] ----------------------------------------------- 295 thread_zombie [1331] 52826 _mtx_lock_spin [933] 149280 _thread_lock_flags [164] 1197932 critical_exit [180] 2676133 sched_switch [380] 0.00 0.00 1/93426961 pmap_growkernel [1317] 0.00 0.00 3/93426961 smp_targeted_tlb_shootdown [1329] 0.00 0.00 4/93426961 kern_setitimer [1259] 0.00 0.00 6/93426961 kern_setrlimit [1064] 0.00 0.00 6/93426961 donice [1216] 0.00 0.00 6/93426961 sched_nice [1250] 0.00 0.00 7/93426961 thread_find [1294] 0.00 0.00 24/93426961 sc_draw_cursor_image [1195] 0.00 0.00 24/93426961 sc_puts [1173] 0.00 0.00 26/93426961 signotify [539] 0.00 0.00 30/93426961 turnstile_adjust_thread [1177] 0.00 0.00 47/93426961 pmap_pinit [1021] 0.00 0.00 70/93426961 thread_reap [568] 0.00 0.00 174/93426961 ioapic_enable_source [1017] 0.00 0.00 174/93426961 ioapic_disable_source [1016] 0.00 0.00 216/93426961 sched_balance [657] 0.00 0.00 272/93426961 calcru [555] 0.00 0.00 295/93426961 kse_unlink [976] 0.00 0.00 384/93426961 sleepq_switch [72] 0.00 0.00 565/93426961 sigqueue_delete_set_proc [928] 0.00 0.00 596/93426961 sleepq_remove [686] 0.00 0.00 607/93426961 doselwakeup [199] 0.00 0.00 1833/93426961 exec_setregs [634] 0.00 0.00 1986/93426961 create_thread [463] 0.00 0.00 2088/93426961 pcireg_cfgread [810] 0.00 0.00 2324/93426961 thread_wait [464] 0.00 0.00 2344/93426961 exit1 [209] 0.00 0.00 2344/93426961 cpu_exit [733] 0.00 0.00 2394/93426961 cpu_fork [687] 0.00 0.00 2405/93426961 tdsignal [591] 0.00 0.00 2639/93426961 sched_exit_thread [579] 0.00 0.00 2749/93426961 kern_select [428] 0.00 0.00 2934/93426961 thread_exit [436] 0.00 0.00 3054/93426961 fork_exit [530] 0.00 0.00 3066/93426961 upcall_reap [681] 0.00 0.00 3219/93426961 poll [341] 0.00 0.00 3454/93426961 random_kthread [150] 0.00 0.00 3456/93426961 lim_cb [541] 0.00 0.00 3940/93426961 turnstile_cancel [647] 0.00 0.00 4834/93426961 sleepq_wait_sig [362] 0.00 0.00 5050/93426961 scrn_update [583] 0.00 0.00 5384/93426961 ast [434] 0.00 0.00 5680/93426961 _callout_stop_safe [566] 0.00 0.00 6964/93426961 tdq_unlock_pair [540] 0.00 0.00 7182/93426961 fork1 [156] 0.00 0.00 7367/93426961 timeout [422] 0.01 0.00 8948/93426961 umtx_thread_cleanup [458] 0.01 0.00 9827/93426961 sleepq_timedwait [339] 0.01 0.00 10820/93426961 sysctl_kern_proc [185] 0.01 0.00 10921/93426961 sysctl_out_proc [190] 0.01 0.00 15008/93426961 sleepq_broadcast [120] 0.01 0.00 18153/93426961 smp_tlb_shootdown [403] 0.01 0.00 21842/93426961 fill_kinfo_proc_only [238] 0.02 0.00 26890/93426961 kern_wait [255] 0.02 0.00 34153/93426961 fill_kinfo_thread [223] 0.02 0.00 34153/93426961 rufetch [273] 0.02 0.00 34153/93426961 sched_pctcpu [275] 0.03 0.00 41180/93426961 sched_relinquish [232] 0.04 0.00 57525/93426961 statclock [234] 0.05 0.00 73748/93426961 ithread_loop [13] 0.10 0.00 156611/93426961 tdq_move [186] 0.11 0.00 176584/93426961 turnstile_chain_unlock [213] 0.11 0.00 176584/93426961 turnstile_broadcast [212] 0.14 0.00 216250/93426961 hardclock [133] 0.24 0.00 368000/93426961 propagate_priority [158] 0.27 0.00 419794/93426961 ipi_bitmap_handler [126] 0.28 0.00 432517/93426961 hardclock_cpu [136] 0.29 0.00 442303/93426961 random_harvest_internal [161] 0.36 0.00 551720/93426961 turnstile_wait [117] 0.38 0.00 578026/93426961 sched_idletd [130] 0.46 0.00 713661/93426961 turnstile_unpend [121] 0.65 0.00 1002645/93426961 sleepq_timedwait_sig [58] 0.66 0.00 1007663/93426961 _sleep [36] 0.66 0.00 1009514/93426961 sched_userret [108] 0.66 0.00 1011766/93426961 sleepq_timeout [80] 0.75 0.00 1154115/93426961 callout_reset [128] 0.80 0.00 1223669/93426961 softclock [55] 0.90 0.00 1391229/93426961 msleep_spin [39] 0.90 0.00 1391229/93426961 sleepq_signal [64] 0.91 0.00 1395192/93426961 taskqueue_run [2] 0.91 0.00 1395706/93426961 taskqueue_enqueue [47] 0.91 0.00 1401314/93426961 sleepq_wait [62] 1.31 0.00 2015712/93426961 sleepq_catch_signals [67] 1.55 0.00 2391125/93426961 intr_event_schedule_thread [70] 1.57 0.00 2419000/93426961 sleepq_add [73] 1.69 0.00 2602529/93426961 thread_lock_set [99] 1.74 0.00 2678939/93426961 thread_lock_unblock [97] 1.74 0.00 2678939/93426961 thread_lock_block [96] 1.83 0.00 2814166/93426961 sleepq_release [95] [12] 27.2 60.29 0.00 39782516 spinlock_exit [12] 39782516 critical_exit [180] ----------------------------------------------- [13] 13.2 0.02 29.15 ithread_loop [13] 0.00 24.78 2565/2565 swi_net [18] 0.04 4.19 79840/79840 softclock [55] 0.05 0.00 73748/93426961 spinlock_exit [12] 0.05 0.00 73746/93426961 _thread_lock_flags [164] 0.05 0.00 73604/93426961 mi_switch [1415] 0.00 0.00 348/348 ata_generic_intr [595] 0.00 0.00 174/174 ioapic_enable_source [1017] ----------------------------------------------- [14] 12.7 1.79 26.30 42212703+24208605 [14] 0.73 13.40 19134629 uma_zalloc_arg [23] 0.61 12.53 19122186 uma_zfree_arg [25] 0.11 0.00 9765739 mb_dtor_mbuf [217] 0.03 0.05 233015 pmap_enter [229] 0.08 0.00 11540146 m_tag_delete_chain [236] 0.02 0.04 48306 free [252] 0.02 0.03 3336409 mb_dtor_pack [257] 0.02 0.03 26102 vm_map_delete [258] 0.04 0.01 377027 vm_object_deallocate [262] 0.00 0.04 48083 malloc [267] 0.02 0.02 20817 vm_object_backing_scan [281] 0.00 0.04 41572 vm_map_insert [283] 0.02 0.02 200903 vm_page_free_toq [305] 0.00 0.02 143645 pmap_remove [366] 0.01 0.01 364837 vm_page_remove [378] 0.02 0.00 106608 pmap_remove_entry [390] 0.01 0.01 36267 vm_object_terminate [393] 0.00 0.01 163934 vm_page_rename [396] 0.00 0.01 47009 vm_object_allocate [401] 0.01 0.00 108872 vm_object_collapse [408] 0.01 0.00 116035 vrele [439] 0.01 0.00 290643 vdropl [494] 0.00 0.00 21555 getblk [517] 0.00 0.00 15381 _vm_map_clip_start [526] 0.00 0.00 39920 vm_map_simplify_entry [528] 0.00 0.00 42476 vinactive [538] 0.00 0.00 13881 vm_object_coalesce [543] 0.00 0.00 17436 vm_object_page_remove [559] 0.00 0.00 1666 kmem_malloc [560] 0.00 0.00 247351 v_decr_usecount [601] 0.00 0.00 9529 _vm_map_clip_end [602] 0.00 0.00 106608 free_pv_entry [608] 0.00 0.00 147290 vm_map_entry_create [614] 0.00 0.00 975 ffs_update [641] 0.00 0.00 23941 pmap_remove_pte [689] 0.00 0.00 41733 ufs_inactive [702] 0.00 0.00 145534 vm_map_entry_dispose [753] 0.00 0.00 42476 VOP_INACTIVE_APV [754] 0.00 0.00 1066 inodedep_lookup [756] 0.00 0.00 165 bufwrite [799] 0.00 0.00 365 free_unr [847] 0.00 0.00 6332 vm_map_remove [873] 0.00 0.00 742 alloc_unr [879] 0.00 0.00 742 thread_ctor [897] 0.00 0.00 420 thread_init [946] 0.00 0.00 73 allocbuf [967] 0.00 0.00 297 thread_dtor [972] 0.00 0.00 686 brelse [986] 0.00 0.00 168 g_vfs_strategy [993] 0.00 0.00 1622 slab_zalloc [1051] 0.00 0.00 80 proc_init [1070] 0.00 0.00 8 bufobj_invalbuf [1075] 0.00 0.00 50 getnewbuf [1176] 0.00 0.00 6 softdep_setup_freeblocks [1190] 0.00 0.00 87 softdep_disk_io_initiation [1204] 0.00 0.00 9 vfs_vmio_release [1227] 0.00 0.00 89 ffs_bufwrite [1257] 0.00 0.00 1248 uma_zalloc_internal [1356] 0.00 0.00 22 flushbuflist [1358] 0.00 0.00 184453 vm_page_free [1448] 0.00 0.00 8542 bread [1508] 0.00 0.00 8542 breadn [1510] 0.00 0.00 3076 uma_zone_slab [1554] 0.00 0.00 2176 mb_zinit_pack [1572] 0.00 0.00 1666 page_alloc [1587] 0.00 0.00 1150 clean_unrhdrl [1591] 0.00 0.00 945 softdep_update_inodeblock [1601] 0.00 0.00 733 vdrop [1609] 0.00 0.00 677 m_tag_delete [1612] 0.00 0.00 677 m_tag_free_default [1613] 0.00 0.00 651 vnode_pager_setsize [1618] 0.00 0.00 420 umtx_thread_init [1641] 0.00 0.00 420 umtxq_alloc [1642] 0.00 0.00 420 sleepq_alloc [1639] 0.00 0.00 420 turnstile_alloc [1640] 0.00 0.00 373 kmem_free [1651] 0.00 0.00 168 ffs_geom_strategy [1684] 0.00 0.00 168 g_alloc_bio [1685] 0.00 0.00 105 workitem_free [1694] 0.00 0.00 80 pstats_alloc [1706] 0.00 0.00 76 uma_large_free [1712] 0.00 0.00 76 page_free [1710] 0.00 0.00 76 bufstrategy [1709] 0.00 0.00 76 VOP_STRATEGY_APV [1708] 0.00 0.00 76 ufs_strategy [1711] 0.00 0.00 48 bucket_alloc [1729] 0.00 0.00 44 uma_large_malloc [1735] 0.00 0.00 33 handle_allocdirect_partdone [1746] 0.00 0.00 31 free_inodedep [1748] 0.00 0.00 28 brelvp [1755] 0.00 0.00 19 geteblk [1788] 0.00 0.00 17 softdep_change_linkcnt [1792] 0.00 0.00 8 vinvalbuf [1816] 0.00 0.00 7 free_allocdirect [1817] 0.00 0.00 6 ffs_truncate [1822] 0.00 0.00 2 vnode_destroy_vobject [1846] 0.00 0.00 2 softdep_releasefile [1843] 0.00 0.00 1 vrecycle [1866] 0.00 0.00 1 vgonel [1863] 0.00 0.00 1 VOP_RECLAIM_APV [1847] 0.00 0.00 1 ufs_reclaim [1861] 0.00 0.00 1 ffs_ifree [1854] 0.00 0.00 1 ffs_vfree [1855] 0.00 0.00 1 softdep_freefile [1858] 0.00 0.00 1 startup_alloc [1859] ----------------------------------------------- -- Oleksandr Samoylyk OVS-RIPE From jfvogel at gmail.com Sun May 4 18:42:15 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun May 4 18:42:21 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> Message-ID: <2a41acea0805041142q286f605bm3bf2fac5065db246@mail.gmail.com> On Sun, May 4, 2008 at 2:13 AM, wrote: > [snip discussion] > > Sorry to all for the noise, turns out that with a motherboard BIOS update > the card is recognized and initialized fine. > > For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I > updated to the 1001 version. > > Jonathan Stewart Excellent, glad to hear that it now works, and thanks the most for getting back on this Jonathan, always good for future searching to have closure :) Jack From mike at sentex.net Sun May 4 21:51:02 2008 From: mike at sentex.net (mike@sentex.net) Date: Sun May 4 21:51:07 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481C84B7.6020205@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> Message-ID: On Sat, 03 May 2008 18:28:55 +0300, in sentex.lists.freebsd.net you wrote: >Hi! > >I'm running a SMP FreeBSD box with mpd5 on it. > ># uname -a >FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 >12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX > amd64 > ># mpd5 -v >Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > >Somehow em0 begins to eat all CPU time of one core. > A new version of the em drivers went into the tree Friday. >dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1 to all of your em nics em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 71949 em1: Good Packets Xmtd = 2507 em1: TSO Contexts Xmtd = 369 em1: TSO Contexts Failed = 0 And are you using gigabit or fastE. If fastE, try disabling TSO as some people have said they have problems with it at 100Mb. ---Mike From paul at gtcomm.net Sun May 4 21:58:28 2008 From: paul at gtcomm.net (Paul) Date: Sun May 4 21:58:31 2008 Subject: Network Patches from -RELEASE to -STABLE 7.0 Message-ID: <481E31E9.2080101@gtcomm.net> Is there a list of patches that have been applied to -STABLE since the -RELEASE ? I can't seem to find a simple organized list of applied patches (something similar to linux kernel changelog). I want to know if anything has been fixed or udpated in the network area to see if it warrants changing the kernel to -STABLE on a production machine. Thank you From bms at FreeBSD.org Sun May 4 22:03:56 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun May 4 22:04:01 2008 Subject: Network Patches from -RELEASE to -STABLE 7.0 In-Reply-To: <481E31E9.2080101@gtcomm.net> References: <481E31E9.2080101@gtcomm.net> Message-ID: <481E32C9.8010204@FreeBSD.org> Paul wrote: > Is there a list of patches that have been applied to -STABLE since > the -RELEASE ? > I can't seem to find a simple organized list of applied patches > (something similar to linux kernel changelog). > I want to know if anything has been fixed or udpated in the network > area to see if it warrants changing the kernel to -STABLE on a > production machine. This information is typically present in commit messages, or in FreeBSD's release notes. It's not something which is compiled on an ad-hoc basis, it is specifically compiled on a per release basis, although you may occasionally see the release engineers updating the release notes for -CURRENT. Cheers BMS From oleksandr at samoylyk.sumy.ua Sun May 4 22:07:14 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 22:07:18 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: References: <481C84B7.6020205@samoylyk.sumy.ua> Message-ID: <481E338D.6040706@samoylyk.sumy.ua> mike@sentex.net wrote: > > A new version of the em drivers went into the tree Friday. > >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > subdevice=0x108c class=0x020000 > dev.em.0.%parent: pci13 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 I tried both: - new drivers: 6.9.0 - rx_processing_limit: 100 Result the same :( > Also, post some of the stats. Do a > sysctl -w dev.em.1.stats=1 > to all of your em nics em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 434970 em0: Receive No Buffers = 290593 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 2929 em0: watchdog timeouts = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 64182304 em0: Good Packets Xmtd = 84277659 em0: TSO Contexts Xmtd = 832 em0: TSO Contexts Failed = 0 em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 62431510 m1: Good Packets Xmtd = 55466567 em1: TSO Contexts Xmtd = 0 em1: TSO Contexts Failed = 0 > And are you using gigabit or fastE. If fastE, try disabling TSO as > some people have said they have problems with it at 100Mb. I'm on GgE. Disabling TSO doesn't help as well. -- Oleksandr Samoylyk OVS-RIPE From mike at sentex.net Sun May 4 22:20:14 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun May 4 22:20:20 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481E338D.6040706@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> Message-ID: <200805042220.m44MKCgK061568@lava.sentex.ca> At 06:07 PM 5/4/2008, Oleksandr Samoylyk wrote: I tried both: >- new drivers: 6.9.0 >- rx_processing_limit: 100 > >Result the same :( > >>Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1 >>to all of your em nics > >em0: Excessive collisions = 0 >em0: Sequence errors = 0 >em0: Defer count = 0 >em0: Missed Packets = 434970 >em0: Receive No Buffers = 290593 >em0: Receive Length Errors = 0 >em0: Receive errors = 0 >em0: Crc errors = 0 >em0: Alignment errors = 0 >em0: Collision/Carrier extension errors = 0 >em0: RX overruns = 2929 >em0: watchdog timeouts = 0 >em0: XON Rcvd = 0 >em0: XON Xmtd = 0 >em0: XOFF Rcvd = 0 >em0: XOFF Xmtd = 0 >em0: Good Packets Rcvd = 64182304 >em0: Good Packets Xmtd = 84277659 >em0: TSO Contexts Xmtd = 832 >em0: TSO Contexts Failed = 0 > >em1: Excessive collisions = 0 >em1: Sequence errors = 0 >em1: Defer count = 0 >em1: Missed Packets = 0 >em1: Receive No Buffers = 0 >em1: Receive Length Errors = 0 >em1: Receive errors = 0 >em1: Crc errors = 0 >em1: Alignment errors = 0 >em1: Collision/Carrier extension errors = 0 >em1: RX overruns = 0 >em1: watchdog timeouts = 0 >em1: XON Rcvd = 0 >em1: XON Xmtd = 0 >em1: XOFF Rcvd = 0 >em1: XOFF Xmtd = 0 >em1: Good Packets Rcvd = 62431510 >m1: Good Packets Xmtd = 55466567 >em1: TSO Contexts Xmtd = 0 >em1: TSO Contexts Failed = 0 > >>And are you using gigabit or fastE. If fastE, try disabling TSO as >>some people have said they have problems with it at 100Mb. > >I'm on GgE. Disabling TSO doesn't help as well. Perhaps time to engage the driver author for insight / help ---Mike From jfvogel at gmail.com Sun May 4 22:29:43 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun May 4 22:29:46 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481E338D.6040706@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> Message-ID: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> On Sun, May 4, 2008 at 3:07 PM, Oleksandr Samoylyk wrote: > mike@sentex.net wrote: > > > > > A new version of the em drivers went into the tree Friday. > > > > > > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > > > > > > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 > > dev.em.0.%driver: em > > dev.em.0.%location: slot=0 function=0 > > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > > subdevice=0x108c class=0x020000 > > dev.em.0.%parent: pci13 > > dev.em.0.debug: -1 > > dev.em.0.stats: -1 > > dev.em.0.rx_int_delay: 0 > > dev.em.0.tx_int_delay: 66 > > dev.em.0.rx_abs_int_delay: 66 > > dev.em.0.tx_abs_int_delay: 66 > > dev.em.0.rx_processing_limit: 100 > > > > I tried both: > > - new drivers: 6.9.0 > - rx_processing_limit: 100 > > Result the same :( > > > > > Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1 > > to all of your em nics > > > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 434970 > em0: Receive No Buffers = 290593 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 2929 > em0: watchdog timeouts = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 64182304 > em0: Good Packets Xmtd = 84277659 > em0: TSO Contexts Xmtd = 832 > em0: TSO Contexts Failed = 0 > > > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 0 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: RX overruns = 0 > em1: watchdog timeouts = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 62431510 > m1: Good Packets Xmtd = 55466567 > em1: TSO Contexts Xmtd = 0 > > em1: TSO Contexts Failed = 0 > > > > And are you using gigabit or fastE. If fastE, try disabling TSO as > > some people have said they have problems with it at 100Mb. > > > > I'm on GgE. Disabling TSO doesn't help as well. You are running out of RX side resources, did you say this was UDP? I'm guessing upping your mbuf pool at least, I can't think of something in driver-wise that would help. If you have this same load going into a different nic, or different os (like say Linux) can it manage? This will take some thought, I'm not sure off the top of my head here. Jack From jfvogel at gmail.com Sun May 4 22:32:17 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun May 4 22:32:20 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> Message-ID: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Oh, I just had a thought, increase the RX processing limit, that only allows you to process 100 packets in one pass. First change it to 250 and see what it does, you might also set it to -1 which will allow you to process til you drain the ring, the risk is that you cause other problems by doing that, but heck at this point anything is worth trying, right? Jack From oleksandr at samoylyk.sumy.ua Sun May 4 23:07:50 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 23:07:56 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> Message-ID: <481E41C2.6020906@samoylyk.sumy.ua> Jack Vogel wrote: > You are running out of RX side resources, did you say this > was UDP? I'm guessing upping your mbuf pool at least, I > can't think of something in driver-wise that would help. > > If you have this same load going into a different nic, or > different os (like say Linux) can it manage? Linux (latest 2.6.24, e1000 with NAPI) on the same hardware with same same tasks having been successfully coped with this load. I just wanted to move to FreeBSD in order to use mpd5 pptp-server with ng_car. I tried different (and new) Intel PRO 1000 NICs (PCI & PCI Express), but all the same. I'm trying to share load with separate adaptors (3 for LAN with deterrent IPs) and one for external interface (which nearly always eates much less CPU time). Vladimir Ivanov, the developer of SMPable version of EM driver, made a guess that this could be a problem with ng_* staff. I've: # kldstat Id Refs Address Size Name 1 13 0xffffffff80100000 760c78 kernel 2 1 0xffffffffae3bb000 8c73 ipfw.ko 3 1 0xffffffffae3ec000 19ba ng_socket.ko 4 10 0xffffffffae3ee000 8f14 netgraph.ko 7 1 0xffffffffae44f000 a9e ng_tee.ko 8 1 0xffffffffae450000 1a22 ng_pptpgre.ko 9 1 0xffffffffae452000 202a ng_ksocket.ko 10 1 0xffffffffae66c000 13a6 ng_iface.ko 11 1 0xffffffffae66e000 459e ng_ppp.ko 12 1 0xffffffffae678000 9e2 ng_tcpmss.ko 13 1 0xffffffffae45a000 1b24 ng_bpf.ko 14 1 0xffffffffae45c000 13be ng_car.ko 15 1 0xffffffffae4cd000 1ea4 ng_vjc.ko and I couple of ipfw rules (in order not to pass local traffic through the pptp-tunnels): deny ip from any to 10.0.0.0/8 via ng* deny ip from any to 172.16.0.0/12 via ng* deny ip from any to 192.168.0.0/16 via ng* deny ip from any to 224.0.0.0/3 via ng* deny ip from any to 169.254.0.0/16 via ng* Nothing less, nothing more :) -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Sun May 4 23:09:49 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 23:09:52 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Message-ID: <481E423B.2080400@samoylyk.sumy.ua> Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > Tried that also, see my first post. My loader.conf has: hw.em.rxd="4096" -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Sun May 4 23:16:47 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 4 23:16:51 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481E3C32.8000507@gtcomm.net> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> Message-ID: <481E43DD.8080300@samoylyk.sumy.ua> Paul wrote: > What is your kernel HZ setting? 1000 > in /boot/loader.conf try adding these two lines: > hw.em.rxd=1024 > hw.em.txd=1024 I've already had: # cat /boot/loader.conf loader_logo="beastie" autoboot_delay="3" hw.em.rxd="4096" hw.em.txd="4096" > and then do this in sysctl.conf: > net.inet.ip.intr_queue_maxlen=1024 - already > net.route.netisr_maxqlen=512 Ok. I just increased from default 256 up to 512 > kern.ipc.maxsockbuf=8388608 It was already higher > kern.ipc.nmbclusters=128000 Ok, I just increased nmbclusters. > > I think this should fix your packet loss problem. Are you doing ip > forwarding at all? If so use: > net.inet.ip.fastforwarding=1 It was already in my sysctl.conf -- Oleksandr Samoylyk OVS-RIPE From linimon at FreeBSD.org Mon May 5 01:06:29 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:06:32 2008 Subject: kern/109733: [bge] bge link state issues [regression] Message-ID: <200805050106.m4516TjK091670@freefall.freebsd.org> Synopsis: [bge] bge link state issues [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:06:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109733 From linimon at FreeBSD.org Mon May 5 01:06:54 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:06:57 2008 Subject: kern/109308: [pppd] [panic] Multiple panics kernel ppp suspected [regression] Message-ID: <200805050106.m4516rbt091749@freefall.freebsd.org> Synopsis: [pppd] [panic] Multiple panics kernel ppp suspected [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:06:43 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109308 From linimon at FreeBSD.org Mon May 5 01:07:42 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:07:46 2008 Subject: bin/108895: pppd(8): PPPoE dead connections on 6.2 [regression] Message-ID: <200805050107.m4517gn7091887@freefall.freebsd.org> Synopsis: pppd(8): PPPoE dead connections on 6.2 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:07:34 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=108895 From linimon at FreeBSD.org Mon May 5 01:11:02 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:11:04 2008 Subject: kern/105925: Regression in ifconfig(8) + vlan(4) [regression] Message-ID: <200805050111.m451B2RH092351@freefall.freebsd.org> Synopsis: Regression in ifconfig(8) + vlan(4) [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:10:38 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=105925 From linimon at FreeBSD.org Mon May 5 01:16:19 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:16:21 2008 Subject: kern/91594: [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] Message-ID: <200805050116.m451GIsu094281@freefall.freebsd.org> Old Synopsis: FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-ort NIC in PCI slot 3 of DL380 G4 (regression) New Synopsis: [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:15:40 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=91594 From linimon at FreeBSD.org Mon May 5 01:41:09 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:41:12 2008 Subject: kern/122858: [nsswitch] nsswitch in 7.0 is f*cked up Message-ID: <200805050141.m451f8Ra098423@freefall.freebsd.org> Synopsis: [nsswitch] nsswitch in 7.0 is f*cked up Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:40:11 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=122858 From linimon at FreeBSD.org Mon May 5 01:45:12 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 01:45:14 2008 Subject: kern/119516: [ip6] [panic] _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /usr/src/sys/net/route.c:1287 Message-ID: <200805050145.m451jBDn098793@freefall.freebsd.org> Synopsis: [ip6] [panic] _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /usr/src/sys/net/route.c:1287 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:44:51 UTC 2008 Responsible-Changed-Why: This is probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=119516 From oleksandr at samoylyk.sumy.ua Mon May 5 05:41:33 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Mon May 5 05:41:37 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Message-ID: <481E9E06.3040603@samoylyk.sumy.ua> Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > last pid: 55326; load averages: 1.40, 1.24, 1.05 up 0+06:56:52 08:32:41 83 processes: 10 running, 60 sleeping, 13 waiting CPU states: 0.5% user, 0.0% nice, 10.5% system, 1.1% interrupt, 87.9% idle Mem: 42M Active, 265M Inact, 272M Wired, 244K Cache, 214M Buf, 7338M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K CPU6 6 413:05 100.00% idle: cpu6 16 root 1 171 ki31 0K 16K RUN 2 401:28 100.00% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 402:45 96.09% idle: cpu3 17 root 1 171 ki31 0K 16K CPU1 1 398:26 92.68% idle: cpu1 14 root 1 171 ki31 0K 16K CPU4 4 401:24 90.28% idle: cpu4 18 root 1 171 ki31 0K 16K CPU0 0 382:00 89.26% idle: cpu0 13 root 1 171 ki31 0K 16K CPU5 5 392:57 81.40% idle: cpu5 11 root 1 171 ki31 0K 16K CPU7 7 378:44 59.47% idle: cpu7 30 root 1 -68 - 0K 16K CPU7 7 37:24 44.78% em1 taskq 31 root 1 -68 - 0K 16K - 5 23:00 18.26% em2 taskq 19 root 1 -44 - 0K 16K WAIT 3 35:45 14.60% swi1: net 32 root 1 -68 - 0K 16K - 0 19:51 7.08% em3 taskq 722 root 2 5 0 68280K 21652K select 2 0:00 1.46% mpd5 20 root 1 -32 - 0K 16K WAIT 2 3:56 0.00% swi4: clock 29 root 1 -68 - 0K 16K - 6 2:53 0.00% em0 taskq 22 root 1 44 - 0K 16K - 1 0:49 0.00% yarrow I've added more NICs. The thing is that the most busiest interface is em3 (uplink) and it's just 7%. # netstat -I em0 -w 1 (just for the way back traffic) input (em0) output packets errs bytes packets errs bytes colls 13 0 2344 8408 0 4290811 0 20 0 2232 8147 0 4179926 0 12 0 1358 8204 0 3984088 0 33 0 5660 7982 0 3944704 0 25 0 3165 8183 0 4226968 0 10 0 1012 8620 0 4288722 0 25 0 2822 8283 0 4220019 0 ^C # netstat -I em1 -w 1 input (em1) output packets errs bytes packets errs bytes colls 7137 0 2618138 0 0 0 0 6772 0 2565885 0 0 0 0 6982 0 2430458 0 0 0 0 6758 0 2459663 0 0 0 0 7036 0 2665113 0 0 0 0 ^C # netstat -I em2 -w 1 input (em2) output packets errs bytes packets errs bytes colls 1237 0 327276 0 0 0 0 1158 0 328459 0 0 0 0 1243 0 346992 0 0 0 0 1076 0 323918 0 0 0 0 1242 0 363008 0 0 0 0 ^C # netstat -I em3 -w 1 input (em3) output packets errs bytes packets errs bytes colls 5681 0 3822499 6233 0 2443102 0 5958 0 4233009 6692 0 2354643 0 6202 0 4296877 6432 0 2455513 0 6117 0 4146643 6419 0 2327346 0 6324 0 4128040 6695 0 2468243 0 5856 0 4052255 6252 0 2445518 0 ^C Why so? -- Oleksandr Samoylyk OVS-RIPE From bugmaster at FreeBSD.org Mon May 5 11:07:10 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:21 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200805051107.m45B79jf070781@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123123 net [re][patch] Realtek RTL8111C detection and failure f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes 67 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re][patch] re(4) unsupported hardware revision (8168/ o kern/123147 net [ti] [patch] ti(4) doesn't use mii, but kernel configs 45 problems total. From oleksandr at samoylyk.sumy.ua Mon May 5 11:23:44 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Mon May 5 11:23:47 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Message-ID: <481EEE34.7060804@samoylyk.sumy.ua> Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > Nothing has helped. :( I need to unplug and plug in again patch cords each time when my CPUs with emX go 100% in order to keep my server alive with a descent pings. I mentioned that "100%: emX taskq" occurs only on that interfaces where GRE packets are being processed. External interface to Internet feels great. Pings are <0ms and load is 9.57% with 14kpps (input/output). Maybe interesting: According to kgmon: % cumulative self self total time seconds seconds calls ms/call ms/call name 39.9 93.10 93.10 1643247 0.06 0.07 rip_input [10] Is it em related or mpd related or something else? Back to releng_6? Not sure though. :( -- Oleksandr Samoylyk OVS-RIPE From zinovik at kspu.karelia.ru Mon May 5 13:29:39 2008 From: zinovik at kspu.karelia.ru (Igor Zinovik) Date: Mon May 5 13:29:43 2008 Subject: Trying to find source of collisions Message-ID: <20080505114938.GA34390@zinovik.kpsu.local> Hello, net@ readers. I'm relatively new to freebsd networking so i'm asking here, because i did not found information in man netstat. I have a machine that suffers from collisions. Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 134590 ... rl0 1500 00:00:1c:dc:b8:d6 23455543 0 36137069 0 0 This is ordinary RELENG_6_1, with ed0 and rl0 acting as gateway. UTP cat5 is connected to both NICs. So i have three questions: 1. What can cause such big collisions number? Bad UTP cable? Bad NIC? Misbeheaving switch? 2. Ierr -- seems that some input errors. What are these errors and what can cause them? 3. Should i ever bother about this issue? From wmoran at collaborativefusion.com Mon May 5 13:38:03 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Mon May 5 13:38:13 2008 Subject: Trying to find source of collisions In-Reply-To: <20080505114938.GA34390@zinovik.kpsu.local> References: <20080505114938.GA34390@zinovik.kpsu.local> Message-ID: <20080505093820.ca62fa93.wmoran@collaborativefusion.com> In response to Igor Zinovik : > Hello, net@ readers. > > I'm relatively new to freebsd networking so i'm asking here, because i > did not found information in man netstat. I have a machine that suffers > from collisions. > > Network interface status: > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 134590 > ... > rl0 1500 00:00:1c:dc:b8:d6 23455543 0 36137069 0 0 > > This is ordinary RELENG_6_1, with ed0 and rl0 acting as gateway. UTP > cat5 is connected to both NICs. > > So i have three questions: > 1. What can cause such big collisions number? Bad UTP cable? Bad NIC? > Misbeheaving switch? Collisions are caused by a nearly saturated network. If you're seeing collisions, you need to either reduce the amount of traffic on that network segment, or increase the capacity of that segment. However, switches shouldn't have collisions. Either your switch isn't really a switch, or something else is wrong. > 2. Ierr -- seems that some input errors. What are these errors and what > can cause them? My first guess would be that you've got a duplex/speed mismatch between NIC and switch. If it's a managed switch, force the speed duplex on both the switch and the FreeBSD machine to ensure they match. If it's not a managed switch, replace it because it's not working correctly and there's nothing you can do about it. > 3. Should i ever bother about this issue? Yes. Something is wrong and it will be hurting your network performance. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From fullermd at over-yonder.net Mon May 5 15:14:03 2008 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Mon May 5 15:14:10 2008 Subject: Trying to find source of collisions In-Reply-To: <20080505114938.GA34390@zinovik.kpsu.local> References: <20080505114938.GA34390@zinovik.kpsu.local> Message-ID: <20080505144927.GW67042@over-yonder.net> On Mon, May 05, 2008 at 03:49:38PM +0400 I heard the voice of Igor Zinovik, and lo! it spake thus: > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 > 134590 ... > > So i have three questions: > 1. What can cause such big collisions number? Bad UTP cable? Bad > NIC? Misbeheaving switch? That's not a particularly big number; it's half a percent of your output packets. That probably doesn't have a measurable effect on your throughput or latency. Now, that said, if you have a switch, you probably SHOULD be running full-duplex, in which case you won't have collisions. But you've got an ed card; some of those may be old enough to not handle FDX. > 2. Ierr -- seems that some input errors. What are these errors and > what can cause them? Cable troubles, NIC troubles, etc. [Un]plugging the cable can cause it. Some forms of on-wire data corruption could cause it. You've got 4 of them, over 36 million input packets. Don't worry about it. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From ras at e-gerbil.net Mon May 5 15:14:30 2008 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon May 5 15:14:40 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: References: <481C84B7.6020205@samoylyk.sumy.ua> Message-ID: <20080505162225.GC4889@gerbil.cluepon.net> On Sun, May 04, 2008 at 05:51:22PM -0400, mike@sentex.net wrote: > A new version of the em drivers went into the tree Friday. Yes but it also broke kernel builds if you don't add device igb. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hlwhyw at shtel.net.cn Sun May 4 13:56:51 2008 From: hlwhyw at shtel.net.cn (hlwhyw@shtel.net.cn) Date: Mon May 5 16:23:15 2008 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? Message-ID: <424543f9f5.3f9f542454@shtel.net.cn> Hi, all Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? Kevin Wu From hlwhyw at 81890.net Sun May 4 15:56:55 2008 From: hlwhyw at 81890.net (kevin) Date: Mon May 5 16:24:10 2008 Subject: Is it possible to change BSD licence to GPL for 4.4BSD-Lite's source code? Message-ID: <001b01c8adff$6cd4cbd0$5084183a@honglan> Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From hlwhyw at 81890.net Sun May 4 22:31:51 2008 From: hlwhyw at 81890.net (kevin) Date: Mon May 5 16:24:58 2008 Subject: Change from BSDL to GPL Message-ID: <001701c8ae36$96f0f560$5084183a@honglan> Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From hlwhyw at 81890.net Sun May 4 22:43:32 2008 From: hlwhyw at 81890.net (kevin) Date: Mon May 5 16:25:09 2008 Subject: Change from BSDL to GPL Message-ID: <002e01c8ae38$3a343240$5084183a@honglan> Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From davidch at broadcom.com Mon May 5 16:27:22 2008 From: davidch at broadcom.com (David Christensen) Date: Mon May 5 16:27:26 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> > > Yes, I'm building a debug kernel. I have the line listed above as > well > > as the following: > > > > options KDB > > options DDB > > options GDB > > options INVARIANTS > > options INVARIANT_SUPPORT > > options WITNESS > > options WITNESS_SKIPSPIN > > Dave: > > What symbols can you not access exactly and how are you > installing/setting up debugging? > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > without a problem. I can examine them and call them. I'm not using > options GDB however, only KDB/DDB. > > I would: > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > generated/installed which contains the debug sections of your ko (from > the objcopy calls during the build - the binary is stripped with a > section pointer to the if_bce.ko.symbols file for debugging > information I believe) > - If you are using GDB, make sure its pointed to the right source base > so it can retrieve symbol information correctly > - If you are using GDB, stub it out and just use DDB to verify that > your build is sane (it works for me!) > - If all else fails, you can always build bce statically (just to move > forward etc.) - Enable the kernel debugger as described above - Build the driver in the /usr/src/sys/modules/bce directory with the command "make". - Run the command "nm if_bce.ko | grep dump_stat" in the same directory with the kernel module just built. In my case I only see a symbol for bce_dump_status_block, but there is a second routine called bce_dump_stats_block. In my working build there are 23 functions that start with "bce_dump" but only 8 are displayed with the command "nm if_bce.ko | grep bce_dump". Of course, I also get the symbol not present error when I try to use any of those missing symbols through a "call" command in the debugger. Dave From kostikbel at gmail.com Mon May 5 16:32:59 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 5 16:33:04 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <20080505163249.GU18958@deviant.kiev.zoral.com.ua> On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > Yes, I'm building a debug kernel. I have the line listed above as > > well > > > as the following: > > > > > > options KDB > > > options DDB > > > options GDB > > > options INVARIANTS > > > options INVARIANT_SUPPORT > > > options WITNESS > > > options WITNESS_SKIPSPIN > > > > Dave: > > > > What symbols can you not access exactly and how are you > > installing/setting up debugging? > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > without a problem. I can examine them and call them. I'm not using > > options GDB however, only KDB/DDB. > > > > I would: > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > generated/installed which contains the debug sections of your ko (from > > the objcopy calls during the build - the binary is stripped with a > > section pointer to the if_bce.ko.symbols file for debugging > > information I believe) > > - If you are using GDB, make sure its pointed to the right source base > > so it can retrieve symbol information correctly > > - If you are using GDB, stub it out and just use DDB to verify that > > your build is sane (it works for me!) > > - If all else fails, you can always build bce statically (just to move > > forward etc.) > > - Enable the kernel debugger as described above > - Build the driver in the /usr/src/sys/modules/bce directory with the > command "make". > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > with the kernel module just built. > > In my case I only see a symbol for bce_dump_status_block, but there is a > second routine called bce_dump_stats_block. In my working build there > are 23 functions that start with "bce_dump" but only 8 are displayed with > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > symbol not present error when I try to use any of those missing symbols > through a "call" command in the debugger. Most likely, they are optimized out, gcc likes to inline once-called static functions. Aside from playing with the optimization options, the easiest way seems to use functions somewhere else, e.g., put the addresses into some table. Just guessing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080505/11d39a9b/attachment.pgp From jfvogel at gmail.com Mon May 5 16:35:49 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon May 5 16:35:52 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <20080505162225.GC4889@gerbil.cluepon.net> References: <481C84B7.6020205@samoylyk.sumy.ua> <20080505162225.GC4889@gerbil.cluepon.net> Message-ID: <2a41acea0805050935g28e85c68g5cbdda6fbf1e0b02@mail.gmail.com> On Mon, May 5, 2008 at 9:22 AM, Richard A Steenbergen wrote: > On Sun, May 04, 2008 at 05:51:22PM -0400, mike@sentex.net wrote: > > A new version of the em drivers went into the tree Friday. > > Yes but it also broke kernel builds if you don't add device igb. :) Only for one pass of the build, I fixed that Friday night. Jack From oberman at es.net Mon May 5 16:55:24 2008 From: oberman at es.net (Kevin Oberman) Date: Mon May 5 16:55:29 2008 Subject: Is it possible to change BSD licence to GPL for 4.4BSD-Lite's source code? In-Reply-To: Your message of "Sun, 04 May 2008 23:56:33 +0800." <001b01c8adff$6cd4cbd0$5084183a@honglan> Message-ID: <20080505165522.6D92145010@ptavv.es.net> > Date: Sun, 04 May 2008 23:56:33 +0800 > From: kevin > Sender: owner-freebsd-net@freebsd.org > > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change > its licence from 4.4BSD-Lite licence to GPL licence? I am not a lawyer, but it is generally not possible to re-license BSD code to GPL. It might be possible, with the permission of the code's author(s), to dual license it under both BSD and GPL. It is unclear to me why adding BSD code to a GPL OS would violate any of the terms of either license as ling as you maintain the copyright notice for the BSD code and follow the GPL redistribution rules and other conditions. I don't believe that anything in GPL prohibits the use of non-GPL code as long as the terms of the GPL are adhered to. Finally, 4.4BSD-Lite is very, very old and lacks a great many features needed in a modern network stack. I really don't see why you would want to do this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080505/dece285e/attachment.pgp From kip.macy at gmail.com Mon May 5 18:00:01 2008 From: kip.macy at gmail.com (Kip Macy) Date: Mon May 5 18:00:05 2008 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> References: <424543f9f5.3f9f542454@shtel.net.cn> Message-ID: On Sun, May 4, 2008 at 6:32 AM, wrote: > Hi, all > > Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? > > I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? Yes. BSD licensed code can, by definition, be included in software with any license. The only restriction is that you cannot change the license of the code without permission of the copyright holder. However, I see no reason to do that. -Kip From pisymbol at gmail.com Mon May 5 18:07:01 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Mon May 5 18:07:05 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <20080505163249.GU18958@deviant.kiev.zoral.com.ua> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> Message-ID: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... -aps On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov wrote: > > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > > Yes, I'm building a debug kernel. I have the line listed above as > > > well > > > > as the following: > > > > > > > > options KDB > > > > options DDB > > > > options GDB > > > > options INVARIANTS > > > > options INVARIANT_SUPPORT > > > > options WITNESS > > > > options WITNESS_SKIPSPIN > > > > > > Dave: > > > > > > What symbols can you not access exactly and how are you > > > installing/setting up debugging? > > > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > > without a problem. I can examine them and call them. I'm not using > > > options GDB however, only KDB/DDB. > > > > > > I would: > > > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > > generated/installed which contains the debug sections of your ko (from > > > the objcopy calls during the build - the binary is stripped with a > > > section pointer to the if_bce.ko.symbols file for debugging > > > information I believe) > > > - If you are using GDB, make sure its pointed to the right source base > > > so it can retrieve symbol information correctly > > > - If you are using GDB, stub it out and just use DDB to verify that > > > your build is sane (it works for me!) > > > - If all else fails, you can always build bce statically (just to move > > > forward etc.) > > > > - Enable the kernel debugger as described above > > - Build the driver in the /usr/src/sys/modules/bce directory with the > > command "make". > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > > with the kernel module just built. > > > > In my case I only see a symbol for bce_dump_status_block, but there is a > > second routine called bce_dump_stats_block. In my working build there > > are 23 functions that start with "bce_dump" but only 8 are displayed with > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > > symbol not present error when I try to use any of those missing symbols > > through a "call" command in the debugger. > > Most likely, they are optimized out, gcc likes to inline once-called > static functions. Aside from playing with the optimization options, > the easiest way seems to use functions somewhere else, e.g., put the > addresses into some table. Just guessing. > From delphij at delphij.net Mon May 5 18:20:22 2008 From: delphij at delphij.net (Xin LI) Date: Mon May 5 18:20:27 2008 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> References: <424543f9f5.3f9f542454@shtel.net.cn> Message-ID: <481F4FD7.1000609@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hlwhyw@shtel.net.cn wrote: | Hi, all | | Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? | | I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? I think this is a complex issue, you'd better ask a lawyer who is an expert in copyright affairs. For pure 4.4-BSD Lite, the license is 4-clause BSD license, and the advertisement clause was removed exactly because FSF claims that it would prevent people from being able to combine BSD licensed code with GPL licensed ones, therefore, it is legal to combine 4.4-BSD Lite code with GPL code. However, it is illegal to change license, if you are not the sole copyright holder of the code. There is no point to do this anyway. On the other hand, why not just use some FreeBSD code for your product instead? Let us know if there is some limitation/lack of functionality? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgfT9cACgkQi+vbBBjt66D+8ACbB1VhjNZS8ZvJHr4TuuGQoVYS JGoAoLHukH9mq/hZP219La3jTtwp0CM4 =Aosf -----END PGP SIGNATURE----- From julian at elischer.org Mon May 5 18:22:23 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 5 18:22:27 2008 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? In-Reply-To: References: <424543f9f5.3f9f542454@shtel.net.cn> Message-ID: <481F505F.5010103@elischer.org> Kip Macy wrote: > On Sun, May 4, 2008 at 6:32 AM, wrote: >> Hi, all >> >> Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? >> >> I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? > > Yes. BSD licensed code can, by definition, be included in software > with any license. The only restriction is that you cannot change the > license of the code without permission of the copyright holder. > However, I see no reason to do that. so, the full answer is: From the BSD perspective, you can use the code as long as you don't change the copyright or say that you wrote it. We don't care what you link it with.. However from the GPL perspective, they will not let you link the BSD code with GPL code because they will not allow "additional limitations" and there is a clause in the BSD 4.4.-lite copyright that they consider to be an additional limitation. (The advertising clause). Some of the newer BSD code has dropped that clause and teh UC regents have announced they have released users from one of the clauses so it may be better to look at more up to date versions of the code. I do understand however that the original code is smaller and cleaner. > > -Kip > _______________________________________________ > 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 yusheng.huang at bluecoat.com Mon May 5 18:53:16 2008 From: yusheng.huang at bluecoat.com (Huang, Yusheng) Date: Mon May 5 18:53:21 2008 Subject: timewait state memory leak Message-ID: Hi, I am looking at the tcp_tw_2msl_scan() code and it looks like there is a bug in there. struct tcptw * tcp_tw_2msl_scan(int reuse) { struct tcptw *tw; INP_INFO_WLOCK_ASSERT(&tcbinfo); for (;;) { tw = TAILQ_FIRST(&twq_2msl); if (tw == NULL || (!reuse && tw->tw_time > ticks)) ^^^^^^^^^^^^^^^^^^ break; INP_WLOCK(tw->tw_inpcb); tcp_twclose(tw, reuse); if (reuse) return (tw); } return (NULL); } Shouldn't the comparison be TSTMP_GT(tw->tw_time, ticks)? -yusheng From Jinmei_Tatuya at isc.org Mon May 5 19:18:32 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Mon May 5 19:18:34 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <20080503100043.GA68835@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> Message-ID: At Sat, 3 May 2008 20:00:43 +1000, Edwin Groothuis wrote: > Before somebody shoots me down on it: I know that ipfw_divert() is > not suitable for IPv6 packets. [snip] > which is what I expected. So why doesn't this get displayed for the > IPv6 sockets? I don't know much about IPDIVERT, but it seems to me this is simply because the IPv6 stack (sys/netinet6) doesn't support divert sockets. So opening an AF_INET6 socket with the protocol being IPPROTO_DIVERT (which is "unknown") sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); matches a wildcard protosw /* raw wildcard */ { .pr_type = SOCK_RAW, .pr_domain = &inet6domain, .pr_flags = PR_ATOMIC|PR_ADDR, .pr_input = rip6_input, .pr_output = rip6_output, .pr_ctloutput = rip6_ctloutput, .pr_usrreqs = &rip6_usrreqs }, whose pr_protocol is implicitly set to 0, which is (accidentally) interpreted by lsof as "HOPOPTS". This should provide a direct answer to you question of "why"? But I suspect the underlying question is why divert sockets aren't supported for IPv6. I don't know why. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From oleksandr at samoylyk.sumy.ua Mon May 5 20:15:03 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Mon May 5 20:15:07 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481EEE34.7060804@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> <481EEE34.7060804@samoylyk.sumy.ua> Message-ID: <481F6AA8.60002@samoylyk.sumy.ua> Oleksandr Samoylyk wrote: > Jack Vogel wrote: >> Oh, I just had a thought, increase the RX processing limit, >> that only allows you to process 100 packets in one pass. >> >> First change it to 250 and see what it does, you might >> also set it to -1 which will allow you to process til you >> drain the ring, the risk is that you cause other problems >> by doing that, but heck at this point anything is worth >> trying, right? >> > > Nothing has helped. :( > > I need to unplug and plug in again patch cords each time when my CPUs > with emX go 100% in order to keep my server alive with a descent pings. > > I mentioned that "100%: emX taskq" occurs only on that interfaces where > GRE packets are being processed. > > External interface to Internet feels great. Pings are <0ms and load is > 9.57% with 14kpps (input/output). > > Maybe interesting: > According to kgmon: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 39.9 93.10 93.10 1643247 0.06 0.07 rip_input [10] > > Is it em related or mpd related or something else? > > Back to releng_6? Not sure though. :( > Now I'm on 6.3-STABLE: last pid: 31566; load averages: 7.61, 7.25, 7.07 up 0+01:34:00 22:30:05 82 processes: 10 running, 58 sleeping, 14 waiting CPU states: 0.2% user, 0.0% nice, 52.1% system, 47.8% interrupt, 0.0% idle Mem: 63M Active, 10M Inact, 152M Wired, 8K Cache, 35M Buf, 1752M Free Swap: 4011M Total, 4011M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 -44 -163 0K 8K WAIT 0 42:43 93.60% swi1: net 24 root 1 43 0 0K 8K CPU0 0 29:50 48.34% em0_rx_kthread_1 23 root 1 43 0 0K 8K RUN 0 29:50 46.78% em0_rx_kthread_0 28 root 1 43 0 0K 8K RORDER 1 3:30 2.25% em1_rx_kthread_0 29 root 1 43 0 0K 8K RUN 0 3:30 2.15% em1_rx_kthread_1 10 root 1 171 52 0K 8K RUN 1 11:22 0.00% idle: cpu1 11 root 1 171 52 0K 8K RUN 0 9:01 0.00% idle: cpu0 The results aren't good as well. -- Oleksandr Samoylyk OVS-RIPE From julian at elischer.org Mon May 5 20:15:29 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 5 20:15:33 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: References: <20080503100043.GA68835@k7.mavetju> Message-ID: <481F6AE1.5020408@elischer.org> JINMEI Tatuya / ???? wrote: > > This should provide a direct answer to you question of "why"? But I > suspect the underlying question is why divert sockets aren't supported > for IPv6. I don't know why. because no=one has done it and because divert sockaddrs are ipv4 sockaddrs you would have to make a new divert6 protocol. That's not impossible, but no-one has done it. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > 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 cswiger at mac.com Mon May 5 20:54:43 2008 From: cswiger at mac.com (Chuck Swiger) Date: Mon May 5 20:54:48 2008 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> References: <424543f9f5.3f9f542454@shtel.net.cn> Message-ID: <2CE7D37B-CC67-4732-9562-6B2ED0857854@mac.com> On May 4, 2008, at 6:32 AM, hlwhyw@shtel.net.cn wrote: > Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own > OS kernel which is GPL Licence? Modern 2- or 3-clause BSD licenses are fully compatible with the GPL, as are most "simple, permissive" licenses like the MIT/X11, Zlib, and similar licenses. The old 4-clause license with the "advertising clause" is not GPL-compatible. > I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD > Licenced code and change it to GPL licence? You are not allowed to remove the copyright statement or the original BSD license, but you can take BSD-licensed code and combine it with other software to create a derivative work which you then distribute under the GPL or even a proprietary license, if you wish. Eric Raymond and his wife, Catherine (who is a lawyer), have written some documentation about this specific issue here: http://catb.org/~esr/Licensing-HOWTO.html#id2787981 http://catb.org/~esr/Licensing-HOWTO.html#changing There was also a thread here: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:sss:15819:200804:ohmgonchmnecmnandlnk#b Regards, -- -Chuck From linimon at FreeBSD.org Mon May 5 23:05:00 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 5 23:05:04 2008 Subject: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 Message-ID: <200805052305.m45N50vT006133@freefall.freebsd.org> Synopsis: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 23:04:49 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123429 From edwin at mavetju.org Mon May 5 23:10:15 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Mon May 5 23:10:20 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <481F6AE1.5020408@elischer.org> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> Message-ID: <20080505231009.GX44028@k7.mavetju> On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: > >This should provide a direct answer to you question of "why"? But I > >suspect the underlying question is why divert sockets aren't supported > >for IPv6. I don't know why. > > because no=one has done it and because divert sockaddrs are ipv4 sockaddrs > > you would have to make a new divert6 protocol. > That's not impossible, but no-one has done it. I've been looking at it, with hints from rwatson@ and bms@, but the problem right now lays in the way you can do dynamic protocol registrations with IPv4 but not yet with IPv6. Every time when I get one step further I end up with a new problem :-( Let's call it a learning excercise! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From julian at elischer.org Mon May 5 23:18:55 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 5 23:19:00 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <20080505231009.GX44028@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> Message-ID: <481F95DE.6090201@elischer.org> Edwin Groothuis wrote: > On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: >>> This should provide a direct answer to you question of "why"? But I >>> suspect the underlying question is why divert sockets aren't supported >>> for IPv6. I don't know why. >> because no=one has done it and because divert sockaddrs are ipv4 sockaddrs >> >> you would have to make a new divert6 protocol. >> That's not impossible, but no-one has done it. > > I've been looking at it, with hints from rwatson@ and bms@, but the > problem right now lays in the way you can do dynamic protocol > registrations with IPv4 but not yet with IPv6. Every time when I > get one step further I end up with a new problem :-( > > Let's call it a learning excercise! > > Edwin you could implement a whole new protocol family of which there was a single protocol.. divert. so you would open a socket of type. sock = socket(PF_DIVERT, SOCK_RAW, DIVPROTO_6); instead of sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); From edwin at mavetju.org Mon May 5 23:59:02 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Mon May 5 23:59:06 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <481F95DE.6090201@elischer.org> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> Message-ID: <20080505235858.GB46427@k7.mavetju> On Mon, May 05, 2008 at 04:18:54PM -0700, Julian Elischer wrote: > Edwin Groothuis wrote: > >On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: > >>>This should provide a direct answer to you question of "why"? But I > >>>suspect the underlying question is why divert sockets aren't supported > >>>for IPv6. I don't know why. > >>because no=one has done it and because divert sockaddrs are ipv4 sockaddrs > >> > >>you would have to make a new divert6 protocol. > >>That's not impossible, but no-one has done it. > > > >I've been looking at it, with hints from rwatson@ and bms@, but the > >problem right now lays in the way you can do dynamic protocol > >registrations with IPv4 but not yet with IPv6. Every time when I > >get one step further I end up with a new problem :-( > > > >Let's call it a learning excercise! My adventures are written down at http://www.mavetju.org/weblog/html/00231.html > you could implement a whole new protocol family of which there > was a single protocol.. divert. > so you would open a socket of type. > > sock = socket(PF_DIVERT, SOCK_RAW, DIVPROTO_6); > instead of > > sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); Euhm... that would make my goal more noble but certainly near impossible for me. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From dengxf at gmail.com Tue May 6 06:11:30 2008 From: dengxf at gmail.com (Deng XueFeng) Date: Tue May 6 06:11:34 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: References: Message-ID: <20080506133208.C2EC.B627C632@gmail.com> hi I'am also meet this problem in my mss server(missey streaming server). one encoder push stream to mss, then run 100 client player playing the sream, as the client number increase, mss will occur this error sooner or later like this: I'am using kqueue, and will got a event with EV_EOF and fflags = ETIMEDOUT, if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), and the tcpdump also show that server will send RST packet to encoder. > Hello, > > I'm are having a trouble with TCP connections being dropped with "read: > Operation timed out". What is unusual is that this is happening right in > the middle of sending a steady stream of data with no network congestion. > > The system is FreeBSD 7 and a bespoke streaming server with 1Gbit > connection. The server receives a 192kbps inbound stream over TCP, and > broadcasts it over a large number of TCP streams. > > With no visible or obvious pattern, the inbound read() fails with > ETIMEDOUT. The likelihood of this happening seems to increase as the > number of audience connections increases. It's happens every few minutes > even with a small audience (eg. 300 outbound connections and about > 60mbit). > > It doesn't cough and splutter -- steady data is coming in, then it just > drops the connection. > > systat doesn't show problems inbound; all packets received are delivered > to the upper layer. But on outbound, there is consistent 'output drops': > > IP Output > 7028 total packets sent > 7028 - generated locally > 314 - output drops > > As the number of outbound connections increases, the 'output drops' > increases to around 10% of the total packets sent and maintains that > ratio. There's no problems with network capacity. > > I've tried different servers, different network interfaces (bge, em), > different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats > and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat > -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen > in a dedicated, uncontended test environment. > > Can anyone explain why the packets are being dropped outbound, and how > this could affect inbound TCP data in such an abrupt way? What can I do to > solve this? > > Thanks, > > Mark > _______________________________________________ > 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" -- Deng XueFeng From brde at optusnet.com.au Tue May 6 07:28:15 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Tue May 6 07:28:20 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Message-ID: <20080506164634.G10595@delplex.bde.org> On Mon, 5 May 2008, Alexander Sack wrote: > For my own edification, unless you specifically mark a function > inline, will gcc really optimize them out? That seems a little > overboard unless there is some compiler option that says its okay to > do that. I guess that would be very easy to test if you do as you > say, just sock away the function address pointer somewhere and you > should be okay... This is a regression in gcc-4. The -O option says it. -O implies -funit-at-a-time, which allows inlining of functions irrespective of their order within a file and implies -finline-functions-called-once. Thus even plain -O removes most static functions that are only called once. This doesn't seem to be the problem with the bce functions, since some of the missing ones are called more than once. -O2 seems to remove even more functions, but I'm not sure of the details. It is a regression in FreeBSD-5(?) to use -O2 by default for kernels. This used to give mainly bloat, but it now breaks debugging (including stack traces) and profiling unless full debugging symbols are available and used. Only gdb uses full debugging symbols AFAIK, and at least for old versions of gdb on objects generated with -g -O2, it doesn't handle even explicit inline functions quite right (both explicit and inline functions get replaced by non-call instructions instructions and by symbols to say where the function call was, and debuggers have a hard time making this look like a function call so that stepping over the function call works, especially when -O2 reorders everything). [Context lost to top posting.] Bruce From yonyossef.lists at gmail.com Tue May 6 07:45:13 2008 From: yonyossef.lists at gmail.com (Mr Y) Date: Tue May 6 07:45:24 2008 Subject: OS throws away large packets In-Reply-To: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com> References: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com> Message-ID: <20def4870805060045l2660b363o5c42631b706f61b6@mail.gmail.com> > > > >>> Hi all, > > >>> > > >>> I'm trying to implement Large Recieve Offload for an > > >>> > > >> Ethernet driver > > >> > > >>> on FreeBSD 6.3, but all my >MTU packets are being thrown > > by the OS. > > >>> I'm using mbuf chains in this imlpementation, each mbuf is > > >>> > > >> a cluster > > >> > > >>> of MCLBYTES bytes. They are linked by the m_next pointer. > > >>> The first packet being thrown away is 2945 bytes long. > > >>> > > >> Wireshark shows > > >> > > >>> the packet that is being passed to the OS is correct. > > >>> > > >>> Do I need to set some OS parameter to make it recieve mbuf chains? > > >>> > > >>> Please help. > > >>> > > >>> > > >> Hi Yony, > > >> > > >> I seem to remember some discussion about this list last > > year see the > > >> following threads: > > >> > > >> > > >> > > > > > > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm > l > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm > l > > > > > > >From my limited reading of these threads just now and possibly bad > > > memory. It would seem that the MRU to MTU relationship is > > defined in > > > the nic driver rather than > > > > > >> enforced further up the stack or at least that seamed to > > be the case > > >> > > > with the bce driver. > > > > > >> Hope this is helpful, > > >> > > >> Tom > > >> > > > > > > Hi Tom, > > > > > > >From what I understand these threads are referring to the bce > > > >hardware > > > configuration (bus configuration) and driver mbuf > > allocation size. Am > > > I correct? > > > In my case I'm not trying to receive packets >MTU from the > > HW, but to > > > chain mbuf clusters, each is MCLBYTES long, and pass the > > mbuf chain to > > > the OS. > > > Since tcpdump (analyzed by wireshark) catches the packets above the > > > driver and reports a good packet (and 2945 bytes long), I assume my > > > driver functionality is ok. From what I know tcpdump is supposed to > > > immitate the way the stack sees the packet, yet it is discarded. > > > My logic says there is an OS parameter handled by the > > driver (at net > > > device init time for example) that will set the OS to receive large > > > mbuf chains, or a kernel tcp parameter. Is the tcp stack > > submitted to > > > the mtu somehow? > > > > > > > > I don't see where you've identified what version of the os you're > > working with. There's a check in the 802.3 input path on earlier > > systems to discard frames >mtu. This was removed not too long ago > > with LRO in mind; check the history of sys/net/if_ethersubr.c. > > > > Sam > > > > Hi Sam, I have mentioned working on 6.3. > > FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: > > 539 if (m->m_pkthdr.len > > 540 ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { > 541 if_printf(ifp, "discard oversize frame " > 542 "(ether type %x flags %x len %u > > max %lu)\n", > 543 etype, m->m_flags, m->m_pkthdr.len, > 544 ETHER_MAX_FRAME(ifp, etype, > 545 m->m_flags & > M_HASFCS)); > 546 ifp->if_ierrors++; > 547 m_freem(m); > 548 return; > 549 } > > Patching it was explained by neterion in > http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD. > This check no longer exists in 6.3, nor any other oversize packet > handling (I couldn't find any so far). > I also get no error prints from the OS. > The problem was in my packet, after I put some traces in netinet/ip_input.c I found out my m_pkthdr.len was not properly updated. Thanks From martes at mgwigglesworth.com Tue May 6 11:56:22 2008 From: martes at mgwigglesworth.com (Martes G Wigglesworth) Date: Tue May 6 11:56:25 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Message-ID: <1210074903.8179.9.camel@localhost> I thought that the "inline" switch was specific to C++ and C and not gcc, hence the standard for the language says to add the inline parameter to explicitly produce optimized code. Unless gcc is not standard, I don't see why the compiler would automatically optimize the coded function to "inline." On Mon, 2008-05-05 at 14:06 -0400, Alexander Sack wrote: > For my own edification, unless you specifically mark a function > inline, will gcc really optimize them out? That seems a little > overboard unless there is some compiler option that says its okay to > do that. I guess that would be very easy to test if you do as you > say, just sock away the function address pointer somewhere and you > should be okay... > > -aps > > On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov wrote: > > > > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > > > Yes, I'm building a debug kernel. I have the line listed above as > > > > well > > > > > as the following: > > > > > > > > > > options KDB > > > > > options DDB > > > > > options GDB > > > > > options INVARIANTS > > > > > options INVARIANT_SUPPORT > > > > > options WITNESS > > > > > options WITNESS_SKIPSPIN > > > > > > > > Dave: > > > > > > > > What symbols can you not access exactly and how are you > > > > installing/setting up debugging? > > > > > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > > > without a problem. I can examine them and call them. I'm not using > > > > options GDB however, only KDB/DDB. > > > > > > > > I would: > > > > > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > > > generated/installed which contains the debug sections of your ko (from > > > > the objcopy calls during the build - the binary is stripped with a > > > > section pointer to the if_bce.ko.symbols file for debugging > > > > information I believe) > > > > - If you are using GDB, make sure its pointed to the right source base > > > > so it can retrieve symbol information correctly > > > > - If you are using GDB, stub it out and just use DDB to verify that > > > > your build is sane (it works for me!) > > > > - If all else fails, you can always build bce statically (just to move > > > > forward etc.) > > > > > > - Enable the kernel debugger as described above > > > - Build the driver in the /usr/src/sys/modules/bce directory with the > > > command "make". > > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > > > with the kernel module just built. > > > > > > In my case I only see a symbol for bce_dump_status_block, but there is a > > > second routine called bce_dump_stats_block. In my working build there > > > are 23 functions that start with "bce_dump" but only 8 are displayed with > > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > > > symbol not present error when I try to use any of those missing symbols > > > through a "call" command in the debugger. > > > > Most likely, they are optimized out, gcc likes to inline once-called > > static functions. Aside from playing with the optimization options, > > the easiest way seems to use functions somewhere else, e.g., put the > > addresses into some table. Just guessing. > > > _______________________________________________ > 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 oleksandr at samoylyk.sumy.ua Tue May 6 14:42:58 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 14:43:05 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <481E4ACC.1080106@gtcomm.net> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> <481E43DD.8080300@samoylyk.sumy.ua> <481E4ACC.1080106@gtcomm.net> Message-ID: <48206E43.2070808@samoylyk.sumy.ua> A bit experiments and it's was detected that it is a netgraph related problem. Whom can I address the problem? Thanks to Paul. -- Oleksandr Samoylyk OVS-RIPE From pisymbol at gmail.com Tue May 6 14:47:54 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue May 6 14:47:57 2008 Subject: Not All Symbols Present in a Loadable Kernel Module In-Reply-To: <20080506164634.G10595@delplex.bde.org> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> <20080506164634.G10595@delplex.bde.org> Message-ID: <3c0b01820805060747j79996b73n6cdb5fb87a368912@mail.gmail.com> On Tue, May 6, 2008 at 3:28 AM, Bruce Evans wrote: > On Mon, 5 May 2008, Alexander Sack wrote: > > For my own edification, unless you specifically mark a function > > inline, will gcc really optimize them out? That seems a little > > overboard unless there is some compiler option that says its okay to > > do that. I guess that would be very easy to test if you do as you > > say, just sock away the function address pointer somewhere and you > > should be okay... > > > > This is a regression in gcc-4. The -O option says it. -O implies > -funit-at-a-time, which allows inlining of functions irrespective of > their order within a file and implies -finline-functions-called-once. > Thus even plain -O removes most static functions that are only called > once. Thanks Bruce, I did some digging and all i can say is YIKES. Got to be careful with gcc optimizations. I suppose to be safe, bge could be compiled with -fno-inline-funcations-called-once to be safe. > This doesn't seem to be the problem with the bce functions, since some > of the missing ones are called more than once. Again, I would assume if you look at the symbols of the generated binary you should be able to figure out if you have a compiler issue or a debugger one! -aps From julian at elischer.org Tue May 6 15:04:54 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 6 15:04:59 2008 Subject: Troubles with em on FreeBSD 7 In-Reply-To: <48206E43.2070808@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> <481E43DD.8080300@samoylyk.sumy.ua> <481E4ACC.1080106@gtcomm.net> <48206E43.2070808@samoylyk.sumy.ua> Message-ID: <48207394.2090707@elischer.org> Oleksandr Samoylyk wrote: > A bit experiments and it's was detected that it is a netgraph related > problem. > > Whom can I address the problem? > > Thanks to Paul. > net@freebsd.org... send details and one of us will look at it.. From oleksandr at samoylyk.sumy.ua Tue May 6 15:58:50 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 15:58:53 2008 Subject: Problems with netgraph In-Reply-To: <48207C8B.4020509@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> Message-ID: <4820801A.90504@samoylyk.sumy.ua> Oleksandr Samoylyk wrote: > Dear developers, > > Please read this thread: > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html > > I'm using no encryption and no compression in mpd, so netgraph should fly. > It seems to get bad after 500 sessions... > > In FreeBSD 6 - it's swi1: net - 100% CPU > In FreeBSD 7 - it's em0 taskq - 100% CPU > > After playing with it I can make guess that's a netgraph problem. > > Maybe it's a poor design in netgraph the way it handle its tables and > it's is probably not designed to add so many interfaces. > > Might be there something in the source code I can edit to improve the > table lookups or hash table or whatever netgraph use to store and > process the node information and do the ppp/gre work. > I can also offer a shell access to server in order to investigate the problem. -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Tue May 6 16:01:15 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 16:01:19 2008 Subject: Problems with netgraph Message-ID: <48207C8B.4020509@samoylyk.sumy.ua> Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Tue May 6 17:53:25 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 17:53:28 2008 Subject: Problems with netgraph In-Reply-To: <4820801A.90504@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <4820801A.90504@samoylyk.sumy.ua> Message-ID: <482099CE.5050802@samoylyk.sumy.ua> Oleksandr Samoylyk ?????: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. >> >> Might be there something in the source code I can edit to improve the >> table lookups or hash table or whatever netgraph use to store and >> process the node information and do the ppp/gre work. >> > > I can also offer a shell access to server in order to investigate the > problem. > # ngctl list ngctl: send msg: No buffer space available However: kern.ipc.maxpipekva="400000000" net.graph.maxalloc="8192" net.graph.maxdgram="256000" net.graph.recvspace="256000" -- Oleksandr Samoylyk OVS-RIPE From julian at elischer.org Tue May 6 18:08:08 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 6 18:08:15 2008 Subject: Problems with netgraph In-Reply-To: <48207C8B.4020509@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> Message-ID: <48209BC4.5080602@elischer.org> Oleksandr Samoylyk wrote: > Dear developers, > > Please read this thread: > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html > > I'm using no encryption and no compression in mpd, so netgraph should fly. > It seems to get bad after 500 sessions... > > In FreeBSD 6 - it's swi1: net - 100% CPU > In FreeBSD 7 - it's em0 taskq - 100% CPU unfortunatly I've been totally ignoring this thread because it said "trouble with em" in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. > > After playing with it I can make guess that's a netgraph problem. > > Maybe it's a poor design in netgraph the way it handle its tables and > it's is probably not designed to add so many interfaces. how many? > > Might be there something in the source code I can edit to improve the > table lookups or hash table or whatever netgraph use to store and > process the node information and do the ppp/gre work. netgraph just had some work done on it for this exact reason, but you may be jumping the gun a bit.. > From oleksandr at samoylyk.sumy.ua Tue May 6 18:33:51 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 18:33:53 2008 Subject: Problems with netgraph In-Reply-To: <48209BC4.5080602@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> Message-ID: <4820A47D.8010404@samoylyk.sumy.ua> Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said > trouble with mpd then maybe I'd have looked earlier.. > >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. > > how many? more than 2500 >> Might be there something in the source code I can edit to improve the >> table lookups or hash table or whatever netgraph use to store and >> process the node information and do the ppp/gre work. > > netgraph just had some work done on it for this exact reason, > but you may be jumping the gun a bit.. > >> > -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Tue May 6 19:43:44 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Tue May 6 19:43:48 2008 Subject: Problems with netgraph In-Reply-To: <48209BC4.5080602@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> Message-ID: <4820B4DD.80105@samoylyk.sumy.ua> Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said > trouble with mpd then maybe I'd have looked earlier.. > >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. > > how many? > # vmstat -m | grep netgraph netgraph_msg 0 0K - 1355522 64,128,256,512,1024 netgraph_node 12110 3028K - 28829 256 netgraph_hook 29648 3706K - 66104 128 netgraph 8076 12663K - 15209 64,256,1024,4096 netgraph_sock 4 1K - 5489 128 netgraph_path 1 1K - 728112 16,32 netgraph_mppc 0 0K - 1 1024 netgraph_ksock 1349 169K - 3414 128 netgraph_iface 1346 169K - 2367 128 netgraph_ppp 1346 16152K - 2367 netgraph_bpf 16020 2003K - 33296 128 # ifconfig -a | grep ng | wc -l 1341 I saw a peak with about 1900 ng interfaces. That was tooo sloowwww.... last pid: 39304; load averages: 1.12, 1.23, 1.20 up 0+01:15:38 22:39:04 93 processes: 10 running, 70 sleeping, 13 waiting CPU states: 0.3% user, 0.0% nice, 15.3% system, 3.1% interrupt, 81.3% idle Mem: 46M Active, 7772K Inact, 109M Wired, 128K Cache, 16M Buf, 7756M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 819 root 23 50 0 92764K 36424K select 1 0:00 207.18% mpd5 17 root 1 171 ki31 0K 16K RUN 1 71:41 100.00% idle: cpu1 14 root 1 171 ki31 0K 16K CPU4 4 69:16 100.00% idle: cpu4 15 root 1 171 ki31 0K 16K CPU3 3 68:11 100.00% idle: cpu3 29 root 1 -68 - 0K 16K CPU6 6 60:50 100.00% em0 taskq 18 root 1 171 ki31 0K 16K CPU0 0 71:58 97.17% idle: cpu0 16 root 1 171 ki31 0K 16K CPU2 2 68:13 95.65% idle: cpu2 11 root 1 171 ki31 0K 16K CPU7 7 66:23 86.38% idle: cpu7 13 root 1 171 ki31 0K 16K CPU5 5 65:28 71.97% idle: cpu5 19 root 1 -44 - 0K 16K WAIT 5 19:53 31.59% swi1: net 30 root 1 -68 - 0K 16K - 7 8:41 12.89% em1 taskq 12 root 1 171 ki31 0K 16K RUN 6 12:41 0.00% idle: cpu6 20 root 1 -32 - 0K 16K WAIT 3 1:12 0.00% swi4: clock # uname -v FreeBSD 7.0-STABLE #0: Mon May 5 01:11:23 EEST 2008 CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2000.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e33d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs usable memory = 8580038656 (8182 MB) avail memory = 8292810752 (7908 MB) # ngctl list ngctl: send msg: No buffer space available # cat /boot/loader.conf loader_logo="beastie" autoboot_delay="3" hw.em.rxd="1024" hw.em.txd="1024" net.inet.tcp.tcbhashsize="4096" kern.ipc.maxpipekva="32000000" net.graph.recvspace="128000" net.graph.maxdgram="128000" Linux with poptop was running quit smoothly. I thought that netgraph would be fast as hell. -- Oleksandr Samoylyk OVS-RIPE From bzeeb-lists at lists.zabbadoz.net Tue May 6 20:35:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 6 20:35:10 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <4816D1D2.7010603@elischer.org> References: <4816D1D2.7010603@elischer.org> Message-ID: <20080506202940.K47338@maildrop.int.zabbadoz.net> On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, > The patch can be found at > http://www.freebsd.org/~julian/mrt.diff > (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > > or source can be taken from perforce at: > //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, ..)? + * For now the protocol indepedent versions are the same as the AF_INET ones + * but this will change.. just #define them at this time. + */ +#define in_rt_getifa(_a, _b) rt_getifa_fib(_a, _b) +#define in_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) +#define in_rtalloc(_a, _b) rtalloc_fib(_a, _b) +#define in_rtalloc1(_a, _b, _c, _d) rtalloc1_fib(_a, _b, _c, _d) +#define in_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) +#define in_rtredirect(_a, _b, _c, _d, _e, _f) \ + rtredirect_fib(_a, _b, _c, _d, _e, _f) +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ + rtrequest_fib(_a, _b, _c, _d, _e, _f,_g) +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, _c, _d) +#define in_rt_check(_a, _b, _c, _d) rt_check_fib(_a, _b, _c, _d) The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Tue May 6 21:08:32 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 6 21:08:37 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <20080506202940.K47338@maildrop.int.zabbadoz.net> References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> Message-ID: <4820C8CE.8010309@elischer.org> Bjoern A. Zeeb wrote: > On Tue, 29 Apr 2008, Julian Elischer wrote: > > Hi, > >> The patch can be found at >> http://www.freebsd.org/~julian/mrt.diff >> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >> >> or source can be taken from perforce at: >> //depot/user/julian/routing/src > > So after looking at the patch a bit more again, could you add wrapper > functions for those like you have done for the old KPI (rtrequest, > rtrequest1, do you really want to do the extra work instructions? > ..)? > > + * For now the protocol indepedent versions are the same as the AF_INET > ones > + * but this will change.. just #define them at this time. > + */ > +#define in_rt_getifa(_a, _b) rt_getifa_fib(_a, _b) > +#define in_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) > +#define in_rtalloc(_a, _b) rtalloc_fib(_a, _b) > +#define in_rtalloc1(_a, _b, _c, _d) rtalloc1_fib(_a, _b, _c, _d) > +#define in_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) > +#define in_rtredirect(_a, _b, _c, _d, _e, _f) \ > + rtredirect_fib(_a, _b, _c, _d, > _e, _f) > +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ > + rtrequest_fib(_a, _b, _c, _d, > _e, _f,_g) > +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, > _c, _d) > +#define in_rt_check(_a, _b, _c, _d) rt_check_fib(_a, _b, _c, > _d) > > > The defines will not give you a stable KPI and having that changed again > if you are going with a prefix for each AF would be a pain if the _fib > versions > are going to change in the future. hmm fair enough... but let me outline my plans and thoughts so we can see if you still want this.. In order to get away from having every protocol (existing or not) from preallocating N fib heads (currently it is done in protocol independent code) the protocols themselves need to know if they are allocating multiple FIBS and how many. For this reason, the protocol versions will eventually know where their own fibs are stored and act on them as needed, allowing them to be dynamically allocated. (as many as needed). The methods for each protocol family woudl be pointed to in the domain structure, and the protocol independent versions would look them up that way and call them.. so the domain structure would include: struct domain { [...] *(struct rtentry *dom_rtalloc)(mumble); [...] }; (or whatever the syntax is (I always have to look it up) in netinet we would declare struct domain inet_domain = { [...] in_rtalloc, [...] ]; A new function find_domain(family) makes a method independent way to find the domain structure for any given PF/AF. So rtalloc_fib would be: struct rtentry * rtalloc_fib( struct route *ro, int fib) { struct domain *dp; dp = find_domain(ro->ro_dst.sa_family) if (dp) return (*(dp->dom_rtalloc)(ro, fib)); return (NULL); } This all however is not ABI compatible so could not go back to 7.x and I want to check in an initial version that can go back to 7.x which sort of suggests to me that adding in_xxx functions is not really required, until I do the next step. 7.x will never get the next step. because the ABI is already set in stone for 7.x. I would make the in_xxx stubs in the next step in 8.x. after the MFC to 7.x of the ABI compat version. let me know what you think. From fox at verio.net Wed May 7 04:41:09 2008 From: fox at verio.net (David DeSimone) Date: Wed May 7 04:41:13 2008 Subject: Problems with netgraph In-Reply-To: <48209BC4.5080602@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> Message-ID: <20080507040727.GA28983@verio.net> Julian Elischer wrote: > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said "trouble with mpd" then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 From bms at incunabulum.net Wed May 7 04:41:54 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Wed May 7 04:41:58 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <481F95DE.6090201@elischer.org> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> Message-ID: <4821330E.8030101@incunabulum.net> Julian Elischer wrote: > you could implement a whole new protocol family of which there > was a single protocol.. divert. That's sheer overkill for what Edwin needs to be able to do. We already have a bunch of apps which use divert sockets in the IPv4 space, why should the existing semantics change? Divert sockets are still tied to the transport you instantiate them with, and they have always been a special case anyway depending on where one wishes to draw the lines. There is no reason per se, that I can see, why the IPPROTO_DIVERT identifier can't just be re-used along with pf_proto_register() for PF_INET6, and I've said this to Edwin off-list. A PROTO_SPACER entry just needs to be added to in6protosw. I was surprised to learn no-one had gone ahead and actually implemented it already as there are a few cases in IPv6 which might warrant it (6to4, Teredo etc.) If I'm missing anything obvious please let me know. cheers BMS From julian at elischer.org Wed May 7 06:59:39 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 7 06:59:44 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <4821330E.8030101@incunabulum.net> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> Message-ID: <4821535B.8050001@elischer.org> Bruce M. Simpson wrote: > Julian Elischer wrote: >> you could implement a whole new protocol family of which there >> was a single protocol.. divert. > That's sheer overkill for what Edwin needs to be able to do. We already > have a bunch of apps which use divert sockets in the IPv4 space, why > should the existing semantics change? Divert sockets are still tied to > the transport you instantiate them with, and they have always been a > special case anyway depending on where one wishes to draw the lines. > > There is no reason per se, that I can see, why the IPPROTO_DIVERT > identifier can't just be re-used along with pf_proto_register() for > PF_INET6, and I've said this to Edwin off-list. A PROTO_SPACER entry > just needs to be added to in6protosw. > > I was surprised to learn no-one had gone ahead and actually implemented > it already as there are a few cases in IPv6 which might warrant it > (6to4, Teredo etc.) If I'm missing anything obvious please let me know. > > cheers > BMS actually the divert sockets should really not be in PF_INET they could deliver both inet and inet6 packets. the sockaddr that they return (and which needs to be read for divert to make sense) could be used to distinguish between them. From oleksandr at samoylyk.sumy.ua Wed May 7 07:15:35 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 07:15:39 2008 Subject: Problems with netgraph In-Reply-To: <20080507040727.GA28983@verio.net> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> Message-ID: <48215706.8080508@samoylyk.sumy.ua> David DeSimone wrote: > Julian Elischer wrote: >> unfortunatly I've been totally ignoring this thread because it said >> "trouble with em" in the topic.. >> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. > > In the poster's defense, the only symptom that started this was this > info from ps: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > > So tracking it down to mpd has been a process of elimination in figuring > out why packets absorb so much CPU. > Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html -- Oleksandr Samoylyk OVS-RIPE From alex.wilkinson at dsto.defence.gov.au Wed May 7 07:24:57 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed May 7 07:25:01 2008 Subject: Fwd: [networking-discuss] uperf - A network benchmark tool Message-ID: <20080507070905.GR77510@stlux503.dsto.defence.gov.au> FYI ----- Forwarded message from Neelakanth Nadgir ----- Date: Tue, 06 May 2008 17:34:23 -0700 From: Neelakanth Nadgir To: networking-discuss@opensolaris.org Cc: Neelakanth Nadgir Subject: [networking-discuss] uperf - A network benchmark tool [apologies if you received duplicates] Folks, we just opensourced (under GPL v3) a network benchmarking tool called uperf at http://www.uperf.org. I encourage you to check it out. uperf (just like filebench) takes a description of the networking component of workloads and replays it. Using a "model" allows you to change different parameters (like scale, protocol, etc..) and analyze performance. I hope you find it useful. Uperf is work in progress and we are adding more functionality. If you would like to contribute, please feel free so; we can use all the help. thanks, -neel -- --- Neelakanth Nadgir http://blogs.sun.com/realneel _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org ----- End forwarded message ----- IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From bms at incunabulum.net Wed May 7 07:41:00 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Wed May 7 07:41:04 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <4821535B.8050001@elischer.org> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> Message-ID: <48215D08.5050500@incunabulum.net> Julian Elischer wrote: > actually the divert sockets should really not be in PF_INET > they could deliver both inet and inet6 packets. > the sockaddr that they return (and which needs to be read for divert > to make sense) could be used to distinguish between them. Good point. I'd forgotten that they were abusing the fields in sin_zero. This is not OK for IPv6, although the kludge can still be perpetuated by looking at sa_len and stashing what divert wants at the end of sockaddr_in6. So there IS a case for making them a separate protocol family if someone's going to do a clean implementation of divert sockets for IPv6. cheers BMS From bzeeb-lists at lists.zabbadoz.net Wed May 7 08:05:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed May 7 08:05:11 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <4820C8CE.8010309@elischer.org> References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> <4820C8CE.8010309@elischer.org> Message-ID: <20080507074647.B47338@maildrop.int.zabbadoz.net> On Tue, 6 May 2008, Julian Elischer wrote: Hi, > Bjoern A. Zeeb wrote: >> On Tue, 29 Apr 2008, Julian Elischer wrote: >> >> Hi, >> >>> The patch can be found at >>> http://www.freebsd.org/~julian/mrt.diff >>> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >>> >>> or source can be taken from perforce at: >>> //depot/user/julian/routing/src >> >> So after looking at the patch a bit more again, could you add wrapper >> functions for those like you have done for the old KPI (rtrequest, >> rtrequest1, > > do you really want to do the extra work instructions? > ... >> >> The defines will not give you a stable KPI and having that changed again >> if you are going with a prefix for each AF would be a pain if the _fib >> versions >> are going to change in the future. > > hmm fair enough... but let me outline my plans and thoughts > so we can see if you still want this.. > [ ... ] > > This all however is not ABI compatible so could not go back to 7.x > and I want to check in an initial version that can go back to 7.x > which sort of suggests to me that adding in_xxx functions is > not really required, until I do the next step. > 7.x will never get the next step. because the ABI is already set > in stone for 7.x. > > I would make the in_xxx stubs in the next step in 8.x. > after the MFC to 7.x of the ABI compat version. > > > let me know what you think. Leaving aside any upcoming enhancement if what we have now is what is going into 7 and possibly 6 we should do the wrapper functions. The point is RELENG_7 will live for $(last release + 2 years) so I guess till 2011 or maybe later. No idea what would happen there in all that time. If people start adding support for other AFs we cannot say that the *_fib variants are not going to change so having the in_* stable sounds like a good thing for 6 and 7. Am I missing anything obvious? I don't mind if they are going to significantly change again in 8 a few weeks later. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Wed May 7 18:05:13 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 7 18:05:17 2008 Subject: Problems with netgraph In-Reply-To: <48215706.8080508@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> Message-ID: <4821EF57.9010600@elischer.org> Oleksandr Samoylyk wrote: > David DeSimone wrote: >> Julian Elischer wrote: >>> unfortunatly I've been totally ignoring this thread because it said >>> "trouble with em" in the topic.. >>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >> >> In the poster's defense, the only symptom that started this was this >> info from ps: >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 >> taskq >> >> So tracking it down to mpd has been a process of elimination in figuring >> out why packets absorb so much CPU. >> > > Here is a result of profiling: > > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html > 0.00 0.00 16/1643247 igmp_input [833] 0.03 0.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10] 49.8 93.10 17.27 1643247 rip_input [10] 14.26 0.88 600796/749987 _mtx_lock_sleep [21] 0.16 1.70 1643863/1643863 raw_append [93] 0.00 0.24 36345/176995 _mtx_unlock_sleep [114] 0.01 0.00 1643863/5117962 jailed [278] 0.00 0.00 1292/1843 m_copym [666] 0.00 0.00 676/8214484 m_freem [34] 50% of time in rip_input??? that's unexpected.. what is the traffic? also: I see no netgraph in the profile at all. did you statically compile it all in at compile time? (you should if you want to see it) From julian at elischer.org Wed May 7 18:08:03 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 7 18:08:09 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <48215D08.5050500@incunabulum.net> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> Message-ID: <4821F001.10208@elischer.org> Bruce M. Simpson wrote: > Julian Elischer wrote: >> actually the divert sockets should really not be in PF_INET >> they could deliver both inet and inet6 packets. >> the sockaddr that they return (and which needs to be read for divert >> to make sense) could be used to distinguish between them. > > Good point. I'd forgotten that they were abusing the fields in sin_zero. "they" == "me" :-) if we made it its own protocol family we could define our own sockaddr types too and have actual fields for that stuff... > This is not OK for IPv6, although the kludge can still be perpetuated by > looking at sa_len and stashing what divert wants at the end of > sockaddr_in6. > > So there IS a case for making them a separate protocol family if > someone's going to do a clean implementation of divert sockets for IPv6. > > cheers > BMS From oleksandr at samoylyk.sumy.ua Wed May 7 18:16:54 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 18:16:57 2008 Subject: Problems with netgraph In-Reply-To: <4821EF57.9010600@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> Message-ID: <4821F206.10606@samoylyk.sumy.ua> Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> David DeSimone wrote: >>> Julian Elischer wrote: >>>> unfortunatly I've been totally ignoring this thread because it said >>>> "trouble with em" in the topic.. >>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>> >>> In the poster's defense, the only symptom that started this was this >>> info from ps: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>> COMMAND >>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>> em0 taskq >>> >>> So tracking it down to mpd has been a process of elimination in figuring >>> out why packets absorb so much CPU. >>> >> >> Here is a result of profiling: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >> > > > 0.00 0.00 16/1643247 igmp_input [833] > 0.03 0.01 614/1643247 icmp_input [272] > 93.07 17.27 1642617/1643247 encap4_input [9] > [10] 49.8 93.10 17.27 1643247 rip_input [10] > 14.26 0.88 600796/749987 _mtx_lock_sleep [21] > 0.16 1.70 1643863/1643863 raw_append [93] > 0.00 0.24 36345/176995 _mtx_unlock_sleep > [114] > 0.01 0.00 1643863/5117962 jailed [278] > 0.00 0.00 1292/1843 m_copym [666] > 0.00 0.00 676/8214484 m_freem [34] > > > > 50% of time in rip_input??? > > that's unexpected.. what is the traffic? more than 20k pps # netstat -I em0 -w 1 input (em0) output packets errs bytes packets errs bytes colls 22247 0 10767499 21079 0 13741924 0 21356 0 10535580 20288 0 13014669 0 21871 0 10565622 20586 0 13165147 0 21894 0 10495771 20964 0 13806336 0 21303 0 10496544 19682 0 12659588 0 21643 0 10561207 20140 0 12692946 0 21534 0 10304466 20289 0 13460444 0 ^C > also: > > I see no netgraph in the profile at all. > did you statically compile it all in at compile time? (you should if you > want to see it) > Tried both variants. Now not statically. -- Oleksandr Samoylyk OVS-RIPE From julian at elischer.org Wed May 7 19:41:45 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 7 19:41:49 2008 Subject: Problems with netgraph In-Reply-To: <4821F206.10606@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> Message-ID: <482205F7.4010503@elischer.org> Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> Oleksandr Samoylyk wrote: >>> David DeSimone wrote: >>>> Julian Elischer wrote: >>>>> unfortunatly I've been totally ignoring this thread because it said >>>>> "trouble with em" in the topic.. >>>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>>> >>>> In the poster's defense, the only symptom that started this was this >>>> info from ps: >>>> >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>> COMMAND >>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>> em0 taskq >>>> >>>> So tracking it down to mpd has been a process of elimination in >>>> figuring >>>> out why packets absorb so much CPU. >>>> >>> >>> Here is a result of profiling: >>> >>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>> >> >> >> 0.00 0.00 16/1643247 igmp_input [833] >> 0.03 0.01 614/1643247 icmp_input [272] >> 93.07 17.27 1642617/1643247 encap4_input [9] >> [10] 49.8 93.10 17.27 1643247 rip_input [10] >> 14.26 0.88 600796/749987 _mtx_lock_sleep >> [21] >> 0.16 1.70 1643863/1643863 raw_append [93] >> 0.00 0.24 36345/176995 _mtx_unlock_sleep >> [114] >> 0.01 0.00 1643863/5117962 jailed [278] >> 0.00 0.00 1292/1843 m_copym [666] >> 0.00 0.00 676/8214484 m_freem [34] >> >> >> >> 50% of time in rip_input??? >> >> that's unexpected.. what is the traffic? > > > more than 20k pps I mean, what KIND of traffic? I'm surprised it 's calling rip_input().. why is it calling encap4_input()? (which calls rip_input).. what is the IP protocol of all these packets? what does a small snippet of traffic show? (tcpdump -i em0 -s0 -e -n -c 64) > >> I see no netgraph in the profile at all. >> did you statically compile it all in at compile time? (you should if >> you want to see it) >> > > Tried both variants. Now not statically. make sure it is static and that the netgraph nodes are all compiled with -pg > From oleksandr at samoylyk.sumy.ua Wed May 7 19:46:04 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 19:46:08 2008 Subject: Problems with netgraph In-Reply-To: <482205F7.4010503@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> Message-ID: <482206EE.2050904@samoylyk.sumy.ua> Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> Oleksandr Samoylyk wrote: >>>> David DeSimone wrote: >>>>> Julian Elischer wrote: >>>>>> unfortunatly I've been totally ignoring this thread because it said >>>>>> "trouble with em" in the topic.. >>>>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>>>> >>>>> In the poster's defense, the only symptom that started this was this >>>>> info from ps: >>>>> >>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>> COMMAND >>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>>> em0 taskq >>>>> >>>>> So tracking it down to mpd has been a process of elimination in >>>>> figuring >>>>> out why packets absorb so much CPU. >>>>> >>>> >>>> Here is a result of profiling: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>> >>> >>> >>> 0.00 0.00 16/1643247 igmp_input [833] >>> 0.03 0.01 614/1643247 icmp_input [272] >>> 93.07 17.27 1642617/1643247 encap4_input [9] >>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>> 14.26 0.88 600796/749987 _mtx_lock_sleep >>> [21] >>> 0.16 1.70 1643863/1643863 raw_append [93] >>> 0.00 0.24 36345/176995 _mtx_unlock_sleep >>> [114] >>> 0.01 0.00 1643863/5117962 jailed [278] >>> 0.00 0.00 1292/1843 m_copym [666] >>> 0.00 0.00 676/8214484 m_freem [34] >>> >>> >>> >>> 50% of time in rip_input??? >>> >>> that's unexpected.. what is the traffic? >> >> >> more than 20k pps > > I mean, what KIND of traffic? > I'm surprised it 's calling rip_input().. why is it calling > encap4_input()? (which calls rip_input).. what is the IP protocol > of all these packets? > > what does a small snippet of traffic show? > > (tcpdump -i em0 -s0 -e -n -c 64) GRE (pptp-tunnels) tcpdump -i em0 -s0 -e -n -c 64 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P 3482978131:3482978327(196) ack 537019550 win 128 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) ack 239105401 win 58593 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 195.91.147.100.62073 > 77.120.205.18.43463: . 2979675127:2979676487(1360) ack 3166103641 win 65212 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 win 17680 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack 1841830, no-payload, proto PPP (0x880b), length 12 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) ack 3056545326 win 32254 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 win 65212 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack 1687270, no-payload, proto PPP (0x880b), length 12 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: seq 0x039, Flags [begin], length 1400 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq 0x039, Flags [end], length 9 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) ack 1774495680 win 16384 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack 337838744 win 6970 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . 2176487112:2176488472(1360) ack 921656808 win 16446 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win 16446 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack 145663, no-payload, proto PPP (0x880b), length 12 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) ack 1545362008 win 65535 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack 145664, no-payload, proto PPP (0x880b), length 12 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win 32502 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 >> >>> I see no netgraph in the profile at all. >>> did you statically compile it all in at compile time? (you should if >>> you want to see it) >>> >> >> Tried both variants. Now not statically. > > make sure it is static and that the netgraph nodes are all compiled with > -pg > I'll try, but a bit later. -- Oleksandr Samoylyk OVS-RIPE From julian at elischer.org Wed May 7 19:58:31 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 7 19:58:38 2008 Subject: Problems with netgraph In-Reply-To: <482206EE.2050904@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> Message-ID: <482209E5.7010607@elischer.org> Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> Oleksandr Samoylyk wrote: >>> Julian Elischer wrote: >>>> Oleksandr Samoylyk wrote: >>>>> David DeSimone wrote: >>>>>> Julian Elischer wrote: >>>>>>> unfortunatly I've been totally ignoring this thread because it said >>>>>>> "trouble with em" in the topic.. >>>>>>> If you'd said "trouble with mpd" then maybe I'd have looked >>>>>>> earlier.. >>>>>> >>>>>> In the poster's defense, the only symptom that started this was this >>>>>> info from ps: >>>>>> >>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>>> COMMAND >>>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>>>> em0 taskq >>>>>> >>>>>> So tracking it down to mpd has been a process of elimination in >>>>>> figuring >>>>>> out why packets absorb so much CPU. >>>>>> >>>>> >>>>> Here is a result of profiling: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>>> >>>> >>>> >>>> 0.00 0.00 16/1643247 igmp_input [833] >>>> 0.03 0.01 614/1643247 icmp_input [272] >>>> 93.07 17.27 1642617/1643247 encap4_input [9] >>>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>>> 14.26 0.88 600796/749987 >>>> _mtx_lock_sleep [21] >>>> 0.16 1.70 1643863/1643863 raw_append [93] >>>> 0.00 0.24 36345/176995 _mtx_unlock_sleep >>>> [114] >>>> 0.01 0.00 1643863/5117962 jailed [278] >>>> 0.00 0.00 1292/1843 m_copym [666] >>>> 0.00 0.00 676/8214484 m_freem [34] >>>> >>>> >>>> >>>> 50% of time in rip_input??? >>>> >>>> that's unexpected.. what is the traffic? >>> >>> >>> more than 20k pps >> >> I mean, what KIND of traffic? >> I'm surprised it 's calling rip_input().. why is it calling >> encap4_input()? (which calls rip_input).. what is the IP protocol >> of all these packets? >> >> what does a small snippet of traffic show? >> >> (tcpdump -i em0 -s0 -e -n -c 64) > > > GRE (pptp-tunnels) > > tcpdump -i em0 -s0 -e -n -c 64 > > 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P > 3482978131:3482978327(196) ack 537019550 win 128 > 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq > 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) > ack 239105401 win 58593 > 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq > 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 195.91.147.100.62073 > 77.120.205.18.43463: . > 2979675127:2979676487(1360) ack 3166103641 win 65212 > 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq > 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length > 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 win > 17680 > 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq > 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593 > 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack > 1841830, no-payload, proto PPP (0x880b), length 12 > 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq > 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) > ack 3056545326 win 32254 > 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq > 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 win > 65212 > 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq > 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: > 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 > 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq > 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length > 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 > 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack > 1687270, no-payload, proto PPP (0x880b), length 12 > 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq > 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: > 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 > 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq > 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: > seq 0x039, Flags [begin], length 1400 > 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq > 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq > 0x039, Flags [end], length 9 > 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq > 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: > 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) ack > 1774495680 win 16384 > 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq > 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: > 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack > 337838744 win 6970 > 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq > 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), length > 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . > 2176487112:2176488472(1360) ack 921656808 win 16446 > 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq > 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win 16446 > 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack > 145663, no-payload, proto PPP (0x880b), length 12 > 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq > 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) ack > 1545362008 win 65535 > 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack > 145664, no-payload, proto PPP (0x880b), length 12 > 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq > 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 > 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq > 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: > 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win 32502 > > 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq > 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length > 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 > 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 > >>> >>>> I see no netgraph in the profile at all. >>>> did you statically compile it all in at compile time? (you should if >>>> you want to see it) >>>> >>> >>> Tried both variants. Now not statically. >> >> make sure it is static and that the netgraph nodes are all compiled >> with -pg >> > > I'll try, but a bit later. ok so we get somewhere.. GRE.. looks like UDP in PPP in GRE is this a pptp session? this may be the issue: http://www.nabble.com/GRE-Mux-td16201899.html > From ml at netfence.it Wed May 7 20:03:36 2008 From: ml at netfence.it (Andrea Venturoli) Date: Wed May 7 20:04:11 2008 Subject: Routing problem with aliases Message-ID: <48220305.7010605@netfence.it> Hello. A box of mine has an interface configured with two IPs on two different nets: # ifconfig xl0: flags=8943 mtu 1500 options=9 inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:50:da:77:5f:79 media: Ethernet autoselect (100baseTX ) status: active Then I have two gateways: 192.168.2.1 and 192.168.0.6. "ping 192.168.2.1" works correctly (source address 192.168.2.2 is used) "ping 192.168.0.6" also does (source address 192.168.0.2 is used) Setting 192.168.2.1 as my default gateway allows me to ping any host on the Internet (again source address 192.168.2.2 is used). However, if I set 192.168.0.6 as the default router, I can't reach the Internet, since it uses source address 192.168.2.2 and the next router won't obviously like it. Is this normal behaviour? Anything to set or check? Any other hint? Perhaps I should mention that I also have some carp devices on that interface, but I'm not sure whether it matters. bye & Thanks av. From vwe at FreeBSD.org Wed May 7 20:37:17 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed May 7 20:37:21 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN Message-ID: <200805072037.m47KbGc6044521@freefall.freebsd.org> Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed May 7 20:33:44 UTC 2008 State-Changed-Why: It appears there's no PHY attached but from your dmesg I would expect bge0 to cause trouble. Can you please post output of `pciconf -lv | grep -A 3 bge'? I think the -net maintainers will be able to see the relevant pieces from that output. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From vwe at FreeBSD.org Wed May 7 21:00:41 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed May 7 21:00:53 2008 Subject: kern/123463: [panic] repeatable crash related to ipsec-tools Message-ID: <200805072100.m47L0fAj045206@freefall.freebsd.org> Old Synopsis: repeatable crash related to ipsec-tools New Synopsis: [panic] repeatable crash related to ipsec-tools Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 21:00:12 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123463 From adam at mhm.lv Wed May 7 21:01:25 2008 From: adam at mhm.lv (adam@mhm.lv) Date: Wed May 7 21:01:53 2008 Subject: Fw: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN Message-ID: <00ad01c8b085$815e77d0$55275150@homee7979e67c1> As a follow-up to my previous output, this is also my custom kernel, just in case: #---------------------------------------------------------------------------------------- # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # FreeBSD 6.3-RELEASE # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.14.2.1 2007/12/15 06:32:32 scottl Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident GBRT2 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. #To make an SMP kernel, the next two are required options SMP device apic # I/O APIC #IPFIREWALL options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options DUMMYNET options HZ=2000 # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals #device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse #device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #----------------------------------------------------------------------------- ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, May 07, 2008 11:44 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > Sure! Here you are! > > GBRT2# pciconf -lv | grep -A 3 bge > bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' > class = network > -- > bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' > class = network > GBRT2# > > ----- Original Message ----- > From: > To: ; ; ; > > Sent: Wednesday, May 07, 2008 11:37 PM > Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate > changed to DOWN > > >> Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN >> >> State-Changed-From-To: open->feedback >> State-Changed-By: vwe >> State-Changed-When: Wed May 7 20:33:44 UTC 2008 >> State-Changed-Why: >> >> It appears there's no PHY attached but from your dmesg I would expect >> bge0 to cause trouble. >> Can you please post output of `pciconf -lv | grep -A 3 bge'? >> I think the -net maintainers will be able to see the relevant pieces >> from that output. >> >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >> Responsible-Changed-By: vwe >> Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 >> Responsible-Changed-Why: >> >> Over to maintainer(s). >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 > From adam at mhm.lv Wed May 7 21:10:54 2008 From: adam at mhm.lv (adam@mhm.lv) Date: Wed May 7 21:11:01 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN References: <200805072037.m47KbGc6044521@freefall.freebsd.org> Message-ID: <009401c8b083$1aafeac0$55275150@homee7979e67c1> Sure! Here you are! GBRT2# pciconf -lv | grep -A 3 bge bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' class = network -- bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# ----- Original Message ----- From: To: ; ; ; Sent: Wednesday, May 07, 2008 11:37 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Wed May 7 20:33:44 UTC 2008 > State-Changed-Why: > > It appears there's no PHY attached but from your dmesg I would expect > bge0 to cause trouble. > Can you please post output of `pciconf -lv | grep -A 3 bge'? > I think the -net maintainers will be able to see the relevant pieces > from that output. > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 > Responsible-Changed-Why: > > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From oleksandr at samoylyk.sumy.ua Wed May 7 21:42:28 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 21:42:31 2008 Subject: Problems with netgraph In-Reply-To: <482209E5.7010607@elischer.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> <482209E5.7010607@elischer.org> Message-ID: <48222236.5090802@samoylyk.sumy.ua> Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> Oleksandr Samoylyk wrote: >>>> Julian Elischer wrote: >>>>> Oleksandr Samoylyk wrote: >>>>>> David DeSimone wrote: >>>>>>> Julian Elischer wrote: >>>>>>>> unfortunatly I've been totally ignoring this thread because it >>>>>>>> said >>>>>>>> "trouble with em" in the topic.. >>>>>>>> If you'd said "trouble with mpd" then maybe I'd have looked >>>>>>>> earlier.. >>>>>>> >>>>>>> In the poster's defense, the only symptom that started this was this >>>>>>> info from ps: >>>>>>> >>>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>>>> COMMAND >>>>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 >>>>>>> 100.00% em0 taskq >>>>>>> >>>>>>> So tracking it down to mpd has been a process of elimination in >>>>>>> figuring >>>>>>> out why packets absorb so much CPU. >>>>>>> >>>>>> >>>>>> Here is a result of profiling: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>>>> >>>>> >>>>> >>>>> 0.00 0.00 16/1643247 igmp_input [833] >>>>> 0.03 0.01 614/1643247 icmp_input [272] >>>>> 93.07 17.27 1642617/1643247 encap4_input [9] >>>>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>>>> 14.26 0.88 600796/749987 >>>>> _mtx_lock_sleep [21] >>>>> 0.16 1.70 1643863/1643863 raw_append [93] >>>>> 0.00 0.24 36345/176995 >>>>> _mtx_unlock_sleep >>>>> [114] >>>>> 0.01 0.00 1643863/5117962 jailed [278] >>>>> 0.00 0.00 1292/1843 m_copym [666] >>>>> 0.00 0.00 676/8214484 m_freem [34] >>>>> >>>>> >>>>> >>>>> 50% of time in rip_input??? >>>>> >>>>> that's unexpected.. what is the traffic? >>>> >>>> >>>> more than 20k pps >>> >>> I mean, what KIND of traffic? >>> I'm surprised it 's calling rip_input().. why is it calling >>> encap4_input()? (which calls rip_input).. what is the IP protocol >>> of all these packets? >>> >>> what does a small snippet of traffic show? >>> >>> (tcpdump -i em0 -s0 -e -n -c 64) >> >> >> GRE (pptp-tunnels) >> >> tcpdump -i em0 -s0 -e -n -c 64 >> >> 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P >> 3482978131:3482978327(196) ack 537019550 win 128 >> 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq >> 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) >> ack 239105401 win 58593 >> 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq >> 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 195.91.147.100.62073 > 77.120.205.18.43463: . >> 2979675127:2979676487(1360) ack 3166103641 win 65212 >> 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq >> 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), >> length 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 >> win 17680 >> 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq >> 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win >> 58593 >> 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack >> 1841830, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq >> 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) >> ack 3056545326 win 32254 >> 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq >> 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 >> win 65212 >> 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq >> 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: >> 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 >> 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq >> 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), >> length 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 >> 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack >> 1687270, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq >> 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: >> 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 >> 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq >> 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: >> seq 0x039, Flags [begin], length 1400 >> 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq >> 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq >> 0x039, Flags [end], length 9 >> 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq >> 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: >> 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) >> ack 1774495680 win 16384 >> 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq >> 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: >> 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack >> 337838744 win 6970 >> 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq >> 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), >> length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . >> 2176487112:2176488472(1360) ack 921656808 win 16446 >> 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq >> 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win >> 16446 >> 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack >> 145663, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq >> 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) >> ack 1545362008 win 65535 >> 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack >> 145664, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq >> 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 >> 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq >> 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: >> 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win >> 32502 >> 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq >> 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length >> 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 >> 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 >> >>>> >>>>> I see no netgraph in the profile at all. >>>>> did you statically compile it all in at compile time? (you should >>>>> if you want to see it) >>>>> >>>> >>>> Tried both variants. Now not statically. >>> >>> make sure it is static and that the netgraph nodes are all compiled >>> with -pg >>> >> >> I'll try, but a bit later. > > ok so we get somewhere.. GRE.. > > looks like UDP in PPP in GRE > > is this a pptp session? Yes. > this may be the issue: > http://www.nabble.com/GRE-Mux-td16201899.html > I think so. Should we hope for some progress in this direction in future? -- Oleksandr Samoylyk OVS-RIPE From killing at multiplay.co.uk Wed May 7 21:49:04 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed May 7 21:49:14 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> Message-ID: <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> Does this really warrant a high priority flag? ----- Original Message ----- From: > Sure! Here you are! > > GBRT2# pciconf -lv | grep -A 3 bge > bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' > class = network ... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From adam at mhm.lv Wed May 7 22:01:33 2008 From: adam at mhm.lv (adam@mhm.lv) Date: Wed May 7 22:01:46 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> Message-ID: <146401c8b08d$e7bf2440$55275150@homee7979e67c1> I guess it does, since this nightmere is being reported with different NICs and drivers including Intel NICs on em driver and 3Com NICs on bge and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. The mailing list if full of too many questions regarding this issue and no answer! If it realy doesn't worth a high priority flag, then I do appolgize and I shoud fall back to 4.11-RELEASE which worked on the same hardware like a sandwatch! http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 ----- Original Message ----- From: "Steven Hartland" To: ; Cc: ; Sent: Thursday, May 08, 2008 12:29 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN > Does this really warrant a high priority flag? > > ----- Original Message ----- > From: > >> Sure! Here you are! >> >> GBRT2# pciconf -lv | grep -A 3 bge >> bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' >> class = network > ... > -- bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing or > otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From andre at freebsd.org Wed May 7 22:54:26 2008 From: andre at freebsd.org (Andre Oppermann) Date: Wed May 7 22:54:32 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <20080506133208.C2EC.B627C632@gmail.com> References: <20080506133208.C2EC.B627C632@gmail.com> Message-ID: <48223324.6070203@freebsd.org> I've looked at the code paths again. There are two possibilities: a) the mbuf allocator has some anomaly where it rejects memory requests but doesn't update the statistics (the code is there however). b) the error doesn't come from the mbuf allocation but from ip_output() and further down the chain. To differentiate please try this updated patch and report the log output again (don't forget to set net.inet.tcp.log_debug=1): http://people.freebsd.org/~andre/tcp_output-error-log.diff -- Andre Deng XueFeng wrote: > hi > I'am also meet this problem in my mss server(missey streaming server). > one encoder push stream to mss, then run 100 client player playing the > sream, as the client number increase, mss will occur this error sooner or later > like this: > I'am using kqueue, and will got a event with EV_EOF and fflags = > ETIMEDOUT, > if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), > > and the tcpdump also show that server will send RST packet to encoder. > > >> Hello, >> >> I'm are having a trouble with TCP connections being dropped with "read: >> Operation timed out". What is unusual is that this is happening right in >> the middle of sending a steady stream of data with no network congestion. >> >> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit >> connection. The server receives a 192kbps inbound stream over TCP, and >> broadcasts it over a large number of TCP streams. >> >> With no visible or obvious pattern, the inbound read() fails with >> ETIMEDOUT. The likelihood of this happening seems to increase as the >> number of audience connections increases. It's happens every few minutes >> even with a small audience (eg. 300 outbound connections and about >> 60mbit). >> >> It doesn't cough and splutter -- steady data is coming in, then it just >> drops the connection. >> >> systat doesn't show problems inbound; all packets received are delivered >> to the upper layer. But on outbound, there is consistent 'output drops': >> >> IP Output >> 7028 total packets sent >> 7028 - generated locally >> 314 - output drops >> >> As the number of outbound connections increases, the 'output drops' >> increases to around 10% of the total packets sent and maintains that >> ratio. There's no problems with network capacity. >> >> I've tried different servers, different network interfaces (bge, em), >> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats >> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat >> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen >> in a dedicated, uncontended test environment. >> >> Can anyone explain why the packets are being dropped outbound, and how >> this could affect inbound TCP data in such an abrupt way? What can I do to >> solve this? >> >> Thanks, >> >> Mark >> _______________________________________________ >> 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 adam at mhm.lv Wed May 7 23:21:22 2008 From: adam at mhm.lv (adam@mhm.lv) Date: Wed May 7 23:21:30 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> <146401c8b08d$e7bf2440$55275150@homee7979e67c1> <6721C20C6813418DBFA2DA2341EB9976@multiplay.co.uk> Message-ID: <150c01c8b099$0dcd91c0$55275150@homee7979e67c1> This issue is not a personal problem of mine. As I have alrady mentioned a lot of people have been reporting this issue without any answer. It's really sad that you've been unpolite and agressive to me just because I labelled the message HP. Does it really worth this overreaction? Well, let the people of reason answer. As for blocking me, I do respect your freedom of choice. Culture prevents me from responding otherwise! ----- Original Message ----- From: "Steven Hartland" To: Sent: Thursday, May 08, 2008 1:50 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN > Well given you have no consideration to for others and clearly think the > world > revolves around you problems so they every email you send must be flagged > as important, welcome to my blocked senders list. > > ----- Original Message ----- > From: > To: "Steven Hartland" > Cc: ; ; > > Sent: Wednesday, May 07, 2008 11:01 PM > Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate > changedto DOWN > > >>I guess it does, since this nightmere is being reported with different >>NICs and drivers including Intel NICs on em driver and 3Com NICs on bge >>and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. >> >> The mailing list if full of too many questions regarding this issue and >> no answer! >> >> If it realy doesn't worth a high priority flag, then I do appolgize and I >> shoud fall back to 4.11-RELEASE which worked on the same hardware like a >> sandwatch! > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing or > otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From bms at incunabulum.net Thu May 8 02:52:17 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Thu May 8 02:52:22 2008 Subject: Problems with netgraph In-Reply-To: <48222236.5090802@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> <482209E5.7010607@elischer.org> <48222236.5090802@samoylyk.sumy.ua> Message-ID: <48226ADC.1090801@incunabulum.net> Oleksandr Samoylyk wrote: >> >> looks like UDP in PPP in GRE > > I think so. Should we hope for some progress in this direction in future? Probably not, unless someone is willing to come up to the table and commit to writing and maintaining a Netgraph node to demux GRE, although this is only shuffling the fanout elsewhere. If MPD is relying on raw sockets to demultiplex GRE, then this is what it's up against in terms of performance -- repeated acquisitions of the INP sleep lock, and context switches when the socket buffer low water mark is passed. It might have improved slightly in HEAD since the move to rwlocks. Like udp_input(), rip_input() suffers from the fact that the stack has to deal with delivering datagrams to potentially more than one socket, and there is no intermediate data structure to handle the fan-out -- it walks the entire inp list every time. If you look at the comments in udp_input() it's pretty clear this is a historical weakness in the BSD implementation. Windows, by the way, forces socket clients to explicitly request reception of broadcast datagrams as of Windows Server 2003, and multicasts are strictly delivered to group members only, which eliminates that problematic loop -- you can always maintain a tree of receivers that way. I'm happy to review patches if someone else commits to fixing it. cheers BMS From dengxf at gmail.com Thu May 8 04:06:55 2008 From: dengxf at gmail.com (Deng XueFeng) Date: Thu May 8 04:07:00 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <48223324.6070203@freebsd.org> References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> Message-ID: <20080508120410.70E4.B627C632@gmail.com> hi, the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? > I've looked at the code paths again. There are two possibilities: > > a) the mbuf allocator has some anomaly where it rejects memory requests > but doesn't update the statistics (the code is there however). > > b) the error doesn't come from the mbuf allocation but from ip_output() > and further down the chain. > > To differentiate please try this updated patch and report the log output > again (don't forget to set net.inet.tcp.log_debug=1): > > http://people.freebsd.org/~andre/tcp_output-error-log.diff > > -- > Andre > > Deng XueFeng wrote: > > hi > > I'am also meet this problem in my mss server(missey streaming server). > > one encoder push stream to mss, then run 100 client player playing the > > sream, as the client number increase, mss will occur this error sooner or later > > like this: > > I'am using kqueue, and will got a event with EV_EOF and fflags = > > ETIMEDOUT, > > if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), > > > > and the tcpdump also show that server will send RST packet to encoder. > > > > > >> Hello, > >> > >> I'm are having a trouble with TCP connections being dropped with "read: > >> Operation timed out". What is unusual is that this is happening right in > >> the middle of sending a steady stream of data with no network congestion. > >> > >> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit > >> connection. The server receives a 192kbps inbound stream over TCP, and > >> broadcasts it over a large number of TCP streams. > >> > >> With no visible or obvious pattern, the inbound read() fails with > >> ETIMEDOUT. The likelihood of this happening seems to increase as the > >> number of audience connections increases. It's happens every few minutes > >> even with a small audience (eg. 300 outbound connections and about > >> 60mbit). > >> > >> It doesn't cough and splutter -- steady data is coming in, then it just > >> drops the connection. > >> > >> systat doesn't show problems inbound; all packets received are delivered > >> to the upper layer. But on outbound, there is consistent 'output drops': > >> > >> IP Output > >> 7028 total packets sent > >> 7028 - generated locally > >> 314 - output drops > >> > >> As the number of outbound connections increases, the 'output drops' > >> increases to around 10% of the total packets sent and maintains that > >> ratio. There's no problems with network capacity. > >> > >> I've tried different servers, different network interfaces (bge, em), > >> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats > >> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat > >> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen > >> in a dedicated, uncontended test environment. > >> > >> Can anyone explain why the packets are being dropped outbound, and how > >> this could affect inbound TCP data in such an abrupt way? What can I do to > >> solve this? > >> > >> Thanks, > >> > >> Mark > >> _______________________________________________ > >> 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" > > -- Deng XueFeng From julian at elischer.org Thu May 8 07:33:50 2008 From: julian at elischer.org (Julian Elischer) Date: Thu May 8 07:33:54 2008 Subject: multiple routing tables review patch ready for simple testing. In-Reply-To: <20080507074647.B47338@maildrop.int.zabbadoz.net> References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> <4820C8CE.8010309@elischer.org> <20080507074647.B47338@maildrop.int.zabbadoz.net> Message-ID: <4822ACDB.6040209@elischer.org> Bjoern A. Zeeb wrote: > On Tue, 6 May 2008, Julian Elischer wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> On Tue, 29 Apr 2008, Julian Elischer wrote: >>> >>> Hi, >>> >>>> The patch can be found at >>>> http://www.freebsd.org/~julian/mrt.diff >>>> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >>>> >>>> or source can be taken from perforce at: >>>> //depot/user/julian/routing/src >>> >>> So after looking at the patch a bit more again, could you add wrapper >>> functions for those like you have done for the old KPI (rtrequest, >>> rtrequest1, >> >> do you really want to do the extra work instructions? >> > ... >>> >>> The defines will not give you a stable KPI and having that changed again >>> if you are going with a prefix for each AF would be a pain if the >>> _fib versions >>> are going to change in the future. >> >> hmm fair enough... but let me outline my plans and thoughts >> so we can see if you still want this.. >> > [ ... ] >> >> This all however is not ABI compatible so could not go back to 7.x >> and I want to check in an initial version that can go back to 7.x >> which sort of suggests to me that adding in_xxx functions is >> not really required, until I do the next step. >> 7.x will never get the next step. because the ABI is already set >> in stone for 7.x. >> >> I would make the in_xxx stubs in the next step in 8.x. >> after the MFC to 7.x of the ABI compat version. >> >> >> let me know what you think. > > Leaving aside any upcoming enhancement if what we have now is > what is going into 7 and possibly 6 we should do the wrapper > functions. > > The point is RELENG_7 will live for $(last release + 2 years) so I > guess till 2011 or maybe later. No idea what would happen there in all > that time. > > If people start adding support for other AFs we cannot say that the > *_fib variants are not going to change so having the in_* stable > sounds like a good thing for 6 and 7. > > Am I missing anything obvious? > > > I don't mind if they are going to significantly change again in 8 > a few weeks later. ok, check http://www.freebsd.org/~julian/mrt.diff > > > /bz > From andre at freebsd.org Thu May 8 08:32:59 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu May 8 08:33:07 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <20080508120410.70E4.B627C632@gmail.com> References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> <20080508120410.70E4.B627C632@gmail.com> Message-ID: <4822BABB.4020407@freebsd.org> Deng XueFeng wrote: > hi, > the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? The logging function is not (yet) present in RELENG_6. I'll post the patch when I've backported the functionality. However it's an important information that it happens on 6.2 too. That means the source of the trouble wasn't introduced with 7.0. -- Andre >> I've looked at the code paths again. There are two possibilities: >> >> a) the mbuf allocator has some anomaly where it rejects memory requests >> but doesn't update the statistics (the code is there however). >> >> b) the error doesn't come from the mbuf allocation but from ip_output() >> and further down the chain. >> >> To differentiate please try this updated patch and report the log output >> again (don't forget to set net.inet.tcp.log_debug=1): >> >> http://people.freebsd.org/~andre/tcp_output-error-log.diff >> >> -- >> Andre >> >> Deng XueFeng wrote: >>> hi >>> I'am also meet this problem in my mss server(missey streaming server). >>> one encoder push stream to mss, then run 100 client player playing the >>> sream, as the client number increase, mss will occur this error sooner or later >>> like this: >>> I'am using kqueue, and will got a event with EV_EOF and fflags = >>> ETIMEDOUT, >>> if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), >>> >>> and the tcpdump also show that server will send RST packet to encoder. >>> >>> >>>> Hello, >>>> >>>> I'm are having a trouble with TCP connections being dropped with "read: >>>> Operation timed out". What is unusual is that this is happening right in >>>> the middle of sending a steady stream of data with no network congestion. >>>> >>>> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit >>>> connection. The server receives a 192kbps inbound stream over TCP, and >>>> broadcasts it over a large number of TCP streams. >>>> >>>> With no visible or obvious pattern, the inbound read() fails with >>>> ETIMEDOUT. The likelihood of this happening seems to increase as the >>>> number of audience connections increases. It's happens every few minutes >>>> even with a small audience (eg. 300 outbound connections and about >>>> 60mbit). >>>> >>>> It doesn't cough and splutter -- steady data is coming in, then it just >>>> drops the connection. >>>> >>>> systat doesn't show problems inbound; all packets received are delivered >>>> to the upper layer. But on outbound, there is consistent 'output drops': >>>> >>>> IP Output >>>> 7028 total packets sent >>>> 7028 - generated locally >>>> 314 - output drops >>>> >>>> As the number of outbound connections increases, the 'output drops' >>>> increases to around 10% of the total packets sent and maintains that >>>> ratio. There's no problems with network capacity. >>>> >>>> I've tried different servers, different network interfaces (bge, em), >>>> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats >>>> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat >>>> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen >>>> in a dedicated, uncontended test environment. >>>> >>>> Can anyone explain why the packets are being dropped outbound, and how >>>> this could affect inbound TCP data in such an abrupt way? What can I do to >>>> solve this? >>>> >>>> Thanks, >>>> >>>> Mark >>>> _______________________________________________ >>>> 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 mark at pogo.org.uk Thu May 8 09:17:09 2008 From: mark at pogo.org.uk (Mark Hills) Date: Thu May 8 09:17:12 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <4822BABB.4020407@freebsd.org> References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> <20080508120410.70E4.B627C632@gmail.com> <4822BABB.4020407@freebsd.org> Message-ID: On Thu, 8 May 2008, Andre Oppermann wrote: > Deng XueFeng wrote: >> hi, >> the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? > > The logging function is not (yet) present in RELENG_6. I'll post the > patch when I've backported the functionality. > > However it's an important information that it happens on 6.2 too. That > means the source of the trouble wasn't introduced with 7.0. I did earlier tests with the same software on FreeBSD 6.3 and never saw ETIMEDOUT -- only on FreeBSD 7.0. But I did have a different issue with 6.3 (lockups under very heavy conditions), although didn't do any specific tuning to try and stop this. Instead I made the jump to 7.0 which stopped this problem but introduced the ETIMEDOUT one. Mark From tim at gebbettco.com Thu May 8 11:53:27 2008 From: tim at gebbettco.com (Tim Gebbett) Date: Thu May 8 11:53:31 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <4822BABB.4020407@freebsd.org> References: <4822BABB.4020407@freebsd.org> Message-ID: Hi all, applied the patch, Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t May 8 12:14:26 timtest kernel: o May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT May 8 12:14:26 timtest kernel: C May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i interspersed with clean blocks of 20 entries or so of: May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) The output did not look appreciably different when the ETIMEDOUT occurred. On stopping the client test program: May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored netstat -m 258/11007/11265 mbufs in use (current/cache/total) 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/36283K/36860K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Thanks again for your help - Tim From andre at freebsd.org Thu May 8 16:06:15 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu May 8 16:06:17 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: References: <4822BABB.4020407@freebsd.org> Message-ID: <482324F9.7030802@freebsd.org> Hi Tim, looking at the ip_output() path there are some places that can return ENOBUFS: a) interface queue length check b) packet filter c) destination address rewrite through NAT d) if_output() call e) IP fragmentation if DF was not set The first one of those is the most likely to be the source of the error. The output interface queue length in read unlocked and may be a stale value on an SMP machine. Further down in ether_output() there are some further possibilities for ENOBUFS errors. But lets concentrate on a) first. For testing purposes please apply the following patch to ip_output(): ------------------------------------------------------------------- cvs diff -up ip_output.c Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.276.2.1 diff -u -p -r1.276.2.1 ip_output.c --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 +++ ip_output.c 8 May 2008 16:02:32 -0000 @@ -370,7 +370,7 @@ again: ip->ip_src = IA_SIN(ia)->sin_addr; } } - +#if 0 /* * Verify that we have any chance at all of being able to queue the * packet or packet fragments, unless ALTQ is enabled on the given @@ -390,7 +390,7 @@ again: ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); goto bad; } - +#endif /* * Look for broadcast address and * verify user is allowed to send ------------------------------------------------------------------- If there is a real interface output queue full event the IFQ_HANDOFF() and IFQ_ENQUEUE() macros will report it too. Then we can focus on the interface queues. -- Andre Tim Gebbett wrote: > Hi all, > > applied the patch, > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: > > > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t > May 8 12:14:26 timtest kernel: o > May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT > May 8 12:14:26 timtest kernel: C > May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > interspersed with clean blocks of 20 entries or so of: > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > On stopping the client test program: > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > netstat -m > > 258/11007/11265 mbufs in use (current/cache/total) > 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) > 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 576K/36283K/36860K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/4/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Thanks again for your help - Tim > > > > > > > > > From tim at gebbettco.com Thu May 8 18:26:55 2008 From: tim at gebbettco.com (Tim Gebbett) Date: Thu May 8 18:27:00 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <482324F9.7030802@freebsd.org> References: <482324F9.7030802@freebsd.org> Message-ID: <32570632be785826455c493ec4d37206@193.189.140.95> Hi Andre, Applied the patch, I could not see anything different to the last test. No packet filtering or NAT are enabled, the test is running over a switch. Many thanks - Tim 258/6657/6915 mbufs in use (current/cache/total) 256/1084/1340/25600 mbuf clusters in use (current/cache/total/max) 256/1024 mbuf+clusters out of packet secondary zone in use (current/cache) 0/3565/3565/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/18092K/18668K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines tcp: 2535986 packets sent 2331504 data packets (3266105457 bytes) 258369 data packets (371873800 bytes) retransmitted 46685 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 27972 ack-only packets (3905 delayed) 0 URG only packets 0 window probe packets 10636 window update packets 4 control packets 1888423 packets received 1172093 acks (for 3256670917 bytes) 425512 duplicate acks 0 acks for unsent data 46363 packets (52992771 bytes) received in-sequence 19 completely duplicate packets (17508 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 293 out-of-order packets (376674 bytes) 0 packets (0 bytes) of data after window 0 window probes 242695 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 2 connection requests 2054 connection accepts 0 bad connection attempts 0 listen queue overflows 597 ignored RSTs in the windows 2056 connections established (including accepts) 2052 connections closed (including 2049 drops) 2048 connections updated cached RTT on close 2048 connections updated cached RTT variance on close 2048 connections updated cached ssthresh on close 0 embryonic connections dropped 1172093 segments updated rtt (of 1057825 attempts) 72399 retransmit timeouts 1 connection dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 4806 correct ACK header predictions 43111 correct data packet header predictions 2054 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 2054 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 2054 cookies sent 0 cookies received 83801 SACK recovery episodes 116632 segment rexmits in SACK recovery episodes 168710294 byte rexmits in SACK recovery episodes 544885 SACK options (SACK blocks) received 14 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 31 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 10 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 21 delivered 22 datagrams output 0 times multicast source filter matched sctp: 0 input packets 0 datagrams 0 packets that had data 0 input SACK chunks 0 input DATA chunks 0 duplicate DATA chunks 0 input HB chunks 0 HB-ACK chunks 0 input ECNE chunks 0 input AUTH chunks 0 chunks missing AUTH 0 invalid HMAC ids received 0 invalid secret ids received 0 auth failed 0 fast path receives all one chunk 0 fast path multi-part data 0 output packets 0 output SACKs 0 output DATA chunks 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 FR's that happened more than once to same chunk. 0 intput HB chunks 0 output ECNE chunks 0 output AUTH chunks 0 ip_output error counter Packet drop statistics: 0 from middle box 0 from end host 0 with data 0 non-data, non-endhost 0 non-endhost, bandwidth rep only 0 not enough for chunk header 0 not enough data to confirm 0 where process_chunk_drop said break 0 failed to find TSN 0 attempt reverse TSN lookup 0 e-host confirms zero-rwnd 0 midbox confirms no space 0 data did not match TSN 0 TSN's marked for Fast Retran Timeouts: 0 iterator timers fired 0 T3 data time outs 0 window probe (T3) timers fired 0 INIT timers fired 0 sack timers fired 0 shutdown timers fired 0 heartbeat timers fired 0 a cookie timeout fired 0 an endpoint changed its cookiesecret 0 PMTU timers fired 0 shutdown ack timers fired 0 shutdown guard timers fired 0 stream reset timers fired 0 early FR timers fired 0 an asconf timer fired 0 auto close timer fired 0 asoc free timers expired 0 inp free timers expired 0 packet shorter than header 0 checksum error 0 no endpoint for port 0 bad v-tag 0 bad SID 0 no memory 0 number of multiple FR in a RTT window 0 RFC813 allowed sending 0 RFC813 does not allow sending 0 max burst dosn't allow sending 0 look ahead tells us no memory in interface 0 numbers of window probes sent 0 times an output error to clamp down on next user send. 0 times sctp_senderrors were caused from a user 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 times a ECN reduced the cwnd 0 used express lookup via vtag 0 collision in express lookup. 0 times the sender ran dry of user data on primary 0 same for above 0 sacks the slow way 0 window update only sacks sent 0 sends with sinfo_flags !=0 0 unordered sends 0 sends with EOF flag set 0 sends with ABORT flag set 0 times protocol drain called 0 times we did a protocol drain 0 times recv was called with peek 0 cached chunks used 0 cached stream oq's used 0 unread messages abandonded by close 0 send burst avoidance, already max burst inflight to net 0 send cwnd full avoidance, already max burst inflight to net 0 number of map array over-runs via fwd-tsn's ip: 1888457 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 1888454 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 3 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 2628572 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header On Thu, 08 May 2008 18:06:17 +0200, Andre Oppermann wrote: > Hi Tim, > > looking at the ip_output() path there are some places that can > return ENOBUFS: > > a) interface queue length check > > b) packet filter > > c) destination address rewrite through NAT > > d) if_output() call > > e) IP fragmentation if DF was not set > > The first one of those is the most likely to be the source of the > error. The output interface queue length in read unlocked and may > be a stale value on an SMP machine. Further down in ether_output() > there are some further possibilities for ENOBUFS errors. But lets > concentrate on a) first. > > For testing purposes please apply the following patch to ip_output(): > > ------------------------------------------------------------------- > cvs diff -up ip_output.c > Index: ip_output.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.276.2.1 > diff -u -p -r1.276.2.1 ip_output.c > --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 > +++ ip_output.c 8 May 2008 16:02:32 -0000 > @@ -370,7 +370,7 @@ again: > ip->ip_src = IA_SIN(ia)->sin_addr; > } > } > - > +#if 0 > /* > * Verify that we have any chance at all of being able to queue > the > * packet or packet fragments, unless ALTQ is enabled on the > given > @@ -390,7 +390,7 @@ again: > ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); > goto bad; > } > - > +#endif > /* > * Look for broadcast address and > * verify user is allowed to send > ------------------------------------------------------------------- > > If there is a real interface output queue full event the IFQ_HANDOFF() > and IFQ_ENQUEUE() macros will report it too. Then we can focus on the > interface queues. > > -- > Andre > > Tim Gebbett wrote: >> Hi all, >> >> applied the patch, >> >> Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug > started venting massive quantities of tcp_output error 55 while sending > with syncache noise: >> >> >> y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: > error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t >> May 8 12:14:26 timtest kernel: o >> May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 > while sendingT >> May 8 12:14:26 timtest kernel: C >> May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 > 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. > 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i >> >> interspersed with clean blocks of 20 entries or so of: >> >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> >> >> The output did not look appreciably different when the ETIMEDOUT > occurred. >> >> On stopping the client test program: >> >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> >> netstat -m >> >> 258/11007/11265 mbufs in use (current/cache/total) >> 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) >> 256/1536 mbuf+clusters out of packet secondary zone in use > (current/cache) >> 0/7585/7585/51200 4k (page size) jumbo clusters in use > (current/cache/total/max) >> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) >> 576K/36283K/36860K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/4/6656 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> >> Thanks again for your help - Tim >> >> >> >> >> >> >> >> >> > > _______________________________________________ > 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 vwe at FreeBSD.org Thu May 8 19:07:19 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Thu May 8 19:07:21 2008 Subject: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN Message-ID: <200805081907.m48J7I2d053813@freefall.freebsd.org> Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Thu May 8 19:06:56 UTC 2008 State-Changed-Why: Feedback has been provided. http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From gnn at freebsd.org Thu May 8 19:20:31 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu May 8 19:20:35 2008 Subject: Change from BSDL to GPL In-Reply-To: <001701c8ae36$96f0f560$5084183a@honglan> References: <001701c8ae36$96f0f560$5084183a@honglan> Message-ID: At Mon, 05 May 2008 06:31:25 +0800, kevin wrote: > > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? > Alas, the short answer is "Consult an IP lawyer." Best, George From jhb at FreeBSD.org Thu May 8 20:45:55 2008 From: jhb at FreeBSD.org (John Baldwin) Date: Thu May 8 20:45:59 2008 Subject: Small patch.. Message-ID: <200805081625.33093.jhb@FreeBSD.org> At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are spamming the heck out of our dmesg so I am #if 0'ing all of them out and while doing so ran into this case. Specifically, it doesn't actually bump the stat counter unless it succeeds in allocating memory to log the debug message. All the other places in the syncache and tcp input code always bump the stats, so this patch fixes it to do that. Index: tcp_syncache.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.143 diff -u -r1.143 tcp_syncache.c --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 @@ -567,10 +567,11 @@ "connection attempt aborted by remote endpoint\n", s, __func__); tcpstat.tcps_sc_reset++; - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " - "(+WND %u), segment ignored\n", - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); + } else { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " + "IRS %u (+WND %u), segment ignored\n", + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); tcpstat.tcps_badrst++; } -- John Baldwin From bzeeb-lists at lists.zabbadoz.net Thu May 8 21:15:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu May 8 21:15:10 2008 Subject: Small patch.. In-Reply-To: <200805081625.33093.jhb@FreeBSD.org> References: <200805081625.33093.jhb@FreeBSD.org> Message-ID: <20080508211342.M47338@maildrop.int.zabbadoz.net> On Thu, 8 May 2008, John Baldwin wrote: > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > while doing so ran into this case. Specifically, it doesn't actually bump > the stat counter unless it succeeds in allocating memory to log the debug > message. All the other places in the syncache and tcp input code always bump > the stats, so this patch fixes it to do that. looks good. > Index: tcp_syncache.c > =================================================================== > RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v > retrieving revision 1.143 > diff -u -r1.143 tcp_syncache.c > --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 > +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 > @@ -567,10 +567,11 @@ > "connection attempt aborted by remote endpoint\n", > s, __func__); > tcpstat.tcps_sc_reset++; > - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { > - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " > - "(+WND %u), segment ignored\n", > - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > + } else { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " > + "IRS %u (+WND %u), segment ignored\n", > + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > tcpstat.tcps_badrst++; > } > > > -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From vwe at FreeBSD.org Thu May 8 21:29:36 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Thu May 8 21:29:37 2008 Subject: kern/121080: [bge] IPv6 NUD problem on multi address config on bge0 Message-ID: <200805082129.m48LTZW9065180@freefall.freebsd.org> Synopsis: [bge] IPv6 NUD problem on multi address config on bge0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Thu May 8 21:29:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121080 From petar at smokva.net Thu May 8 21:36:43 2008 From: petar at smokva.net (Petar Bogdanovic) Date: Thu May 8 21:36:48 2008 Subject: authentication timeouts with ath(4) in hostap mode In-Reply-To: <481BB0E5.8000803@freebsd.org> References: <20080502093655.GA3535@pintail.smokva.net> <481BB0E5.8000803@freebsd.org> Message-ID: <20080508213512.GA9389@pintail.smokva.net> On Fri, May 02, 2008 at 05:25:09PM -0700, Sam Leffler wrote: > Petar Bogdanovic wrote: >> Hi, >> >> I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and >> FreeBSD 7: >> >> ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan >> ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan >> >> >> When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux >> wpa_supplicant drops the connection and has to reassociate. This however >> does not work immediately; The supplicant fails a few times before >> reconnecting: >> >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Associated with 00:0b:0b:06:0d:09 >> <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> >> >> This happens more on the 11a than on the 11g network. When I'm next to >> the AP, the timeouts are almost gone but they still happen. (My laptop >> is just one room away from the AP). Here is the athstats-output of ath0 >> (11a): >> >> # ./athstats -i ath0 >> 481546 data frames received >> 330669 data frames transmit >> 13395 tx frames with an alternate rate >> 78558 long on-chip tx retries >> 1431 tx failed 'cuz too many retries >> 36M current transmit rate >> 78 tx management frames >> 3 tx frames discarded prior to association >> 45 tx frames with no ack marked >> 2894 rx failed 'cuz of bad CRC >> 2 rx failed 'cuz decryption >> 92711 rx failed 'cuz of PHY err >> 92708 OFDM timing >> 3 OFDM restart >> 318332 beacons transmitted >> 1111 periodic calibrations >> 2 rfgain value change >> 22 rssi of last ack >> 23 avg recv rssi >> -96 rx noise floor >> 2530 switched default/rx antenna >> Antenna profile: >> [1] tx 173364 rx 123068 >> [2] tx 155874 rx 358671 > > So the obvious question is whether your system config has enough isolation > of the radios for them not to impact each other? I have no experience with > Alix boards but it's not uncommon for there to be power and signal issues > when operating multiple radios in an enclosure (and yes, even with the > radios on different bands). > > You don't indicate what you've done to diagnose this problem. Have you > verified the packets are present in the air? Have you traced packets > and/or phy errors around the time of the problem? Does turning off one > radio give you stable operation? Have you tried different channels? Have > you tried different boards? > > >> >> >> All this is well known to me, since I had NetBSD running on this device >> for months and it suffered the same problems -- it was even worse, the >> timeouts occured every few minutes. Back then, it seemed that ath had >> some interrupt problems: >> >> ath0: device timeout >> >> as David Young from NetBSD noticed in his mail some time ago: >> >> http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html >> >> >> FreeBSD doesn't seem to have this `device timeouts'. I don't see any in >> /var/log/messages and there are none when I'm connected to the device >> over a serial port. >> >> I'm a bit lost here, but ready to debug if someone knows more. > > netbsd's code base is many _years_ out of date wrt freebsd; comparing > operation of the two systems is unlikely to be useful. Just for the record: After various (client-)tests with Intel 2200BG and 3945ABG chips and one AR5212 chip on FreeBSD, it seems that only the madwifi client caused interrupts or more precisly: interrupts after a missed beacon. My observations correspond with the following madwifi ticket: http://madwifi.org/ticket/848 One beacon miss, one interrupt. The FreeBSD ath-driver does _not_ show any similar behaviour on the same device. Kind regards, Petar From andre at freebsd.org Thu May 8 22:30:52 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu May 8 22:30:56 2008 Subject: Small patch.. In-Reply-To: <200805081625.33093.jhb@FreeBSD.org> References: <200805081625.33093.jhb@FreeBSD.org> Message-ID: <48237F1A.6020601@freebsd.org> John Baldwin wrote: > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > while doing so ran into this case. Specifically, it doesn't actually bump sysctl net.inet.tcp.log_debug=0 is simpler than #if 0 and has the same effect. In RELENG_7 it was disabled by default. > the stat counter unless it succeeds in allocating memory to log the debug > message. All the other places in the syncache and tcp input code always bump > the stats, so this patch fixes it to do that. Your fix is correct. -- Andre > Index: tcp_syncache.c > =================================================================== > RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v > retrieving revision 1.143 > diff -u -r1.143 tcp_syncache.c > --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 > +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 > @@ -567,10 +567,11 @@ > "connection attempt aborted by remote endpoint\n", > s, __func__); > tcpstat.tcps_sc_reset++; > - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { > - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " > - "(+WND %u), segment ignored\n", > - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > + } else { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " > + "IRS %u (+WND %u), segment ignored\n", > + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > tcpstat.tcps_badrst++; > } > > From dengxf at gmail.com Fri May 9 02:48:29 2008 From: dengxf at gmail.com (Deng XueFeng) Date: Fri May 9 02:48:33 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <482324F9.7030802@freebsd.org> References: <482324F9.7030802@freebsd.org> Message-ID: <20080509104700.A502.B627C632@gmail.com> hi, applied the patch for 6.2, rebuild & install kernel, but nothing changed. ETIMEDOUT still occur. > Hi Tim, > > looking at the ip_output() path there are some places that can > return ENOBUFS: > > a) interface queue length check > > b) packet filter > > c) destination address rewrite through NAT > > d) if_output() call > > e) IP fragmentation if DF was not set > > The first one of those is the most likely to be the source of the > error. The output interface queue length in read unlocked and may > be a stale value on an SMP machine. Further down in ether_output() > there are some further possibilities for ENOBUFS errors. But lets > concentrate on a) first. > > For testing purposes please apply the following patch to ip_output(): > > ------------------------------------------------------------------- > cvs diff -up ip_output.c > Index: ip_output.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.276.2.1 > diff -u -p -r1.276.2.1 ip_output.c > --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 > +++ ip_output.c 8 May 2008 16:02:32 -0000 > @@ -370,7 +370,7 @@ again: > ip->ip_src = IA_SIN(ia)->sin_addr; > } > } > - > +#if 0 > /* > * Verify that we have any chance at all of being able to queue the > * packet or packet fragments, unless ALTQ is enabled on the given > @@ -390,7 +390,7 @@ again: > ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); > goto bad; > } > - > +#endif > /* > * Look for broadcast address and > * verify user is allowed to send > ------------------------------------------------------------------- > > If there is a real interface output queue full event the IFQ_HANDOFF() > and IFQ_ENQUEUE() macros will report it too. Then we can focus on the > interface queues. > > -- > Andre > > Tim Gebbett wrote: > > Hi all, > > > > applied the patch, > > > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: > > > > > > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t > > May 8 12:14:26 timtest kernel: o > > May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT > > May 8 12:14:26 timtest kernel: C > > May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > > > interspersed with clean blocks of 20 entries or so of: > > > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > > > On stopping the client test program: > > > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > > > netstat -m > > > > 258/11007/11265 mbufs in use (current/cache/total) > > 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) > > 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > 576K/36283K/36860K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/4/6656 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > 0 calls to protocol drain routines > > > > Thanks again for your help - Tim > > > > > > > > > > > > > > > > > > -- Deng XueFeng From andre at freebsd.org Fri May 9 10:02:06 2008 From: andre at freebsd.org (Andre Oppermann) Date: Fri May 9 10:02:10 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: References: <4822BABB.4020407@freebsd.org> Message-ID: <4824211C.9090105@freebsd.org> Tim Gebbett wrote: > Hi all, > > applied the patch, > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive > quantities of tcp_output error 55 while sending with syncache noise: The error seems to be coming from the interface send queue which hits the limit. If you are using em(4) network interface please add this line to loader.conf(5): hw.em.txd=1024 Or even more if problems persist. The maximum is 4096. -- Andre > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e > n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t May 8 12:14:26 timtest kernel: o May 8 12:14:26 > timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT May 8 12:14:26 timtest > kernel: C May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; > tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest > kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 > 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 > while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 > 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ > osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > interspersed with clean blocks of 20 entries or so of: > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error > 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: > [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > On stopping the client test program: > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment > ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags > 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie > only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache > entry (possibly syncookie only), segment ignored > > netstat -m > > 258/11007/11265 mbufs in use (current/cache/total) 256/1596/1852/25600 mbuf clusters in use > (current/cache/total/max) 256/1536 mbuf+clusters out of packet secondary zone in use > (current/cache) 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in > use (current/cache/total/max) 576K/36283K/36860K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters > denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 > requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain > routines > > Thanks again for your help - Tim > > > > > > > > > From ivoras at freebsd.org Fri May 9 11:06:22 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri May 9 11:06:26 2008 Subject: Change from BSDL to GPL In-Reply-To: <002e01c8ae38$3a343240$5084183a@honglan> References: <002e01c8ae38$3a343240$5084183a@honglan> Message-ID: kevin wrote: > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? You cannot *change* the license to anything if you don't have explicit permission from the original authors (the people who created the file with the license text in it). You can *use* the BSD licensed source in your GPL project without any restrictions or requirements. You can *add* your own copyright clause and/or license to the files if you change them. In this particular case the virulent aspect of the GPL comes into play so the rest of the source becomes tainted with GPL, and in effect becomes GPL-licensed (which is allowed). But you must not *remove* the original BSD license text and its copyright lines even in this case. If you suspect anyone might sue you for it, don't rely on what I said; you must seek opinion from a lawyer. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080509/6821fb9e/signature.pgp From guru at Sisis.de Fri May 9 12:47:27 2008 From: guru at Sisis.de (Matthias Apitz) Date: Fri May 9 12:47:35 2008 Subject: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R In-Reply-To: <20080506174359.GA2814@rebelion.Sisis.de> References: <20080506174359.GA2814@rebelion.Sisis.de> Message-ID: <20080509123521.GA11366@rebelion.Sisis.de> El d?a Tuesday, May 06, 2008 a las 07:43:59PM +0200, Matthias Apitz escribi?: > > Hello, > > I'm on the way to port the above mentioned driver to FreeBSD 7.0-REL; > the work is based on the Linux driver of this card and of some help I've > got in frebsd-mobile, see thread: > > http://groups.google.com/group/muc.lists.freebsd.mobile/browse_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e > > the current state of the work is: > > - driver attaches fine to the card on insert; > - devices come up as /dev/cuaN0...4; > - serial communication with, for example, kermit to /dev/cuaN0 is fine; > - PPPD can chat with AT-cmd's into UMTS network and sign on; > - LCP layer is fine, IP comes up, routing, etc; > - with real TCP traffic the communication gets stuck, for example with > SSH from the PPPD-laptop to some server in my network; > > I've watched with TCPDUMP the interface ppp0 of the laptop and the eth0 of > the server at the same time, ... Hello, without going into the details of the TCPDUMP, it shows that the three-way-handshake (SYN-SYN-ACK) is fine, the 1st data pkg from SSH server arrives, but the answer from PPPD with the ACK is only to be seen in the TCPDUMP on the PPPD site and does not arrive at server; I've instructed the driver to log a lot of stuff, and as well the contents of the buffers send to the card ... and compared them against the PPP specs I have handy in the TCP/IP Illustraded, Volume I, from Stevens; for the LCP packages the frame look like this: 7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e 7e -- flag ff -- addr, always ff 03 -- control, always 03 c0 21 -- protocol, here LCP and the frame ends with 7e, ok; for the IP datagram containing the 1st (outgoing) SYN it looks like: 7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 cc fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58 00 00 02 04 05 b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79 f2 7e 7e -- flag 21 -- ??? (could be part of 0021 indicating IP datagram) 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 -- IP header already 4d 19 8f b7 -- src addr 77.25.143.183 c1 1f 0b c8 -- dst addr as well the ACK of SYN-SYN-ACK goes out like this: 7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7 c1 1f 0b c8 ... and also the 1st real data (containing the protocol string of the SSH client looks like this: 7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7 c1 1f 0b c8 cc fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd 00 00 01 01 08 0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30 30 36 31 31 31 30 0a f1 62 7e shouldn't they start with 7e ff 03 00 21 ... Stevens explains further more that client and server could handshake to omit the constant flag (7e) and adress field (ff) and reduce the protocol field (0021) to one byte (21), but in the above packages 'flag' is there while 'addr' and 'control' are missing? any PPP expert here to explain this? could this be the reason that the connection gets stuck? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? From rpaulo at FreeBSD.org Fri May 9 14:23:21 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Fri May 9 14:23:26 2008 Subject: fxp timeouts Message-ID: <48245E51.1090009@FreeBSD.org> Hi, On a RELENG_7 machine, after a few days of uptime, I started getting fxp DMA and SBC timeouts: May 8 19:59:33 sigma kernel: fxp0: DMA timeout May 8 19:59:33 sigma kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0xffff And this goes on forever until I reboot: % zcat /var/log/messages.1.bz2 | egrep -c '(SBC|DMA|timeout)' 1785 Has anyone else experienced this problem ? Am I having hardware problems ? I never had any problems with this card, but I recently put some extra load on this server. Regards, -- Rui Paulo From linimon at FreeBSD.org Fri May 9 14:43:30 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri May 9 14:43:32 2008 Subject: kern/123552: [ath] [panic] kernel panic during network activity on ath0 Message-ID: <200805091443.m49EhT97062955@freefall.freebsd.org> Synopsis: [ath] [panic] kernel panic during network activity on ath0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 9 14:43:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123552 From smithi at nimnet.asn.au Fri May 9 14:49:14 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri May 9 14:49:18 2008 Subject: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R In-Reply-To: <20080509123521.GA11366@rebelion.Sisis.de> Message-ID: On Fri, 9 May 2008, Matthias Apitz wrote: > El d?a Tuesday, May 06, 2008 a las 07:43:59PM +0200, Matthias Apitz escribi?: > > > > > Hello, > > > > I'm on the way to port the above mentioned driver to FreeBSD 7.0-REL; > > the work is based on the Linux driver of this card and of some help I've > > got in frebsd-mobile, see thread: > > > > http://groups.google.com/group/muc.lists.freebsd.mobile/browse_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e > > > > the current state of the work is: > > > > - driver attaches fine to the card on insert; > > - devices come up as /dev/cuaN0...4; > > - serial communication with, for example, kermit to /dev/cuaN0 is fine; > > - PPPD can chat with AT-cmd's into UMTS network and sign on; > > - LCP layer is fine, IP comes up, routing, etc; > > - with real TCP traffic the communication gets stuck, for example with > > SSH from the PPPD-laptop to some server in my network; > > > > I've watched with TCPDUMP the interface ppp0 of the laptop and the eth0 of > > the server at the same time, ... > > Hello, > > without going into the details of the TCPDUMP, it shows that the > three-way-handshake (SYN-SYN-ACK) is fine, the 1st data pkg from SSH > server arrives, but the answer from PPPD with the ACK is only to be seen > in the TCPDUMP on the PPPD site and does not arrive at server; > > I've instructed the driver to log a lot of stuff, and as well the > contents of the buffers send to the card ... and compared them against > the PPP specs I have handy in the TCP/IP Illustraded, Volume I, from > Stevens; > > for the LCP packages the frame look like this: > > 7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e > > 7e -- flag > ff -- addr, always ff > 03 -- control, always 03 > c0 21 -- protocol, here LCP > > and the frame ends with 7e, ok; > > for the IP datagram containing the 1st (outgoing) SYN it looks like: > > 7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 cc > fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58 00 00 02 04 05 > b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79 f2 7e > > > 7e -- flag > 21 -- ??? (could be part of 0021 indicating IP datagram) > 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 -- IP header already > 4d 19 8f b7 -- src addr 77.25.143.183 > c1 1f 0b c8 -- dst addr > > as well the ACK of SYN-SYN-ACK goes out like this: > > 7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7 c1 1f 0b c8 ... > > and also the 1st real data (containing the protocol string of the SSH client > looks like this: > > 7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7 c1 1f 0b c8 cc > fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd 00 00 01 01 08 > 0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 > 48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30 30 36 31 31 31 > 30 0a f1 62 7e > > shouldn't they start with > > 7e ff 03 00 21 ... > > Stevens explains further more that client and server could handshake to > omit the constant flag (7e) and adress field (ff) and reduce the > protocol field (0021) to one byte (21), but in the above packages 'flag' is there > while 'addr' and 'control' are missing? > > any PPP expert here to explain this? could this be the reason that the > connection gets stuck? Probably not the sort of help you wanted, and I'm no PPP expert, but having run ppp(8) in and out for ten years and more recently mpd(8) outbound, I have to ask, does this gig depend on using pppd? Just that in that time I've seen very few people using pppd except some people just coming over from linux, or those hoping to use kde's dialer, and have noticed little success reported with apparent pppd bugs. Almost invariably people seem better advised to use ppp or more lately mpd instead, if only because quite a few people here can resolve config and usage problems with either, whereas pppd appears to have been all but deprecated for some years - but perhaps I do it an injustice. HTH, Ian (subscribed only to -net) From ermal.luci at gmail.com Fri May 9 16:36:52 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Fri May 9 16:36:55 2008 Subject: Dummynet, gif, and ipsec In-Reply-To: <48247901.3000706@razorfever.net> References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> <48247901.3000706@razorfever.net> Message-ID: <9a542da30805090936l222a58bcy5b926cba01d62ce6@mail.gmail.com> On Fri, May 9, 2008 at 6:17 PM, Derek (freebsd-ipfw) <482254ac@razorfever.net> wrote: > Ermal Lu?i wrote: >> >> Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 >> as you are running. It is another alternative to dummynet though it >> have been tested with pf but should work with ipfw too since it knows >> about ALTQ. >> Hope it helps! >> > > Hi Ermal, > > Thanks for the response! > > I'm looking to roll this out on 5-7 machines, so I'm really looking for a > solution where we wouldn't have to make changes to the kernel code and would > be supported by the base system moving forward. > > Are you planning to submit a PR with this patch? > > Also are the m_tag, or altq_tag the same tags created with the ipfw tag > command? > As far as i am aware this should be transparent to ipfw. Meaning it should work since ipfw speaks ALTQ tags so no problems should arise. It is in use in production machines as a patch so you can be sure it works reliably. I can submit the PR but i think it is better if somebody with ipsec competence comments about its eligibility. I CC'd freebsd-net@ so somebody will speak for this more rather than place it on PR that nobody would look at. Ermal > -- Derek > From sam at FreeBSD.org Fri May 9 17:12:17 2008 From: sam at FreeBSD.org (sam@FreeBSD.org) Date: Fri May 9 17:12:20 2008 Subject: kern/123552: [ath] [panic] kernel panic during network activity on ath0 Message-ID: <200805091712.m49HCGgn074352@freefall.freebsd.org> Synopsis: [ath] [panic] kernel panic during network activity on ath0 State-Changed-From-To: open->feedback State-Changed-By: sam State-Changed-When: Fri May 9 17:10:24 UTC 2008 State-Changed-Why: need system and network configuration at a minimum Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Fri May 9 17:10:24 UTC 2008 Responsible-Changed-Why: need system and network configuration at a minimum; e.g. provide a dmesg and the output of ifconfig http://www.freebsd.org/cgi/query-pr.cgi?pr=123552 From jhb at freebsd.org Fri May 9 17:55:24 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri May 9 17:55:29 2008 Subject: Small patch.. In-Reply-To: <48237F1A.6020601@freebsd.org> References: <200805081625.33093.jhb@FreeBSD.org> <48237F1A.6020601@freebsd.org> Message-ID: <200805091207.05611.jhb@freebsd.org> On Thursday 08 May 2008 06:30:50 pm Andre Oppermann wrote: > John Baldwin wrote: > > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > > while doing so ran into this case. Specifically, it doesn't actually bump > > sysctl net.inet.tcp.log_debug=0 is simpler than #if 0 and has the same effect. > In RELENG_7 it was disabled by default. That doesn't shut up log(LOG_DEBUG). That is controlled by syslog settings. Trust me. We enable more crap in syslog at work which is why we were inundated. net.inet.tcp.log_debug was already 0. -- John Baldwin From ccowart at rescomp.berkeley.edu Fri May 9 18:18:53 2008 From: ccowart at rescomp.berkeley.edu (Christopher Cowart) Date: Fri May 9 18:18:56 2008 Subject: carp and vlan interfaces recovery issue Message-ID: <20080509180152.GV89055@hal.rescomp.berkeley.edu> Hello, I have the following configuration: box1:/etc/rc.conf: | ifconfig_bge1="up" | ifconfig_vlan95="inet 10.9.128.2/20 vlan 95 vlandev bge1" | ifconfig_carp15="inet 10.9.128.1/32 vhid 15 pass secret advskew 100" | ifconfig_carp25="inet 10.9.128.1/32 vhid 25 pass secret" box2:/etc/rc.conf: | ifconfig_fxp0="up" | ifconfig_vlan95="inet 10.9.128.3/20 vlan 95 vlandev fxp1" | ifconfig_carp15="inet 10.9.128.1/32 vhid 15 pass secret" | ifconfig_carp25="inet 10.9.128.1/32 vhid 25 pass secret advskew 100" /etc/sysct.conf: | net.inet.carp.arpbalance=1 Output from ifconfig: box1: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 0 box2: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: BACKUP vhid 25 advbase 1 advskew 100 Then, on box 1, I `ifconfig vlan95 down'. Updated output from ifconfig: box1: | carp15: flags=8 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: INIT vhid 15 advbase 1 advskew 100 | carp25: flags=8 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: INIT vhid 25 advbase 1 advskew 0 box2: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 100 Then, on box 1, I `ifconfig vlan95 up'. Again: box1: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: BACKUP vhid 25 advbase 1 advskew 0 box2: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 100 Notice that both carp interfaces are running in "BACKUP" mode on box1, even after some period of waiting. I would expect things to return to the initial state. If I `tcpdump -i vlan95 vrrp' on both boxes at this point, I see: | 10:57:20.502188 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement, | vrid 15, prio 0, authtype none, intvl 1s, length 36 | 10:57:21.503211 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement, | vrid 15, prio 0, authtype none, intvl 1s, length 36 | 10:57:21.537201 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement, | vrid 25, prio 100, authtype none, intvl 1s, length 36 | 10:57:22.504234 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement, | vrid 15, prio 0, authtype none, intvl 1s, length 36 Note that box1 (10.9.128.2) isn't sending any advertisements. If I use the physical interface, not the vlan interface `ifconfig bge1 down' on box1: box1: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 15 advbase 1 advskew 100 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 0 box2: | carp16: flags=49 metric 0 mtu 1500 | inet 10.9.144.1 netmask 0xffffffff | carp: MASTER vhid 16 advbase 1 advskew 0 | carp26: flags=49 metric 0 mtu 1500 | inet 10.9.144.1 netmask 0xffffffff | carp: MASTER vhid 26 advbase 1 advskew 100 And finally, `ifconfig bge1 up' on box1: | carp15: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 0 Things return to where they should be. Is this a bug? -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080509/a24553ac/attachment.pgp From fox at verio.net Fri May 9 18:46:12 2008 From: fox at verio.net (David DeSimone) Date: Fri May 9 18:46:18 2008 Subject: carp and vlan interfaces recovery issue In-Reply-To: <20080509180152.GV89055@hal.rescomp.berkeley.edu> References: <20080509180152.GV89055@hal.rescomp.berkeley.edu> Message-ID: <20080509184610.GB30415@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Cowart wrote: > > Notice that both carp interfaces are running in "BACKUP" mode on box1, > even after some period of waiting. I would expect things to return to > the initial state. net.inet.carp.preempt=1 ? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIJJvyFSrKRjX5eCoRAoZSAJ9s7sDYTJA+9xJpxjdhJLSkkH9+IQCgk4dE S8UuiFOsNid0Ow9W1PFptEs= =GSdm -----END PGP SIGNATURE----- From ccowart at rescomp.berkeley.edu Fri May 9 19:13:50 2008 From: ccowart at rescomp.berkeley.edu (Christopher Cowart) Date: Fri May 9 19:13:54 2008 Subject: carp and vlan interfaces recovery issue In-Reply-To: <20080509184610.GB30415@verio.net> References: <20080509180152.GV89055@hal.rescomp.berkeley.edu> <20080509184610.GB30415@verio.net> Message-ID: <20080509191350.GW89055@hal.rescomp.berkeley.edu> David DeSimone wrote: > Christopher Cowart wrote: > > > > Notice that both carp interfaces are running in "BACKUP" mode on box1, > > even after some period of waiting. I would expect things to return to > > the initial state. > > net.inet.carp.preempt=1 ? They return to the initial states when I perform the down/up on the physical parent interface without turning on preempt. My point was the behavior when moving a vlan from down to up is different from moving the physical interface from down to up; I don't think they should be. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080509/9876f6be/attachment.pgp From tim at gebbettco.com Sat May 10 09:08:44 2008 From: tim at gebbettco.com (Tim Gebbett) Date: Sat May 10 09:08:48 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <4824211C.9090105@freebsd.org> References: <4822BABB.4020407@freebsd.org> <4824211C.9090105@freebsd.org> Message-ID: <482561F3.6080701@gebbettco.com> Hi Andre, did some careful testing yesterday and last night. I seem to be still hitting an unknown buffer although the probem is much alleviated. The system achieved a 7hour run at 500mbit where ETIMEDOUT occured. I was feeding 11 other streams to the server whos counters show an uninterrupted eleven hours. The feeder streams are from the same source, so it is unlikely that the one feeding the test could of had a problem without affecting the counters of the others. sysctls are: (loader.conf) hw.em.txd=4096 net.inet.tcp.sendspace=78840 net.inet.tcp.recvspace=78840 kern.ipc.nmbjumbop=51200 kern.ipc.nmbclusters=78840 kern.maxfiles=50000 IP stats are miraculously improved, going from a 10% packet loss within stack (output drops) to a consistent zero at peaks of 80000 pps. I believe the problem is now being shunted to the NIC from the following output: dev.em.0.debug=1 < em0: Adapter hardware address = 0xc520b224 < em0: CTRL = 0x48f00249 RCTL = 0x8002 < em0: Packet buffer = Tx=16k Rx=48k < em0: Flow control watermarks high = 47104 low = 45604 < em0: tx_int_delay = 66, tx_abs_int_delay = 66 < em0: rx_int_delay = 0, rx_abs_int_delay = 66 < em0: fifo workaround = 0, fifo_reset_count = 0 < em0: hw tdh = 3285, hw tdt = 3285 < em0: hw rdh = 201, hw rdt = 200 < em0: Num Tx descriptors avail = 4096 < em0: Tx Descriptors not avail1 = 4591225 < em0: Tx Descriptors not avail2 = 0 < em0: Std mbuf failed = 0 < em0: Std mbuf cluster failed = 0 < em0: Driver dropped packets = 0 < em0: Driver tx dma failure in encap = 0 dev.em.0.stats=1 < em0: Excessive collisions = 0 < em0: Sequence errors = 0 < em0: Defer count = 0 < em0: Missed Packets = 16581181 < em0: Receive No Buffers = 74605555 < em0: Receive Length Errors = 0 < em0: Receive errors = 0 < em0: Crc errors = 0 < em0: Alignment errors = 0 < em0: Collision/Carrier extension errors = 0 < em0: RX overruns = 289717 < em0: watchdog timeouts = 0 < em0: XON Rcvd = 0 < em0: XON Xmtd = 0 < em0: XOFF Rcvd = 0 < em0: XOFF Xmtd = 0 < em0: Good Packets Rcvd = 848158221 < em0: Good Packets Xmtd = 1080368640 < em0: TSO Contexts Xmtd = 0 < em0: TSO Contexts Failed = 0 Does the counter 'Tx Descriptors not avail1' indicate lack of decriptors at the time not available, and would this be symptomatic of something Mark suggested: "(the stack) needs to handle local buffer fills not as a failed attempt on transmission that increments the retry counter, a possible better strategy required for backoff when the hardware buffer is full?" Thanks for your continued time and effort - Tim Andre Oppermann wrote: > Tim Gebbett wrote: >> Hi all, >> >> applied the patch, >> >> Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug >> started venting massive >> quantities of tcp_output error 55 while sending with syncache noise: > > The error seems to be coming from the interface send queue which hits > the limit. > If you are using em(4) network interface please add this line to > loader.conf(5): > > hw.em.txd=1024 > > Or even more if problems persist. The maximum is 4096. > From oleksandr at samoylyk.sumy.ua Sat May 10 14:39:30 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 14:39:35 2008 Subject: Problems with netgraph In-Reply-To: <4825B177.7020503@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> Message-ID: <4825B397.4060005@samoylyk.sumy.ua> Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> this may be the issue: >>> http://www.nabble.com/GRE-Mux-td16201899.html >> >> I think so. Should we hope for some progress in this direction in future? > > This is not an issue any more for mpd. > Originally multiplexing based on peers addresses by socket binding and > connecting was used. There was only problem with multiplexing multiple > calls inside the same tunnel (having the same peer addresses). > Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved > ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and > the latest mpd-5.1 is able to use this feature when it is present at a > build time. > * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 08:01:26 mav Exp $ -- Oleksandr Samoylyk OVS-RIPE From mav at FreeBSD.org Sat May 10 14:55:25 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 10 14:55:28 2008 Subject: Problems with netgraph In-Reply-To: <4825B397.4060005@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> Message-ID: <4825B75B.9050604@FreeBSD.org> Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Oleksandr Samoylyk wrote: >>> Julian Elischer wrote: >>>> this may be the issue: >>>> http://www.nabble.com/GRE-Mux-td16201899.html >>> >>> I think so. Should we hope for some progress in this direction in >>> future? >> >> This is not an issue any more for mpd. >> Originally multiplexing based on peers addresses by socket binding and >> connecting was used. There was only problem with multiplexing multiple >> calls inside the same tunnel (having the same peer addresses). >> Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved >> ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and >> the latest mpd-5.1 is able to use this feature when it is present at a >> build time. >> > > * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 > 08:01:26 mav Exp $ As I can see you have build mpd before system build. Probably mpd was built on a system without this feature present yet: # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root at xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Try to rebuild mpd to be sure it uses this feature. Also you can check this by observing the name of any ng_pptpgre hook used. If it is "upper", then ng_pptpgre multiplexing is not used and if it is "session_hhhh" then OK. -- Alexander Motin From oleksandr at samoylyk.sumy.ua Sat May 10 15:00:32 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 15:00:37 2008 Subject: Problems with netgraph In-Reply-To: <4825B75B.9050604@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> Message-ID: <4825B884.9030009@samoylyk.sumy.ua> Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> Julian Elischer wrote: >>>>> this may be the issue: >>>>> http://www.nabble.com/GRE-Mux-td16201899.html >>>> >>>> I think so. Should we hope for some progress in this direction in >>>> future? >>> >>> This is not an issue any more for mpd. >>> Originally multiplexing based on peers addresses by socket binding >>> and connecting was used. There was only problem with multiplexing >>> multiple calls inside the same tunnel (having the same peer addresses). >>> Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved >>> ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and >>> the latest mpd-5.1 is able to use this feature when it is present at >>> a build time. >>> >> >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 >> 08:01:26 mav Exp $ > > As I can see you have build mpd before system build. Probably mpd was > built on a system without this feature present yet: > > # uname -a > FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 > 12:40:02 EEST 2008 > xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 > > # mpd5 -v > Version 5.1 (root at xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > I just tried to rebuild it one more time: # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon May 5 01:11:23 EEST 2008 xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (xxxxx at xxx.xxxxxxxxx.xxx 17:38 10-May-2008) # /usr/local/etc/rc.d/mpd5 restart Stopping mpd5. Waiting for PIDS: 604, 604, 604, 604, 604, 604, 604. Starting mpd5. I'll see if anything will change. -- Oleksandr Samoylyk OVS-RIPE From mav at FreeBSD.org Sat May 10 15:30:18 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 10 15:30:30 2008 Subject: Problems with netgraph In-Reply-To: <1210209785.00067436.1210197002@10.7.7.3> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> Message-ID: <4825B177.7020503@FreeBSD.org> Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> this may be the issue: >> http://www.nabble.com/GRE-Mux-td16201899.html > > I think so. Should we hope for some progress in this direction in future? This is not an issue any more for mpd. Originally multiplexing based on peers addresses by socket binding and connecting was used. There was only problem with multiplexing multiple calls inside the same tunnel (having the same peer addresses). Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and the latest mpd-5.1 is able to use this feature when it is present at a build time. -- Alexander Motin From oleksandr at samoylyk.sumy.ua Sat May 10 16:10:51 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 16:10:54 2008 Subject: Problems with netgraph In-Reply-To: <4825B75B.9050604@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> Message-ID: <4825C8E3.5020501@samoylyk.sumy.ua> Alexander Motin wrote: > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > I can't even list all nodes. # ngctl list ngctl: send msg: No buffer space available # sysctl -a | grep graph net.graph.msg_version: 8 net.graph.abi_version: 11 net.graph.maxdata: 512 net.graph.maxalloc: 4096 net.graph.control.proto: 2 net.graph.data.proto: 1 net.graph.family: 32 net.graph.recvspace: 128000 net.graph.maxdgram: 128000 Any other way to check? -- Oleksandr Samoylyk OVS-RIPE From mav at FreeBSD.org Sat May 10 16:15:52 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 10 16:15:57 2008 Subject: Problems with netgraph In-Reply-To: <4825C8E3.5020501@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825C8E3.5020501@samoylyk.sumy.ua> Message-ID: <4825CA33.4040106@FreeBSD.org> Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Try to rebuild mpd to be sure it uses this feature. Also you can check >> this by observing the name of any ng_pptpgre hook used. If it is >> "upper", then ng_pptpgre multiplexing is not used and if it is >> "session_hhhh" then OK. > > I can't even list all nodes. > > # ngctl list > ngctl: send msg: No buffer space available Nodes list can be big. This should help you to get it: kern.ipc.maxsockbuf=1048576 net.graph.maxdgram=524288 net.graph.recvspace=524288 -- Alexander Motin From oleksandr at samoylyk.sumy.ua Sat May 10 16:31:15 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 16:31:22 2008 Subject: Problems with netgraph In-Reply-To: <4825B75B.9050604@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> Message-ID: <4825CDCA.5020607@samoylyk.sumy.ua> Alexander Motin wrote: > > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > # ngctl show mpd24375-L-237-lt: Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd24375-B-607 ppp 0008e922 link0 left pptpgre 0008e91b upper It's "upper". And I don't know why :( The sources were updated before building new kernel on May, 5, 2008. The mpd5 port was rebuilt and restarted just few hours ago. -- Oleksandr Samoylyk OVS-RIPE From guru at Sisis.de Sat May 10 16:38:07 2008 From: guru at Sisis.de (Matthias Apitz) Date: Sat May 10 16:38:25 2008 Subject: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R In-Reply-To: References: <20080509123521.GA11366@rebelion.Sisis.de> Message-ID: <20080510163417.GA17718@rebelion.Sisis.de> El d?a Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribi?: > > Stevens explains further more that client and server could handshake to > > omit the constant flag (7e) and adress field (ff) and reduce the > > protocol field (0021) to one byte (21), but in the above packages 'flag' is there > > while 'addr' and 'control' are missing? > > > > any PPP expert here to explain this? could this be the reason that the > > connection gets stuck? > > Probably not the sort of help you wanted, and I'm no PPP expert, but > having run ppp(8) in and out for ten years and more recently mpd(8) > outbound, I have to ask, does this gig depend on using pppd? ... I've checked a short moment mpd5(8) (installed it from the ports and checked the manual about configuration); it seems that it would me take some time to get the CHAT part working; because, on the other hand, my installed pppd(8) works just fine, with older UMTS cards, I don't think that this is the problem; I've spent some more hours as well on debugging and now I have it clear a) what the problem is with the TCP packages b) why LCP works just nicely c) why CHAT works as well nicely d) why telneting to the ECHO port works also if (and only if) you enter only a few characters on the line, say up to five the problem is the size of the buffer coming down from user space in the nzstart() function: ... data = tty->t_outq.c_cf; cbp = (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND); cnt = min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc); if(cnt == 0) goto out; buf = malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT); memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf->data)); buf->size = cnt; printf("nzdebug: nzstart() -> STAILQ_INSERT_TAIL() of %d bytes\n", cnt); STAILQ_INSERT_TAIL(&fifo_head, buf, fifo_bufs); ndflush(&tty->t_outq, cnt); intr_ul(sc, pidx, ENABLE); ... I saw frames upto 108 bytes length; and later send_data(), which puts the data into the card's buffer, picks the data up like this: buf = STAILQ_FIRST(&fifo_head); size = buf->size; memcpy(sc->send_buf, buf->data, ul_size < SEND_BUF_MAX ? ul_size : SEND_BUF_MAX ); STAILQ_REMOVE_HEAD(&fifo_head, fifo_bufs); free(buf, M_DEVBUF); port->tx_data += size; /* Write length + data */ bus_write_4(sc->res, ul_offs, size); bus_write_region_4(sc->res, ul_offs + 4, (u_int32_t *)sc->send_buf, size); SEND_BUF_MAX is 1024 but the 'ul_size' (size of the up link part of the card) is only 68!! that's why parts of the PPP frames are just thrown away if the frame size is bigger than 64 (4 bytes are needed for the size); I got to know this comparing the hex dumps of the buffer in the nzstart() and send_data() parts; at the moment I have no idea how to fix this :-(( I've put the driver here: http://www.unixarea.de/nozomi/nozomi.c if someone wants to have a look and give me some hint; thanks in advance; it's Saturday evening and sunny, time for go out... matthias From mav at FreeBSD.org Sat May 10 16:51:21 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 10 16:51:25 2008 Subject: Problems with netgraph In-Reply-To: <4825CDCA.5020607@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> Message-ID: <4825D280.9080807@FreeBSD.org> Oleksandr Samoylyk wrote: > # ngctl show mpd24375-L-237-lt: > Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > right mpd24375-B-607 ppp 0008e922 link0 > left pptpgre 0008e91b upper > > It's "upper". And I don't know why :( > The sources were updated before building new kernel on May, 5, 2008. > The mpd5 port was rebuilt and restarted just few hours ago. Here is mine: %ngctl show mpd95052-L2-4-lt: Name: mpd95052-L2-4-lt Type: tee ID: 000000eb Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd95052-B1-1 ppp 000000f0 link0 left pptpgre 000000ed session_b826 Have you updated your world also? Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from /usr/include/netgraph/ng_pptpgre.h at the build time to detect this feature presence. One more way to check this feature in mpd-5.1: Without this feature: # grep "PPTP: can't connect to" mpd5 # With this feature present: # grep "PPTP: can't connect to" mpd5 Binary file mpd5 matches # -- Alexander Motin From oleksandr at samoylyk.sumy.ua Sat May 10 17:01:43 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 17:01:56 2008 Subject: Problems with netgraph In-Reply-To: <4825D280.9080807@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> Message-ID: <4825D4EE.2060006@samoylyk.sumy.ua> Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> # ngctl show mpd24375-L-237-lt: >> Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num >> hooks: 2 >> Local hook Peer name Peer type Peer ID Peer hook >> ---------- --------- --------- ------- --------- >> right mpd24375-B-607 ppp 0008e922 link0 >> left pptpgre 0008e91b upper >> >> It's "upper". And I don't know why :( >> The sources were updated before building new kernel on May, 5, 2008. >> The mpd5 port was rebuilt and restarted just few hours ago. > > Here is mine: > %ngctl show mpd95052-L2-4-lt: > Name: mpd95052-L2-4-lt Type: tee ID: 000000eb Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > right mpd95052-B1-1 ppp 000000f0 link0 > left pptpgre 000000ed session_b826 > > Have you updated your world also? No, just kernel. Should I? > Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from /usr/include/netgraph/ng_pptpgre.h at the build time to detect this feature presence. # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 imp Exp $ > One more way to check this feature in mpd-5.1: > Without this feature: > # grep "PPTP: can't connect to" mpd5 > # > With this feature present: > # grep "PPTP: can't connect to" mpd5 > Binary file mpd5 matches > # > # cd /usr/local/sbin/ # grep "PPTP: can't connect to" mpd5 # -- Oleksandr Samoylyk OVS-RIPE From nike_d at cytexbg.com Sat May 10 17:08:01 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Sat May 10 17:08:03 2008 Subject: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R In-Reply-To: <20080510163417.GA17718@rebelion.Sisis.de> References: <20080509123521.GA11366@rebelion.Sisis.de> <20080510163417.GA17718@rebelion.Sisis.de> Message-ID: <2e77fc10805101008ybafe7b3g8b9210cb8d2955d@mail.gmail.com> On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz wrote: > El d?a Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribi?: > >> > Stevens explains further more that client and server could handshake to >> > omit the constant flag (7e) and adress field (ff) and reduce the >> > protocol field (0021) to one byte (21), but in the above packages 'flag' is there >> > while 'addr' and 'control' are missing? >> > >> > any PPP expert here to explain this? could this be the reason that the >> > connection gets stuck? >> >> Probably not the sort of help you wanted, and I'm no PPP expert, but >> having run ppp(8) in and out for ten years and more recently mpd(8) >> outbound, I have to ask, does this gig depend on using pppd? > ... > > I've checked a short moment mpd5(8) (installed it from the ports and > checked the manual about configuration); it seems that it would me take > some time to get the CHAT part working; > > because, on the other hand, my installed pppd(8) works just fine, > with older UMTS cards, I don't think that this is the problem; > > I've spent some more hours as well on debugging and now I have it clear > a) what the problem is with the TCP packages > b) why LCP works just nicely > c) why CHAT works as well nicely > d) why telneting to the ECHO port works also if (and only if) you enter > only a few characters on the line, say up to five > > the problem is the size of the buffer coming down from user space in the > nzstart() function: > > ... > data = tty->t_outq.c_cf; > cbp = (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND); > cnt = min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc); > > if(cnt == 0) > goto out; > > buf = malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT); > memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf->data)); > buf->size = cnt; > > printf("nzdebug: nzstart() -> STAILQ_INSERT_TAIL() of %d bytes\n", cnt); > STAILQ_INSERT_TAIL(&fifo_head, buf, fifo_bufs); > ndflush(&tty->t_outq, cnt); > intr_ul(sc, pidx, ENABLE); > ... > > I saw frames upto 108 bytes length; > > and later send_data(), which puts the data into the card's buffer, picks > the data up like this: > > buf = STAILQ_FIRST(&fifo_head); > size = buf->size; > > memcpy(sc->send_buf, buf->data, ul_size < SEND_BUF_MAX ? ul_size : SEND_BUF_MAX ); > > STAILQ_REMOVE_HEAD(&fifo_head, fifo_bufs); > free(buf, M_DEVBUF); > > port->tx_data += size; > > /* Write length + data */ > bus_write_4(sc->res, ul_offs, size); > bus_write_region_4(sc->res, ul_offs + 4, (u_int32_t *)sc->send_buf, size); > > SEND_BUF_MAX is 1024 but the 'ul_size' (size of the up link part of the > card) is only 68!! that's why parts of the PPP frames are just thrown > away if the frame size is bigger than 64 (4 bytes are needed for the > size); I got to know this comparing the hex dumps of the buffer in the > nzstart() and send_data() parts; > > at the moment I have no idea how to fix this :-(( > I've put the driver here: > > http://www.unixarea.de/nozomi/nozomi.c > > if someone wants to have a look and give me some hint; thanks in advance; > > it's Saturday evening and sunny, time for go out... > > matthias > I can see that this is the initial port of the Linux nozomi driver that i did back in 2006, and i got stuck exactly with the same problem, ppp connection get's established, but only small packets are passed. I will see if I can get my hands on this HSDPA/UMTS card (i don't have it anymore) and help. Niki From mav at FreeBSD.org Sat May 10 17:24:24 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 10 17:24:29 2008 Subject: Problems with netgraph In-Reply-To: <4825D4EE.2060006@samoylyk.sumy.ua> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> Message-ID: <4825DA46.1090400@FreeBSD.org> Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Oleksandr Samoylyk wrote: >>> It's "upper". And I don't know why :( >>> The sources were updated before building new kernel on May, 5, 2008. >>> The mpd5 port was rebuilt and restarted just few hours ago. >> >> Have you updated your world also? > > No, just kernel. Should I? In my experience it is sane to keep kernel and the world in sync. Even if binary compatibility is declared inside the same branch, there could be some minorities like this one. Also it may be hard for developers to track all possible kernel/world combinations. >> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >> feature presence. > > # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 imp > Exp $ HEAD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 mav Exp $ RELENG_7: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 08:01:26 mav Exp $ RELENG_6: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 mav Exp $ -- Alexander Motin From oleksandr at samoylyk.sumy.ua Sat May 10 17:28:11 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sat May 10 17:28:15 2008 Subject: Problems with netgraph In-Reply-To: <4825DA46.1090400@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> <4825DA46.1090400@FreeBSD.org> Message-ID: <4825DB21.3050902@samoylyk.sumy.ua> Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> It's "upper". And I don't know why :( >>>> The sources were updated before building new kernel on May, 5, 2008. >>>> The mpd5 port was rebuilt and restarted just few hours ago. >>> >>> Have you updated your world also? >> >> No, just kernel. Should I? > > In my experience it is sane to keep kernel and the world in sync. Even > if binary compatibility is declared inside the same branch, there could > be some minorities like this one. Also it may be hard for developers to > track all possible kernel/world combinations. > >>> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >>> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >>> feature presence. >> >> # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 >> imp Exp $ > > HEAD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 > mav Exp $ > RELENG_7: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 > 08:01:26 mav Exp $ > RELENG_6: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 > mav Exp $ > Ok, I'll update and rebuild kernel, world and mpd5 and write you back with results. -- Oleksandr Samoylyk OVS-RIPE From jay at jcornwall.me.uk Sat May 10 19:11:55 2008 From: jay at jcornwall.me.uk (Jay L. T. Cornwall) Date: Sat May 10 19:12:00 2008 Subject: if_bridge with two subnets Message-ID: <4825EF8D.1050304@jcornwall.me.uk> Hi, I have an if_bridge, thus: bridge0: flags=8843 metric 0 mtu 1500 inet XX.XX.XXX.20 netmask 0xfffffff8 broadcast XX.XX.XXX.23 inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 On one side of the bridge is a layer 2 switch with clients of a mix of addresses from these two subnets. On the other side is a gateway XX.XX.XXX.22. All clients can communicate through the gateway correctly, with the 192.168.1.x subnet being NAT'd. However, clients from one subnet cannot communicate with clients from the other subnet. Pinging a 192.168.1.X machine from the other subnet shows the packet incorrectly routed out through the gateway, not back through the interface it came. The routing table shows that both subnets should be routed through the bridge: XX.XX.XXX.XX/29 link#5 UC 0 0 bridge 192.168.1.0/24 link#5 UC 0 0 bridge The bridge host itself can ping machines on both subnets. So why is the if_bridge routing packets destined for the private subnet out through the default route instead? (The specific hosts being pinged are present in the routing table from ARP lookups. They are all destined for the bridge interface.) -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From linimon at FreeBSD.org Sat May 10 20:08:11 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 10 20:08:12 2008 Subject: kern/123559: [iwi] iwi periodically disassociates/associates [regression] Message-ID: <200805102008.m4AK8Aou018380@freefall.freebsd.org> Old Synopsis: iwi periodically disassociates/assotiates New Synopsis: [iwi] iwi periodically disassociates/associates [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 10 20:07:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123559 From oleksandr at samoylyk.sumy.ua Sun May 11 05:48:01 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 11 05:48:04 2008 Subject: Problems with netgraph In-Reply-To: <4825DA46.1090400@FreeBSD.org> References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> <4825DA46.1090400@FreeBSD.org> Message-ID: <48268881.4070504@samoylyk.sumy.ua> Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> It's "upper". And I don't know why :( >>>> The sources were updated before building new kernel on May, 5, 2008. >>>> The mpd5 port was rebuilt and restarted just few hours ago. >>> >>> Have you updated your world also? >> >> No, just kernel. Should I? > > In my experience it is sane to keep kernel and the world in sync. Even > if binary compatibility is declared inside the same branch, there could > be some minorities like this one. Also it may be hard for developers to > track all possible kernel/world combinations. > >>> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >>> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >>> feature presence. >> >> # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 >> imp Exp $ > > HEAD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 > mav Exp $ > RELENG_7: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 > 08:01:26 mav Exp $ > RELENG_6: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 > mav Exp $ > Thanks for the tip! I got it working. Let's see if the load changes. # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 08:01:26 mav Exp $ # ngctl show mpd5909-L-1-lt: Name: mpd5909-L-1-lt Type: tee ID: 00000256 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd5909-B-1 ppp 00000267 link0 left pptpgre 00000258 session_6492 # grep "PPTP: can't connect to" mpd5 Binary file mpd5 matches -- Oleksandr Samoylyk OVS-RIPE From is at rambler-co.ru Sun May 11 09:21:39 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Sun May 11 09:21:43 2008 Subject: Multiple routing tables in action... In-Reply-To: <481772C7.8090300@elischer.org> References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <48176C65.4080600@gtcomm.net> <481772C7.8090300@elischer.org> Message-ID: <20080511092046.GC79358@rambler-co.ru> On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote: > >Then you can export RIB entries , say > >you have 5 BGP peers and you want to export 2 or 3 or all of them into > >the 'main' routing instance you can set up a policy to add those learned > >routes into the main instance and v-v. > >Linux behaves a little bit differently as you have to make an 'ip rule' > >entry for it but it doesn't use the firewall. > > for now this code asks you to use a firewall to classify incoming > packets.. > > e.g. > 100 setfib 2 ip from any to any in recv em0 Is is possible to extend ifconfig to classify incoming packets ? -- Igor Sysoev http://sysoev.ru/en/ From julian at elischer.org Sun May 11 09:42:13 2008 From: julian at elischer.org (Julian Elischer) Date: Sun May 11 09:42:18 2008 Subject: Multiple routing tables in action... In-Reply-To: <20080511092046.GC79358@rambler-co.ru> References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <48176C65.4080600@gtcomm.net> <481772C7.8090300@elischer.org> <20080511092046.GC79358@rambler-co.ru> Message-ID: <4826BF74.3030204@elischer.org> Igor Sysoev wrote: > On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote: > >>> Then you can export RIB entries , say >>> you have 5 BGP peers and you want to export 2 or 3 or all of them into >>> the 'main' routing instance you can set up a policy to add those learned >>> routes into the main instance and v-v. >>> Linux behaves a little bit differently as you have to make an 'ip rule' >>> entry for it but it doesn't use the firewall. >> for now this code asks you to use a firewall to classify incoming >> packets.. >> >> e.g. >> 100 setfib 2 ip from any to any in recv em0 > > Is is possible to extend ifconfig to classify incoming packets ? > > You could assign a default fib for all packets received by an interface and that is on my list of things to look at doing later. In the meantime you can use ipfw and pf to assign fibs to incoming packets depending on the receive interface. From fazaeli at sepehrs.com Sun May 11 13:18:12 2008 From: fazaeli at sepehrs.com (H.fazaeli) Date: Sun May 11 13:18:16 2008 Subject: if_bridge with two subnets In-Reply-To: <4825EF8D.1050304@jcornwall.me.uk> References: <4825EF8D.1050304@jcornwall.me.uk> Message-ID: <4826EB42.104@sepehrs.com> The bridge works as it should: It receives packets from XX.XX.XXX.YYY on the interface connected to the switch, and forwards them on the interface connected to the gateway. The problem is that forwarding between subnets is the responsibility of your switch. The switch does its job, but since the two clients are not on the same IP subnet, they can not reach each other w/o the help of an intermediate router. Jay L. T. Cornwall wrote: > Hi, > > I have an if_bridge, thus: > > bridge0: flags=8843 metric 0 > mtu 1500 > inet XX.XX.XXX.20 netmask 0xfffffff8 broadcast XX.XX.XXX.23 > inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 > > On one side of the bridge is a layer 2 switch with clients of a mix of > addresses from these two subnets. On the other side is a gateway > XX.XX.XXX.22. All clients can communicate through the gateway > correctly, with the 192.168.1.x subnet being NAT'd. > > However, clients from one subnet cannot communicate with clients from > the other subnet. Pinging a 192.168.1.X machine from the other subnet > shows the packet incorrectly routed out through the gateway, not back > through the interface it came. > > The routing table shows that both subnets should be routed through the > bridge: > > XX.XX.XXX.XX/29 link#5 UC 0 0 bridge > 192.168.1.0/24 link#5 UC 0 0 bridge > > The bridge host itself can ping machines on both subnets. So why is > the if_bridge routing packets destined for the private subnet out > through the default route instead? > > (The specific hosts being pinged are present in the routing table from > ARP lookups. They are all destined for the bridge interface.) > -- With best regards. Hooman Fazaeli Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From jay at jcornwall.me.uk Sun May 11 19:52:15 2008 From: jay at jcornwall.me.uk (Jay L. T. Cornwall) Date: Sun May 11 19:52:18 2008 Subject: if_bridge with two subnets In-Reply-To: <4826EB42.104@sepehrs.com> References: <4825EF8D.1050304@jcornwall.me.uk> <4826EB42.104@sepehrs.com> Message-ID: <48274E6D.9060704@jcornwall.me.uk> H.fazaeli wrote: > The bridge works as it should: It receives packets from > XX.XX.XXX.YYY on the interface connected to the switch, and > forwards them on the interface connected to the gateway. > > The problem is that forwarding between subnets is the responsibility > of your switch. The switch does its job, but since the two clients are > not on the same IP subnet, they can not reach each other w/o the help of > an intermediate router. Perhaps I am mixing up two separate networking concepts. On a machine configured to act as a gateway, I would expect a single interface with more than one subnet to route packets correctly across those subnets. That may not be how it works in practice. If it does not work, I would question why not. If it does work then I would expect the same behaviour on each of a bridge's constituent interfaces? -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From vwe at FreeBSD.org Sun May 11 21:59:08 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun May 11 21:59:10 2008 Subject: bin/123465: [ip6] route(1): route add -inet6 -interface gif0 -proxy mangle ipv6 address Message-ID: <200805112159.m4BLx8s9057471@freefall.freebsd.org> Synopsis: [ip6] route(1): route add -inet6 -interface gif0 -proxy mangle ipv6 address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 11 21:58:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123465 From vwe at FreeBSD.org Sun May 11 23:51:33 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun May 11 23:51:35 2008 Subject: kern/123160: [ip] Panic and reboot at sysctl kern.polling.enable=0 Message-ID: <200805112351.m4BNpXhJ067450@freefall.freebsd.org> Old Synopsis: Panic and reboot at sysctl kern.polling.enable=0 New Synopsis: [ip] Panic and reboot at sysctl kern.polling.enable=0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 11 23:50:18 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123160 From paul at gtcomm.net Mon May 12 06:44:05 2008 From: paul at gtcomm.net (Paul) Date: Mon May 12 06:44:10 2008 Subject: Discrepancy on netstat -w x -I and what Cisco reports Message-ID: <4827E79C.8050608@gtcomm.net> This is very strange.. I can do: netstat -w 10 -I lagg0 input (lagg0) output packets errs bytes packets errs bytes colls 57806 0 41751685 232442 0 51062425 0 56459 0 38341591 225146 0 48865209 0 60687 0 43552946 227987 0 52008241 0 which is roughly 23,000 pps and the Cisco switch reports 30 second input rate 44544000 bits/sec, 16198 packets/sec Another example: netstat -w 10 -I lagg0 input (lagg0) output packets errs bytes packets errs bytes colls 71111 0 52180947 89734 0 25304669 0 66847 0 49028588 81737 0 21614941 0 63530 0 43502418 83419 0 24599547 0 8,300 or so pps Cisco: 30 second input rate 19230000 bits/sec, 4594 packets/sec In some cases it's pretty close, cisco says 6500 and bsd says 7500.. but sometimes it is way off I even checked the em interfaces directly to see if it was a problem with the lagg interface code and they report weird issues, check below. Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue with the counters. It's two different Cisco switches and two fbsd machines that have the same kernel, etc. Maybe this is a side effect of setting my kernel HZ at 4000? Gets even worse like this: netstat -w 100 lagg0 input (Total) output packets errs bytes packets errs bytes colls 9229322 0 3337789024 9424932 0 3510341158 0 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports 2 minute input rate 44130000 bits/sec, 14892 packets/sec and even check this out: netstat -w 1 lagg0 input (Total) output packets errs bytes packets errs bytes colls 92481 0 31630795 94952 0 34193131 0 89078 0 32498082 91460 0 35094821 0 87540 0 34526292 89992 0 37159101 0 88987 0 32391984 91765 0 35394351 0 netstat -w 1 em0 input (Total) output packets errs bytes packets errs bytes colls 96802 0 39474036 99897 0 42814245 0 93277 0 37018533 95943 0 39860879 0 95916 0 37559076 99032 0 40739640 0 netstat -w 1 em1 input (Total) output packets errs bytes packets errs bytes colls 97102 0 38369949 99508 0 40841183 0 92321 0 35375169 94305 0 37384073 0 92225 0 33171455 94253 0 35209658 0 What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k and i KNOW it's not doing anywhere near.. cisco report 2 minute output rate 32928000 bits/sec, 5823 packets/sec Now all lagg interfaces are reporting netstat -w 1 lagg1 input (Total) output packets errs bytes packets errs bytes colls 89324 0 30824353 91518 0 32770482 0 85875 0 31924738 87813 0 33552137 0 84105 0 31176932 85666 0 32393051 0 83617 0 32175677 84871 0 33120271 0 90611 0 37313093 92403 0 38818721 0 lagg1 goes directly to another freebsd box and on the other freebsd box I do: netstat -w 1 -I lagg1 input (lagg1) output packets errs bytes packets errs bytes colls 45 0 3078 2213 0 1890198 0 48 0 3245 1958 0 1545642 0 43 0 3186 1975 0 1628916 0 43 0 2905 2169 0 1918250 0 46 0 3464 1859 0 1729764 0 46 0 3134 1873 0 1739662 0 and the other one netstat -w 1 lagg1 input (Total) output packets errs bytes packets errs bytes colls 92149 0 31706183 93523 0 32673138 0 89737 0 28119643 91323 0 28958816 0 Doing all these reports now seems to have the interfaces stuck at packets errs bytes packets errs bytes colls 96937 0 31749525 98551 0 32678863 0 85892 0 29411078 87233 0 30182355 0 90435 0 31628680 91620 0 32215244 0 87383 0 30616741 88278 0 31026608 0 every interface on the machine is reporting the same PPS and bytes.. lol :) So something is extremely fishy about the counters.. I'm going to try and update to -STABLE to see if it makes any difference. It's not just the lagg interface either because all the em's are showing it as well. This is using 4 port Intel Server PCI Express NIC ifstat seems to report correct usage in Kbps and seems to report correct packet count. Maybe it's just a netstat problem? I will see if stable fixes it. Also, feel free to make any comments on my config file for routing. FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 UPDATE.. Changed 1 router to stable: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 amd64 Still see: 2 minute input rate 10463000 bits/sec, 2481 packets/sec 2 minute output rate 40075000 bits/sec, 6847 packets/sec and input (lagg0) output packets errs bytes packets errs bytes colls 6940 0 5172153 4841 0 1345660 0 5922 0 4252074 3963 0 1087205 0 6673 0 4982394 4116 0 1056933 0 6659 0 4467398 4140 0 1068919 0 7085 0 4692973 4777 0 1665109 0 7140 0 4654486 4713 0 1658303 0 7070 0 4558384 5078 0 1994666 0 6375 0 4575464 4037 0 1121385 0 6257 0 3932910 4321 0 1607862 0 6504 0 4345014 4370 0 1278819 0 Hmmmm.. em0: port 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci12 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:5d:18:00 em0: [FILTER] em1: port 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 on pci12 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:5d:18:01 em1: [FILTER] .......etc.. to em7 Copyright (c) 1992-2008 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 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4285833216 (4087 MB) avail memory = 4124545024 (3933 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 Kernel config file: (if you have any suggestions about the config let me know for faster routing speed) cpu HAMMER ident GENERIC #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler #options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options ADAPTIVE_GIANT # Giant mutex is adaptive. options NO_ADAPTIVE_MUTEXES ## options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options IPSEC ## for tcp md5 options TCP_SIGNATURE ##include support for RFC 2385 device crypto ## for md5 device cryptodev ## for md5 # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers device mfi # LSI MegaRAID SAS # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse ### OPTIONS options MP_WATCHDOG options DEVICE_POLLING device pf device pflog device pfsync device carp device vlan device gre device if_bridge device tun device lagg device stf #6to4 IPv6 over IPv4 encapsulation options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_CDNR options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options NETGRAPH options NETGRAPH_CISCO options NETGRAPH_FEC options NETGRAPH_ETHER Copyright (c) 1992-2008 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 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4286042112 (4087 MB) avail memory = 4124753920 (3933 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 64-87 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard 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 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci6: on pcib1 pcib2: at device 0.0 on pci6 pci7: on pcib2 pcib3: at device 0.0 on pci7 pci8: on pcib3 pcib4: at device 0.0 on pci8 pci9: on pcib4 bce0: mem 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:19:b9:cd:60:44 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) pcib5: at device 1.0 on pci7 pci10: on pcib5 pcib6: at device 0.0 on pci10 pci11: on pcib6 pcib7: at device 0.0 on pci11 pci12: on pcib7 em0: port 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci12 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:5d:2a:40 em1: port 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 on pci12 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:5d:2a:41 pcib8: at device 1.0 on pci11 pci13: on pcib8 em2: port 0xdce0-0xdcff mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:2a:40 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c lagg1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:62 inet netmask 0xfffffffc broadcast media: Ethernet autoselect status: active laggproto lacp laggport: em7 flags=1c laggport: em6 flags=1c lagg2: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:60 media: Ethernet autoselect status: active laggproto lacp laggport: em5 flags=1c laggport: em4 flags=1c From dkramer at coverity.com Mon May 12 09:01:02 2008 From: dkramer at coverity.com (David Kramer) Date: Mon May 12 09:01:06 2008 Subject: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) Message-ID: <482804BF.1090506@coverity.com> **IF this is the wrong list for this topic please let me know which list I should post network services issues to. I am relatively new to FreeBSD but have quite a bit of experience with NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. The type of behavior I am seeing would be common on a Linux machine that uses nssswitch.conf to state which objects to pass authentication through, but its missing the nis value for passwd: or group:. Looking through the FreeBSD website I see that nssswitch was introduced in FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any additional configurations that need to be done? Possibly with PAM? I have the following values in my /etc/rc.conf files: nisdomainname="myNISdomain" nis_client_enable="YES" I have followed the FreeBSD NIS/YP Handbook configuration to the T, and still get the illegal user authentication any insight would be greatly appreciated. Thanks much, DK -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. From stefan.lambrev at moneybookers.com Mon May 12 09:19:36 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon May 12 09:19:41 2008 Subject: Discrepancy on netstat -w x -I and what Cisco reports In-Reply-To: <4827E79C.8050608@gtcomm.net> References: <4827E79C.8050608@gtcomm.net> Message-ID: <48280B97.1020708@moneybookers.com> Greetings, I just have a question: is "netstat -w 100 lagg0" a typo ? If you want to see the traffic only on single interface you should use -I I do not know if this is bug, but netstat -w 100 something_non_existing works on my bsd and just shows "Total" So may be from here comes the confusion. You think, that netstat count only traffic on lagg0, but it shows you the Total traffic? Paul wrote: > This is very strange.. I can do: > > netstat -w 10 -I lagg0 > input (lagg0) output > packets errs bytes packets errs bytes colls > 57806 0 41751685 232442 0 51062425 0 > 56459 0 38341591 225146 0 48865209 0 > 60687 0 43552946 227987 0 52008241 0 > > which is roughly 23,000 pps and the Cisco switch reports > 30 second input rate 44544000 bits/sec, 16198 packets/sec > > > Another example: > > netstat -w 10 -I lagg0 > input (lagg0) output > packets errs bytes packets errs bytes colls > 71111 0 52180947 89734 0 25304669 0 > 66847 0 49028588 81737 0 21614941 0 > 63530 0 43502418 83419 0 24599547 0 > > 8,300 or so pps > > Cisco: > 30 second input rate 19230000 bits/sec, 4594 packets/sec > > > In some cases it's pretty close, cisco says 6500 and bsd says 7500.. > but sometimes it is way off > I even checked the em interfaces directly to see if it was a problem > with the lagg interface code and they report weird issues, check below. > Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue > with the counters. > It's two different Cisco switches and two fbsd machines that have the > same kernel, etc. > > Maybe this is a side effect of setting my kernel HZ at 4000? > Gets even worse like this: > netstat -w 100 lagg0 > input (Total) output > packets errs bytes packets errs bytes colls > 9229322 0 3337789024 9424932 0 3510341158 0 > > 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports > 2 minute input rate 44130000 bits/sec, 14892 packets/sec Again this is Total not lagg0 > and even check this out: > > netstat -w 1 lagg0 > input *(Total) * output > packets errs bytes packets errs bytes colls > 92481 0 31630795 94952 0 34193131 0 > 89078 0 32498082 91460 0 35094821 0 > 87540 0 34526292 89992 0 37159101 0 > 88987 0 32391984 91765 0 35394351 0 > > > netstat -w 1 em0 > input *(Total) * output > packets errs bytes packets errs bytes colls > 96802 0 39474036 99897 0 42814245 0 > 93277 0 37018533 95943 0 39860879 0 > 95916 0 37559076 99032 0 40739640 0 > > netstat -w 1 em1 > input * (Total) * output > packets errs bytes packets errs bytes colls > 97102 0 38369949 99508 0 40841183 0 > 92321 0 35375169 94305 0 37384073 0 > 92225 0 33171455 94253 0 35209658 0 > > What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k > and i KNOW it's not doing anywhere near.. > cisco report > 2 minute output rate 32928000 bits/sec, 5823 packets/sec Again missing -I :) > > Now all lagg interfaces are reporting > netstat -w 1 lagg1 > input * (Total) * output > packets errs bytes packets errs bytes colls > 89324 0 30824353 91518 0 32770482 0 > 85875 0 31924738 87813 0 33552137 0 > 84105 0 31176932 85666 0 32393051 0 > 83617 0 32175677 84871 0 33120271 0 > 90611 0 37313093 92403 0 38818721 0 > > lagg1 goes directly to another freebsd box and on the other freebsd > box I do: > netstat -w 1 -I lagg1 > input (lagg1) output > packets errs bytes packets errs bytes colls > 45 0 3078 2213 0 1890198 0 > 48 0 3245 1958 0 1545642 0 > 43 0 3186 1975 0 1628916 0 > 43 0 2905 2169 0 1918250 0 > 46 0 3464 1859 0 1729764 0 > 46 0 3134 1873 0 1739662 0 > > and the other one > netstat -w 1 lagg1 > input * (Total)* output > packets errs bytes packets errs bytes colls > 92149 0 31706183 93523 0 32673138 0 > 89737 0 28119643 91323 0 28958816 0 > > > Doing all these reports now seems to have the interfaces stuck at > packets errs bytes packets errs bytes colls > 96937 0 31749525 98551 0 32678863 0 > 85892 0 29411078 87233 0 30182355 0 > 90435 0 31628680 91620 0 32215244 0 > 87383 0 30616741 88278 0 31026608 0 > > > every interface on the machine is reporting the same PPS and bytes.. > lol :) > > So something is extremely fishy about the counters.. I'm going to try > and update to -STABLE to see if it makes any difference. It's not > just the lagg interface either because all the em's are showing it as > well. > > This is using 4 port Intel Server PCI Express NIC > > ifstat seems to report correct usage in Kbps and seems to report > correct packet count. Maybe it's just a netstat problem? > > I will see if stable fixes it. Also, feel free to make any comments > on my config file for routing. > > FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 > EDT 2008 amd64 > > > UPDATE.. Changed 1 router to stable: > FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT > 2008 amd64 > > Still see: > 2 minute input rate 10463000 bits/sec, 2481 packets/sec > 2 minute output rate 40075000 bits/sec, 6847 packets/sec > > and > input (lagg0) output > packets errs bytes packets errs bytes colls > 6940 0 5172153 4841 0 1345660 0 > 5922 0 4252074 3963 0 1087205 0 > 6673 0 4982394 4116 0 1056933 0 > 6659 0 4467398 4140 0 1068919 0 > 7085 0 4692973 4777 0 1665109 0 > 7140 0 4654486 4713 0 1658303 0 > 7070 0 4558384 5078 0 1994666 0 > 6375 0 4575464 4037 0 1121385 0 > 6257 0 3932910 4321 0 1607862 0 > 6504 0 4345014 4370 0 1278819 0 > > > Hmmmm.. > > > > > em0: port > 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 > at device 0.0 on pci12 > em0: Using MSI interrupt > em0: Ethernet address: 00:15:17:5d:18:00 > em0: [FILTER] > em1: port > 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 > at device 0.1 on pci12 > em1: Using MSI interrupt > em1: Ethernet address: 00:15:17:5d:18:01 > em1: [FILTER] > .......etc.. to em7 > > > Copyright (c) 1992-2008 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 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4285833216 (4087 MB) > avail memory = 4124545024 (3933 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > > > > Kernel config file: (if you have any suggestions about the config let > me know for faster routing speed) > > cpu HAMMER > ident GENERIC > > #makeoptions DEBUG=-g # Build kernel with gdb(1) > debug symbols > > options SCHED_4BSD # 4BSD scheduler > #options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control > lists > options UFS_DIRHASH # Improve performance on big > directories > options UFS_GJOURNAL # Enable gjournal-based UFS > journaling > options MD_ROOT # MD is a potential root device > options NTFS # NT File System > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires > PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options SCSI_DELAY=5000 # Delay (in ms) before probing > SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > options NO_ADAPTIVE_MUTEXES ## > options STOP_NMI # Stop CPUS using NMI instead > of IPI > options AUDIT # Security event auditing > options IPSEC ## for tcp md5 > options TCP_SIGNATURE ##include support for RFC 2385 > device crypto ## for md5 > device cryptodev ## for md5 > > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor Kernel > > # CPU frequency control > device cpufreq > > # Bus support. > device acpi > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and > SAF-TE) > > # RAID controllers > device mfi # LSI MegaRAID SAS > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > device uart # Generic UART driver > > # PCI Ethernet NICs. > device em # Intel PRO/1000 adapter Gigabit > Ethernet Card > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these > NICs! > device miibus > device bce # Broadcom BCM5706/BCM5708 Gigabit > Ethernet > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device umass # Disks/Mass storage - Requires scbus > and da > device ums # Mouse > > ### OPTIONS > > > options MP_WATCHDOG > options DEVICE_POLLING > device pf > device pflog > device pfsync > device carp > device vlan > device gre > device if_bridge > device tun > device lagg > device stf #6to4 IPv6 over IPv4 encapsulation > > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_CDNR > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build > > > > options NETGRAPH > options NETGRAPH_CISCO > options NETGRAPH_FEC > options NETGRAPH_ETHER > > > > > > Copyright (c) 1992-2008 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 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 > root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4286042112 (4087 MB) > avail memory = 4124753920 (3933 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 64-87 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > 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 > acpi_hpet0: iomem 0xfed00000-0xfed003ff > on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci6: on pcib1 > pcib2: at device 0.0 on pci6 > pci7: on pcib2 > pcib3: at device 0.0 on pci7 > pci8: on pcib3 > pcib4: at device 0.0 on pci8 > pci9: on pcib4 > bce0: mem > 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 > miibus0: on bce0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bce0: Ethernet address: 00:19:b9:cd:60:44 > bce0: [ITHREAD] > bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W > (0x02090105); Flags( MFW MSI ) > pcib5: at device 1.0 on pci7 > pci10: on pcib5 > pcib6: at device 0.0 on pci10 > pci11: on pcib6 > pcib7: at device 0.0 on pci11 > pci12: on pcib7 > em0: port 0xece0-0xecff > mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 > on pci12 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:5d:2a:40 > em1: port 0xecc0-0xecdf > mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 > on pci12 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:15:17:5d:2a:41 > pcib8: at device 1.0 on pci11 > pci13: on pcib8 > em2: port 0xdce0-0xdcff > mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. > > > lagg0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:2a:40 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em1 flags=1c > laggport: em0 flags=1c > > > lagg1: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:28:62 > inet netmask 0xfffffffc broadcast > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em7 flags=1c > laggport: em6 flags=1c > > lagg2: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:28:60 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em5 flags=1c > laggport: em4 flags=1c > > > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From volker at thalreit.de Mon May 12 10:12:30 2008 From: volker at thalreit.de (Volker Jahns) Date: Mon May 12 10:12:34 2008 Subject: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) In-Reply-To: <482804BF.1090506@coverity.com> References: <482804BF.1090506@coverity.com> Message-ID: <48281511.6000003@thalreit.de> David Kramer schrieb: > I am currently working on connecting a FreeBSD 4.9 client connection > to NIS server running on OpenBSD 3.9. The ypcat commands are working > and I can see the passwd and group files, however when I attempt to > login to the machine I keep getting SSHD Illegal User Errors. As a first guess I would recommend: - check /etc/hosts.allow (ssh access control used by FreeBSD) - shadow support - rpcinfo -p works OK? - run ypserv daemon in foregound, check its output -- Volker Jahns, volker@thalreit.de From volker at vwsoft.com Mon May 12 11:02:20 2008 From: volker at vwsoft.com (Volker) Date: Mon May 12 11:02:25 2008 Subject: how to identify a PHY? Message-ID: <48281D8F.2090501@vwsoft.com> Hi! >From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). Thanks! Volker From bugmaster at FreeBSD.org Mon May 12 11:07:02 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:07:12 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200805121107.m4CB71pE038085@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123123 net [re][patch] Realtek RTL8111C detection and failure o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre 74 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re][patch] re(4) unsupported hardware revision (8168/ o kern/123147 net [ti] [patch] ti(4) doesn't use mii, but kernel configs 45 problems total. From marius at alchemy.franken.de Mon May 12 11:37:28 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon May 12 11:37:31 2008 Subject: how to identify a PHY? In-Reply-To: <48281D8F.2090501@vwsoft.com> References: <48281D8F.2090501@vwsoft.com> Message-ID: <20080512111958.GA95632@alchemy.franken.de> On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: > Hi! > > >From the bugbusting front, I'm often seeing network related issues with > unknown (new) PHYs. > > Can please somebody explain me how one is able to identify what kind of > PHY interface is build into a system? Does pciconf output provide some > piece of information which leads into getting PHY information? I need to > know that to work with the submitter and get their interfaces running > (or retrieve information for you to work on). > If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). Marius From artem at aws-net.org.ua Mon May 12 11:47:17 2008 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Mon May 12 11:47:21 2008 Subject: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) In-Reply-To: <482804BF.1090506@coverity.com> References: <482804BF.1090506@coverity.com> Message-ID: <482824E2.4000403@aws-net.org.ua> David Kramer wrote: > **IF this is the wrong list for this topic please let me know which list > I should post network services issues to. > > I am relatively new to FreeBSD but have quite a bit of experience with > NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client > connection to NIS server running on OpenBSD 3.9. The ypcat commands are > working and I can see the passwd and group files, however when I attempt > to login to the machine I keep getting SSHD Illegal User Errors. The > type of behavior I am seeing would be common on a Linux machine that > uses nssswitch.conf to state which objects to pass authentication > through, but its missing the nis value for passwd: or group:. Looking > through the FreeBSD website I see that nssswitch was introduced in > FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any > additional configurations that need to be done? Possibly with PAM? I > have the following values in my /etc/rc.conf files: Have you added special records to /etc/group and /etc/master.passwd files? It should be +::: in /etc/group and +::::::::: in /etc/master.passwd. Use vipw to edit password file. > > nisdomainname="myNISdomain" > nis_client_enable="YES" > > I have followed the FreeBSD NIS/YP Handbook configuration to the T, and > still get the illegal user authentication any insight would be greatly > appreciated. > > Thanks much, > > DK > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | ================================ FreeBSD: The Power to Serve - http://www.freebsd.org From volker at vwsoft.com Mon May 12 11:55:53 2008 From: volker at vwsoft.com (Volker) Date: Mon May 12 11:55:58 2008 Subject: how to identify a PHY? In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> Message-ID: <48283036.8060602@vwsoft.com> On 05/12/08 13:19, Marius Strobl wrote: > On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: >> Hi! >> >> >From the bugbusting front, I'm often seeing network related issues with >> unknown (new) PHYs. >> >> Can please somebody explain me how one is able to identify what kind of >> PHY interface is build into a system? Does pciconf output provide some >> piece of information which leads into getting PHY information? I need to >> know that to work with the submitter and get their interfaces running >> (or retrieve information for you to work on). >> > > If the system is running the simplest thing in order to identifiy > the PHYs is to check the oui= and model= output of `devinfo -v`. > Otherwise boot verbose and check the OUI and model output of > ukphy(4). Marius, thanks for your answer. As far as I understand, the devinfo output will only contain useful information if a driver attaches to the phy. Sometimes a new mainboard hits the market and the ID of the phy's chip is unknown the FreeBSD. If a submitter files a PR and no phy driver attaches, I would like to check if the chip ID is currently known to the system. So I need to know a way to check the ID of a chip without a driver being attached. In short my original question better reads as "how do I know the kind of phy if no driver has been attached". Can one retrieve that information out of a verbose boot dmesg (from probing messages)? I would like to first check if a PR might be related to a phy problem at all and if it's just coming with an ID currently unknown to FreeBSD to prepare the PR into a state containing every piece of information needed to have the net-team working easily on it. Thanks Volker From volker at vwsoft.com Mon May 12 12:01:25 2008 From: volker at vwsoft.com (Volker) Date: Mon May 12 12:01:28 2008 Subject: how to identify a PHY? In-Reply-To: <48282DEE.9090502@FreeBSD.org> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48282DEE.9090502@FreeBSD.org> Message-ID: <4828317C.4000807@vwsoft.com> On 05/12/08 13:45, Bruce M. Simpson wrote: > Marius Strobl wrote: >> If the system is running the simplest thing in order to identifiy >> the PHYs is to check the oui= and model= output of `devinfo -v`. >> Otherwise boot verbose and check the OUI and model output of ukphy(4). >> > > There's a project for someone in there I'm sure. > > Linux has mii-tool and mii-diag. Whilst we generally don't need all of > the knobs, sometimes it can be useful to dump and poke PHY registers on > the MII. src/sys/dev/mii/miibus_if.m contains the newbus interface > definition for miibus which would be a place to start. Bruce, am I correct assuming there's currently no easy way to get that information? Thanks Volker From bms at FreeBSD.org Mon May 12 12:02:37 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon May 12 12:02:42 2008 Subject: how to identify a PHY? In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> Message-ID: <48282DEE.9090502@FreeBSD.org> Marius Strobl wrote: > If the system is running the simplest thing in order to identifiy > the PHYs is to check the oui= and model= output of `devinfo -v`. > Otherwise boot verbose and check the OUI and model output of > ukphy(4). > There's a project for someone in there I'm sure. Linux has mii-tool and mii-diag. Whilst we generally don't need all of the knobs, sometimes it can be useful to dump and poke PHY registers on the MII. src/sys/dev/mii/miibus_if.m contains the newbus interface definition for miibus which would be a place to start. cheers BMS From bms at FreeBSD.org Mon May 12 12:07:53 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon May 12 12:07:57 2008 Subject: how to identify a PHY? In-Reply-To: <48283036.8060602@vwsoft.com> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48283036.8060602@vwsoft.com> Message-ID: <48283316.2080100@FreeBSD.org> Volker wrote: > ... > In short my original question better reads as "how do I know the kind of > phy if no driver has been attached". Can one retrieve that information > out of a verbose boot dmesg (from probing messages)? > You can't determine which PHY is in use unless a driver is attached, because it's necessary to attach a driver in order to access the card's MII registers. Same with any other OS. If no PHY driver attached, but a NIC driver attached, you should see this message: device_printf(dev, "MII without any PHY!\n"); It sounds like someone needs to instrument the code path mii_phy_probe() to print useful information in the situation you describe. cheers BMS From marius at alchemy.franken.de Mon May 12 12:10:43 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon May 12 12:10:46 2008 Subject: how to identify a PHY? In-Reply-To: <48283036.8060602@vwsoft.com> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48283036.8060602@vwsoft.com> Message-ID: <20080512121041.GD36894@alchemy.franken.de> On Mon, May 12, 2008 at 01:55:34PM +0200, Volker wrote: > On 05/12/08 13:19, Marius Strobl wrote: > > On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: > >> Hi! > >> > >> >From the bugbusting front, I'm often seeing network related issues with > >> unknown (new) PHYs. > >> > >> Can please somebody explain me how one is able to identify what kind of > >> PHY interface is build into a system? Does pciconf output provide some > >> piece of information which leads into getting PHY information? I need to > >> know that to work with the submitter and get their interfaces running > >> (or retrieve information for you to work on). > >> > > > > If the system is running the simplest thing in order to identifiy > > the PHYs is to check the oui= and model= output of `devinfo -v`. > > Otherwise boot verbose and check the OUI and model output of > > ukphy(4). > > Marius, > > thanks for your answer. As far as I understand, the devinfo output will > only contain useful information if a driver attaches to the phy. > Sometimes a new mainboard hits the market and the ID of the phy's chip > is unknown the FreeBSD. > > If a submitter files a PR and no phy driver attaches, I would like to > check if the chip ID is currently known to the system. So I need to know > a way to check the ID of a chip without a driver being attached. > > In short my original question better reads as "how do I know the kind of > phy if no driver has been attached". Can one retrieve that information > out of a verbose boot dmesg (from probing messages)? > > I would like to first check if a PR might be related to a phy problem at > all and if it's just coming with an ID currently unknown to FreeBSD to > prepare the PR into a state containing every piece of information needed > to have the net-team working easily on it. > For NIC drivers interfacing with miibus(4) the ukphy(4) driver always matches as a last resort. If even ukphy(4) doesn't attach this means there's a more fundamental problem of some sort with the NIC driver communicating with the MII bus. In that case there's no way to identify which PHYs are on the MII bus (it even doesn't necessarily mean they are "unknown" to the system.) Marius From slawek.zak at gmail.com Mon May 12 13:14:22 2008 From: slawek.zak at gmail.com (Slawek Zak) Date: Mon May 12 13:14:26 2008 Subject: PF NAT and IPSec (ESP) not working Message-ID: <787bbe1c0805120549m8d80979t3932d091608dbbfa@mail.gmail.com> Hi, I probably do something wrong, and I can't seem to get NAT in PF working with IPSec tunnel mode. Here's the network diagram: (172.16.0.0/16) internal network-- remote end of tunnel AA.AA.AA.AA --- XX.XX.XX.XX re0 (Internet) ----- enc (IPSec) ---- ZZ.ZZ.ZZ.ZZ gif1 --- tun0 --- YY.YY.YY.YY/24 OpenVPN clients I want OpenVPN clients to be NAT'ed to ZZ.ZZ.ZZ.ZZ and then enter the ipsec tunnel, be encrypted and land on the other side. When I've setup NAT using following PF rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 -> ZZ.ZZ.ZZ.ZZ the packets go out on gif1 but are not encrypted (no traffic on enc0). Same for following NAT rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 -> ZZ.ZZ.ZZ.ZZ Help, please! Thanks, /S From andre at freebsd.org Mon May 12 13:58:01 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon May 12 13:58:04 2008 Subject: read() returns ETIMEDOUT on steady TCP connection In-Reply-To: <482561F3.6080701@gebbettco.com> References: <4822BABB.4020407@freebsd.org> <4824211C.9090105@freebsd.org> <482561F3.6080701@gebbettco.com> Message-ID: <48284CE7.2020707@freebsd.org> Tim Gebbett wrote: > Hi Andre, did some careful testing yesterday and last night. I seem to > be still hitting an unknown buffer although the probem is much alleviated. > The system achieved a 7hour run at 500mbit where ETIMEDOUT occured. I > was feeding 11 other streams to the server whos counters show an > uninterrupted eleven hours. The feeder streams are from the same source, > so it is unlikely that the one feeding the test could of had a problem > without affecting the counters of the others. > sysctls are: > > (loader.conf) hw.em.txd=4096 > net.inet.tcp.sendspace=78840 > net.inet.tcp.recvspace=78840 > > kern.ipc.nmbjumbop=51200 > kern.ipc.nmbclusters=78840 > kern.maxfiles=50000 > > IP stats are miraculously improved, going from a 10% packet loss within > stack (output drops) to a consistent zero at peaks of 80000 pps. I > believe the problem is now being shunted to the NIC from the following > output: > > dev.em.0.debug=1 > > < em0: Adapter hardware address = 0xc520b224 > > < em0: CTRL = 0x48f00249 RCTL = 0x8002 < em0: Packet buffer = Tx=16k > Rx=48k < em0: Flow control watermarks high = 47104 low = 45604 > < em0: tx_int_delay = 66, tx_abs_int_delay = 66 > < em0: rx_int_delay = 0, rx_abs_int_delay = 66 > < em0: fifo workaround = 0, fifo_reset_count = 0 > < em0: hw tdh = 3285, hw tdt = 3285 > < em0: hw rdh = 201, hw rdt = 200 > < em0: Num Tx descriptors avail = 4096 > < em0: Tx Descriptors not avail1 = 4591225 > < em0: Tx Descriptors not avail2 = 0 > < em0: Std mbuf failed = 0 > < em0: Std mbuf cluster failed = 0 > < em0: Driver dropped packets = 0 > < em0: Driver tx dma failure in encap = 0 > > dev.em.0.stats=1 > > < em0: Excessive collisions = 0 > > < em0: Sequence errors = 0 > < em0: Defer count = 0 > < em0: Missed Packets = 16581181 > < em0: Receive No Buffers = 74605555 > < em0: Receive Length Errors = 0 > < em0: Receive errors = 0 > < em0: Crc errors = 0 > < em0: Alignment errors = 0 > < em0: Collision/Carrier extension errors = 0 > < em0: RX overruns = 289717 > < em0: watchdog timeouts = 0 > < em0: XON Rcvd = 0 > < em0: XON Xmtd = 0 > < em0: XOFF Rcvd = 0 > < em0: XOFF Xmtd = 0 > < em0: Good Packets Rcvd = 848158221 > < em0: Good Packets Xmtd = 1080368640 > < em0: TSO Contexts Xmtd = 0 > < em0: TSO Contexts Failed = 0 > > > Does the counter 'Tx Descriptors not avail1' indicate lack of > decriptors at the time not available, and would this be symptomatic of > something Mark suggested: > "(the stack) needs to handle local buffer fills not as a failed attempt > on transmission that increments the retry counter, a possible better > strategy required for backoff > when the hardware buffer is full?" Indeed. We have rethink a couple of assumptions the code currently makes and has made for the longest time. Additionally the defaults for the network hardware need to be better tuned for workloads like yours. I'm on my way to BSDCan'08 soon and I will discuss these issues at the Developer Summit. -- Andre From fazaeli at sepehrs.com Mon May 12 15:33:02 2008 From: fazaeli at sepehrs.com (H.fazaeli) Date: Mon May 12 15:33:06 2008 Subject: if_bridge with two subnets In-Reply-To: <48274E6D.9060704@jcornwall.me.uk> References: <4825EF8D.1050304@jcornwall.me.uk> <4826EB42.104@sepehrs.com> <48274E6D.9060704@jcornwall.me.uk> Message-ID: <48286052.6000507@sepehrs.com> Jay L. T. Cornwall wrote: > H.fazaeli wrote: > >> The bridge works as it should: It receives packets from >> XX.XX.XXX.YYY on the interface connected to the switch, and >> forwards them on the interface connected to the gateway. >> >> The problem is that forwarding between subnets is the responsibility >> of your switch. The switch does its job, but since the two clients are >> not on the same IP subnet, they can not reach each other w/o the help of >> an intermediate router. > > Perhaps I am mixing up two separate networking concepts. > > On a machine configured to act as a gateway, I would expect a single > interface with more than one subnet to route packets correctly across > those subnets. That may not be how it works in practice. > > If it does not work, I would question why not. If it does work then I > would expect the same behaviour on each of a bridge's constituent > interfaces? > It does work. However, if I understand your setup correctly, the freebsd box has been setup to act as a bridge, not as a router (routing is enabled with sysctl net.inet.ip.forwarding=1). Bridging works when the forwarding is between the same subnets. For freebsd box to route between subnets: - enable routing: sysctl net.inet.ip.forwarding=1 - clients must use the freebsd box as gateway. - IP addresses must be removed from the bridge and assigned to the member interfaces. (the bridge is no longer needed). You may have bridging & routing on the same box at the same time but note that a single packet coming into the system either goes through bridging _or_ routing code, but not both. The former case happens if packet's destination MAC address is not that of box. The latter case happens when destination MAC address is that of receiving interface. If you provide a network diagram along with your requirements, we can better discuss the matter. -- With best regards. Hooman Fazaeli Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From linimon at FreeBSD.org Mon May 12 17:42:30 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 12 17:42:32 2008 Subject: kern/123603: [tcp] tcp_do_segment and Received duplicate SYN Message-ID: <200805121742.m4CHgTT1076336@freefall.freebsd.org> Old Synopsis: tcp_do_segment and Received duplicate SYN New Synopsis: [tcp] tcp_do_segment and Received duplicate SYN Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 17:42:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123603 From paul at gtcomm.net Mon May 12 18:50:07 2008 From: paul at gtcomm.net (Paul) Date: Mon May 12 18:50:13 2008 Subject: Discrepancy on netstat -w x -I and what Cisco reports In-Reply-To: <48280B97.1020708@moneybookers.com> References: <4827E79C.8050608@gtcomm.net> <48280B97.1020708@moneybookers.com> Message-ID: <482891C7.1030603@gtcomm.net> Yes it was a typo I meant -w -I It just doesn't add up to what the switch is seeing, and it's directly connected and the traffic can't be going anywhere else. Stefan Lambrev wrote: > Greetings, > > I just have a question: > > is "netstat -w 100 lagg0" a typo ? > > If you want to see the traffic only on single interface you should use -I > > I do not know if this is bug, but netstat -w 100 > something_non_existing works on my bsd and just shows "Total" > > So may be from here comes the confusion. You think, that netstat count > only traffic on lagg0, > but it shows you the Total traffic? > > Paul wrote: >> This is very strange.. I can do: >> >> netstat -w 10 -I lagg0 >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 57806 0 41751685 232442 0 51062425 0 >> 56459 0 38341591 225146 0 48865209 0 >> 60687 0 43552946 227987 0 52008241 0 >> >> which is roughly 23,000 pps and the Cisco switch reports >> 30 second input rate 44544000 bits/sec, 16198 packets/sec >> >> >> Another example: >> >> netstat -w 10 -I lagg0 >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 71111 0 52180947 89734 0 25304669 0 >> 66847 0 49028588 81737 0 21614941 0 >> 63530 0 43502418 83419 0 24599547 0 >> >> 8,300 or so pps >> >> Cisco: >> 30 second input rate 19230000 bits/sec, 4594 packets/sec >> >> >> In some cases it's pretty close, cisco says 6500 and bsd says 7500.. >> but sometimes it is way off >> I even checked the em interfaces directly to see if it was a problem >> with the lagg interface code and they report weird issues, check below. >> Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue >> with the counters. >> It's two different Cisco switches and two fbsd machines that have the >> same kernel, etc. >> >> Maybe this is a side effect of setting my kernel HZ at 4000? >> Gets even worse like this: >> netstat -w 100 lagg0 >> input (Total) output >> packets errs bytes packets errs bytes colls >> 9229322 0 3337789024 9424932 0 3510341158 0 >> >> 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports >> 2 minute input rate 44130000 bits/sec, 14892 packets/sec > Again this is Total not lagg0 >> and even check this out: >> >> netstat -w 1 lagg0 >> input *(Total) * output >> packets errs bytes packets errs bytes colls >> 92481 0 31630795 94952 0 34193131 0 >> 89078 0 32498082 91460 0 35094821 0 >> 87540 0 34526292 89992 0 37159101 0 >> 88987 0 32391984 91765 0 35394351 0 >> >> >> netstat -w 1 em0 >> input *(Total) * output >> packets errs bytes packets errs bytes colls >> 96802 0 39474036 99897 0 42814245 0 >> 93277 0 37018533 95943 0 39860879 0 >> 95916 0 37559076 99032 0 40739640 0 >> >> netstat -w 1 em1 >> input * (Total) * output >> packets errs bytes packets errs bytes colls >> 97102 0 38369949 99508 0 40841183 0 >> 92321 0 35375169 94305 0 37384073 0 >> 92225 0 33171455 94253 0 35209658 0 >> >> What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k >> and i KNOW it's not doing anywhere near.. >> cisco report >> 2 minute output rate 32928000 bits/sec, 5823 packets/sec > Again missing -I :) >> >> Now all lagg interfaces are reporting >> netstat -w 1 lagg1 >> input * (Total) * output >> packets errs bytes packets errs bytes colls >> 89324 0 30824353 91518 0 32770482 0 >> 85875 0 31924738 87813 0 33552137 0 >> 84105 0 31176932 85666 0 32393051 0 >> 83617 0 32175677 84871 0 33120271 0 >> 90611 0 37313093 92403 0 38818721 0 >> >> lagg1 goes directly to another freebsd box and on the other freebsd >> box I do: >> netstat -w 1 -I lagg1 >> input (lagg1) output >> packets errs bytes packets errs bytes colls >> 45 0 3078 2213 0 1890198 0 >> 48 0 3245 1958 0 1545642 0 >> 43 0 3186 1975 0 1628916 0 >> 43 0 2905 2169 0 1918250 0 >> 46 0 3464 1859 0 1729764 0 >> 46 0 3134 1873 0 1739662 0 >> >> and the other one >> netstat -w 1 lagg1 >> input * (Total)* output >> packets errs bytes packets errs bytes colls >> 92149 0 31706183 93523 0 32673138 0 >> 89737 0 28119643 91323 0 28958816 0 >> >> >> Doing all these reports now seems to have the interfaces stuck at >> packets errs bytes packets errs bytes colls >> 96937 0 31749525 98551 0 32678863 0 >> 85892 0 29411078 87233 0 30182355 0 >> 90435 0 31628680 91620 0 32215244 0 >> 87383 0 30616741 88278 0 31026608 0 >> >> >> every interface on the machine is reporting the same PPS and bytes.. >> lol :) >> >> So something is extremely fishy about the counters.. I'm going to try >> and update to -STABLE to see if it makes any difference. It's not >> just the lagg interface either because all the em's are showing it as >> well. >> >> This is using 4 port Intel Server PCI Express NIC >> >> ifstat seems to report correct usage in Kbps and seems to report >> correct packet count. Maybe it's just a netstat problem? >> >> I will see if stable fixes it. Also, feel free to make any comments >> on my config file for routing. >> >> FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 >> 18:11:49 EDT 2008 amd64 >> >> >> UPDATE.. Changed 1 router to stable: >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 amd64 >> >> Still see: >> 2 minute input rate 10463000 bits/sec, 2481 packets/sec >> 2 minute output rate 40075000 bits/sec, 6847 packets/sec >> >> and >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 6940 0 5172153 4841 0 1345660 0 >> 5922 0 4252074 3963 0 1087205 0 >> 6673 0 4982394 4116 0 1056933 0 >> 6659 0 4467398 4140 0 1068919 0 >> 7085 0 4692973 4777 0 1665109 0 >> 7140 0 4654486 4713 0 1658303 0 >> 7070 0 4558384 5078 0 1994666 0 >> 6375 0 4575464 4037 0 1121385 0 >> 6257 0 3932910 4321 0 1607862 0 >> 6504 0 4345014 4370 0 1278819 0 >> >> >> Hmmmm.. >> >> >> >> >> em0: port >> 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 >> at device 0.0 on pci12 >> em0: Using MSI interrupt >> em0: Ethernet address: 00:15:17:5d:18:00 >> em0: [FILTER] >> em1: port >> 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 >> at device 0.1 on pci12 >> em1: Using MSI interrupt >> em1: Ethernet address: 00:15:17:5d:18:01 >> em1: [FILTER] >> .......etc.. to em7 >> >> >> Copyright (c) 1992-2008 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 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz >> K8-class CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> >> Features=0xbfebfbff >> >> >> Features2=0x4e3bd >> >> AMD Features=0x20100800 >> AMD Features2=0x1 >> Cores per package: 2 >> usable memory = 4285833216 (4087 MB) >> avail memory = 4124545024 (3933 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 6 >> cpu3 (AP): APIC ID: 7 >> ioapic0: Changing APIC ID to 8 >> ioapic1: Changing APIC ID to 9 >> >> >> >> Kernel config file: (if you have any suggestions about the config let >> me know for faster routing speed) >> >> cpu HAMMER >> ident GENERIC >> >> #makeoptions DEBUG=-g # Build kernel with gdb(1) >> debug symbols >> >> options SCHED_4BSD # 4BSD scheduler >> #options PREEMPTION # Enable kernel thread >> preemption >> options INET # InterNETworking >> options INET6 # IPv6 communications protocols >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates >> support >> options UFS_ACL # Support for access control >> lists >> options UFS_DIRHASH # Improve performance on big >> directories >> options UFS_GJOURNAL # Enable gjournal-based UFS >> journaling >> options MD_ROOT # MD is a potential root device >> options NTFS # NT File System >> options MSDOSFS # MSDOS Filesystem >> options CD9660 # ISO 9660 Filesystem >> options PROCFS # Process filesystem >> (requires PSEUDOFS) >> options PSEUDOFS # Pseudo-filesystem framework >> options GEOM_PART_GPT # GUID Partition Tables. >> options GEOM_LABEL # Provides labelization >> options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP >> THIS!] >> options COMPAT_IA32 # Compatible with i386 binaries >> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 # Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 # Compatible with FreeBSD6 >> options SCSI_DELAY=5000 # Delay (in ms) before >> probing SCSI >> options KTRACE # ktrace(1) support >> options SYSVSHM # SYSV-style shared memory >> options SYSVMSG # SYSV-style message queues >> options SYSVSEM # SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B >> real-time extensions >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> #options ADAPTIVE_GIANT # Giant mutex is adaptive. >> options NO_ADAPTIVE_MUTEXES ## >> options STOP_NMI # Stop CPUS using NMI instead >> of IPI >> options AUDIT # Security event auditing >> options IPSEC ## for tcp md5 >> options TCP_SIGNATURE ##include support for RFC 2385 >> device crypto ## for md5 >> device cryptodev ## for md5 >> >> # Make an SMP-capable kernel by default >> options SMP # Symmetric MultiProcessor >> Kernel >> >> # CPU frequency control >> device cpufreq >> >> # Bus support. >> device acpi >> device pci >> >> # Floppy drives >> device fdc >> >> # ATA and ATAPI devices >> device ata >> device atadisk # ATA disk drives >> device ataraid # ATA RAID drives >> device atapicd # ATAPI CDROM drives >> device atapifd # ATAPI floppy drives >> device atapist # ATAPI tape drives >> options ATA_STATIC_ID # Static device numbering >> >> # SCSI peripherals >> device scbus # SCSI bus (required for SCSI) >> device ch # SCSI media changers >> device da # Direct Access (disks) >> device sa # Sequential Access (tape etc) >> device cd # CD >> device pass # Passthrough device (direct SCSI >> access) >> device ses # SCSI Environmental Services (and >> SAF-TE) >> >> # RAID controllers >> device mfi # LSI MegaRAID SAS >> >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> device atkbdc # AT keyboard controller >> device atkbd # AT keyboard >> device psm # PS/2 mouse >> >> device kbdmux # keyboard multiplexer >> >> device vga # VGA video card driver >> >> device splash # Splash screen and screen saver support >> >> # syscons is the default console driver, resembling an SCO console >> device sc >> >> device agp # support several AGP chipsets >> >> # Serial (COM) ports >> device sio # 8250, 16[45]50 based serial ports >> device uart # Generic UART driver >> >> # PCI Ethernet NICs. >> device em # Intel PRO/1000 adapter Gigabit >> Ethernet Card >> # PCI Ethernet NICs that use the common MII bus controller code. >> # NOTE: Be sure to keep the 'device miibus' line in order to use >> these NICs! >> device miibus >> device bce # Broadcom BCM5706/BCM5708 Gigabit >> Ethernet >> >> # Pseudo devices. >> device loop # Network loopback >> device random # Entropy device >> device ether # Ethernet support >> device sl # Kernel SLIP >> device ppp # Kernel PPP >> device tun # Packet tunnel. >> device pty # Pseudo-ttys (telnet etc) >> device md # Memory "disks" >> device gif # IPv6 and IPv4 tunneling >> device faith # IPv6-to-IPv4 relaying (translation) >> device firmware # firmware assist module >> >> # The `bpf' device enables the Berkeley Packet Filter. >> # Be aware of the administrative consequences of enabling this! >> # Note that 'bpf' is required for DHCP. >> device bpf # Berkeley packet filter >> >> # USB support >> device uhci # UHCI PCI->USB interface >> device ohci # OHCI PCI->USB interface >> device ehci # EHCI PCI->USB interface (USB 2.0) >> device usb # USB Bus (required) >> #device udbp # USB Double Bulk Pipe devices >> device ugen # Generic >> device uhid # "Human Interface Devices" >> device ukbd # Keyboard >> device umass # Disks/Mass storage - Requires scbus >> and da >> device ums # Mouse >> >> ### OPTIONS >> >> >> options MP_WATCHDOG >> options DEVICE_POLLING >> device pf >> device pflog >> device pfsync >> device carp >> device vlan >> device gre >> device if_bridge >> device tun >> device lagg >> device stf #6to4 IPv6 over IPv4 encapsulation >> >> options ALTQ >> options ALTQ_CBQ # Class Bases Queuing (CBQ) >> options ALTQ_RED # Random Early Detection (RED) >> options ALTQ_RIO # RED In/Out >> options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) >> options ALTQ_CDNR >> options ALTQ_PRIQ # Priority Queuing (PRIQ) >> options ALTQ_NOPCC # Required for SMP build >> >> >> >> options NETGRAPH >> options NETGRAPH_CISCO >> options NETGRAPH_FEC >> options NETGRAPH_ETHER >> >> >> >> >> >> Copyright (c) 1992-2008 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 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 >> root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz >> K8-class CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> >> Features=0xbfebfbff >> >> >> Features2=0x4e3bd >> >> AMD Features=0x20100800 >> AMD Features2=0x1 >> Cores per package: 2 >> usable memory = 4286042112 (4087 MB) >> avail memory = 4124753920 (3933 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 6 >> cpu3 (AP): APIC ID: 7 >> ioapic0: Changing APIC ID to 8 >> ioapic1: Changing APIC ID to 9 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 64-87 on motherboard >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> 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 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff >> on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> cpu2: on acpi0 >> est2: on cpu2 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est2 attach returned 6 >> p4tcc2: on cpu2 >> cpu3: on acpi0 >> est3: on cpu3 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est3 attach returned 6 >> p4tcc3: on cpu3 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci6: on pcib1 >> pcib2: at device 0.0 on pci6 >> pci7: on pcib2 >> pcib3: at device 0.0 on pci7 >> pci8: on pcib3 >> pcib4: at device 0.0 on pci8 >> pci9: on pcib4 >> bce0: mem >> 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 >> miibus0: on bce0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bce0: Ethernet address: 00:19:b9:cd:60:44 >> bce0: [ITHREAD] >> bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W >> (0x02090105); Flags( MFW MSI ) >> pcib5: at device 1.0 on pci7 >> pci10: on pcib5 >> pcib6: at device 0.0 on pci10 >> pci11: on pcib6 >> pcib7: at device 0.0 on pci11 >> pci12: on pcib7 >> em0: port 0xece0-0xecff >> mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 >> on pci12 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:5d:2a:40 >> em1: port 0xecc0-0xecdf >> mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 >> on pci12 >> em1: Using MSI interrupt >> em1: [FILTER] >> em1: Ethernet address: 00:15:17:5d:2a:41 >> pcib8: at device 1.0 on pci11 >> pci13: on pcib8 >> em2: port 0xdce0-0xdcff >> mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. >> >> >> lagg0: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:2a:40 >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em1 flags=1c >> laggport: em0 flags=1c >> >> >> lagg1: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:28:62 >> inet netmask 0xfffffffc broadcast >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em7 flags=1c >> laggport: em6 flags=1c >> >> lagg2: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:28:60 >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em5 flags=1c >> laggport: em4 flags=1c >> >> >> _______________________________________________ >> 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" > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From dkramer at coverity.com Mon May 12 20:42:29 2008 From: dkramer at coverity.com (David Kramer) Date: Mon May 12 20:42:34 2008 Subject: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) In-Reply-To: <48281511.6000003@thalreit.de> References: <482804BF.1090506@coverity.com> <48281511.6000003@thalreit.de> Message-ID: <4828ABC5.60201@coverity.com> Thank you all for your responses, I have solved my issue. I needed to have Bash installed and setup for the shell to mount properly when the authentication happens. A symbolic link took care of it. Thanks much, DK Volker Jahns wrote: > > David Kramer schrieb: > > I am currently working on connecting a FreeBSD 4.9 client connection > > to NIS server running on OpenBSD 3.9. The ypcat commands are working > > and I can see the passwd and group files, however when I attempt to > > login to the machine I keep getting SSHD Illegal User Errors. > As a first guess I would recommend: > - check /etc/hosts.allow (ssh access control used by FreeBSD) > - shadow support > - rpcinfo -p works OK? > - run ypserv daemon in foregound, check its output > > -- > Volker Jahns, volker@thalreit.de > > -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. dkramer@coverity.com o. 415.694.5315 c. 650.302.7889 bb. 415.646.6320 Yahooo: Pollucts AIM: PolluctsXXX From linimon at FreeBSD.org Mon May 12 22:43:59 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 12 22:44:01 2008 Subject: kern/123617: [tcp] breaking connection when client downloading files from server Message-ID: <200805122243.m4CMhx3b002782@freefall.freebsd.org> Old Synopsis: breaking connection when client downloading files from server New Synopsis: [tcp] breaking connection when client downloading files from server Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 22:43:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s), although I supposed this could also be an re(4) problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=123617 From edwin at mavetju.org Tue May 13 14:38:02 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Tue May 13 14:38:06 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <48215D08.5050500@incunabulum.net> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> Message-ID: <20080513143758.GA3041@k7.mavetju> On Wed, May 07, 2008 at 08:40:56AM +0100, Bruce M. Simpson wrote: > Julian Elischer wrote: > >actually the divert sockets should really not be in PF_INET > >they could deliver both inet and inet6 packets. > >the sockaddr that they return (and which needs to be read for divert > >to make sense) could be used to distinguish between them. > > Good point. I'd forgotten that they were abusing the fields in sin_zero. > This is not OK for IPv6, although the kludge can still be perpetuated by > looking at sa_len and stashing what divert wants at the end of sockaddr_in6. > > So there IS a case for making them a separate protocol family if > someone's going to do a clean implementation of divert sockets for IPv6. I have it more or less working! See my "FreeBSD IPv6 Divert socket adventures" at http://www.mavetju.org/weblog/html/00231.html (1) http://www.mavetju.org/weblog/html/00232.html (2) http://www.mavetju.org/weblog/html/00233.html (3) It contains links to patches for FreeBSD 6.3 and the nat6to4d.c. Please read the disclaimer in the second last paragraph of the 3rd article about the rough edges on it. I'm very keen on getting help from somebody to check it and to polish it up once I'm happy with it. For example with regarding to the "inpcb" things which I have absolutely no idea about what they are or what they do, or how to properly manage them. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Tue May 13 14:45:28 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Tue May 13 14:45:32 2008 Subject: IPPROTO_DIVERT and PF_INET6 In-Reply-To: <20080513143758.GA3041@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> <20080513143758.GA3041@k7.mavetju> Message-ID: <20080513144525.GA3038@k7.mavetju> On Wed, May 14, 2008 at 12:37:58AM +1000, Edwin Groothuis wrote: > It contains links to patches for FreeBSD 6.3 and the nat6to4d.c. Needless to say that the code of nat6to4d.c is a proof-of-concept and is missing essential features like garbage-collection and configurationability. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From m.oe at x-trader.de Tue May 13 22:00:35 2008 From: m.oe at x-trader.de (Markus Oestreicher) Date: Tue May 13 22:00:38 2008 Subject: RX/TX multiqueue support Message-ID: Good Day, I see that the new igb driver has a tunable for multiple rx/tx queues. Is that for future use or already working when using a 82575 NIC? Currently the processing of packets is limited to one CPU per NIC. Can we now have multiple taskq processes for one NIC in parallel? Best Regards, Markus From paul at gtcomm.net Tue May 13 22:55:47 2008 From: paul at gtcomm.net (Paul) Date: Tue May 13 22:55:52 2008 Subject: RX/TX multiqueue support In-Reply-To: References: Message-ID: <482A1CDB.3030802@gtcomm.net> This would be awesome, like the Yandex driver for fbsd 6.. I wish there was some way of doing this for 7.0 :) maybe this is it.. So this is the question now....... Markus Oestreicher wrote: > Good Day, > > I see that the new igb driver has a tunable for multiple rx/tx queues. > Is that for future use or already working when using a 82575 NIC? > > Currently the processing of packets is limited to one CPU per NIC. > Can we now have multiple taskq processes for one NIC in parallel? > > Best Regards, > Markus > _______________________________________________ > 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 alex.wilkinson at dsto.defence.gov.au Wed May 14 06:11:38 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed May 14 06:11:43 2008 Subject: how to identify a PHY? In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> Message-ID: <20080514060556.GI65832@stlux503.dsto.defence.gov.au> 0n Mon, May 12, 2008 at 01:19:58PM +0200, Marius Strobl wrote: >If the system is running the simplest thing in order to identifiy >the PHYs is to check the oui= and model= output of `devinfo -v`. >Otherwise boot verbose and check the OUI and model output of >ukphy(4). Curious, once we have the hex codes for the oui and model e.g. brgphy0 pnpinfo oui=0x818 model=0x1a rev=0x2 at phyno=1 How do we then determine what 0x818 and 0x1a refer to ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From vwe at FreeBSD.org Wed May 14 21:04:47 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed May 14 21:04:50 2008 Subject: kern/120966: [rum] kernel panic with if_rum and WPA encryption Message-ID: <200805142104.m4EL4kKt016644@freefall.freebsd.org> Old Synopsis: [rum]: kernel panic with if_rum and WPA encryption New Synopsis: [rum] kernel panic with if_rum and WPA encryption State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Wed May 14 21:03:46 UTC 2008 State-Changed-Why: Feedback has been provided. Does this belong to net or better assign to usb? http://www.freebsd.org/cgi/query-pr.cgi?pr=120966 From vwe at FreeBSD.org Wed May 14 21:12:25 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed May 14 21:12:28 2008 Subject: kern/116172: [tun] [panic] Network / ipv6 recursive mutex panic Message-ID: <200805142112.m4ELCO3R017079@freefall.freebsd.org> Synopsis: [tun] [panic] Network / ipv6 recursive mutex panic State-Changed-From-To: feedback->suspended State-Changed-By: vwe State-Changed-When: Wed May 14 21:10:24 UTC 2008 State-Changed-Why: unfortunately we haven't received feedback and the state of this issue is still unclear if it has been solved or not by updating to a recent version. suspend for now until either we're seeing feedback or this ticket can be closed within a reasonable timeframe. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 14 21:10:24 UTC 2008 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=116172 From vwe at FreeBSD.org Wed May 14 21:14:59 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed May 14 21:15:07 2008 Subject: bin/123633: ifconfig doesn't set inet and ether address in one command Message-ID: <200805142114.m4ELEx3J018845@freefall.freebsd.org> Synopsis: ifconfig doesn't set inet and ether address in one command Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 14 21:14:27 UTC 2008 Responsible-Changed-Why: I'm able to reproduce this on 7-STABLE. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123633 From gnn at freebsd.org Thu May 15 03:15:09 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu May 15 03:15:36 2008 Subject: Proposed patch to the kernel and to netstat... Message-ID: Howdy, I have developed the attached patch which extends the functionality of netstat (via the -x flag) to show us all the socket buffer statistics. The kernel change counts mbufs, as well as clusters (at the moment of any size) and gives output like this: Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX S-BMAX (state) tcp4 0 0 127.0.0.1.6010 *.* 0 0 0 0 65536 32768 1 2048 0 0 262144 262144 LISTEN tcp6 0 0 ::1.6010 *.* 0 0 0 0 65536 32768 1 2048 0 0 262144 262144 LISTEN tcp4 0 0 172.16.186.130.22 172.16.186.1.53443 0 0 0 0 66608 33304 1 2048 0 0 262144 262144 ESTABLISHED tcp4 0 0 172.16.186.130.29178 172.16.186.1.22 0 0 0 0 0 0 0 0 0 0 0 0 TIME_WAIT tcp4 0 0 172.16.186.130.62302 69.147.83.41.22 0 0 0 0 65700 74540 1 2048 0 0 262144 262144 ESTABLISHED tcp4 0 0 127.0.0.1.62415 127.0.0.1.6010 0 0 0 0 0 0 0 0 0 0 0 0 TIME_WAIT Note you need a very wide screen to read that. The man page is also updated but the relevant bits are: The -x flag causes netstat to output all the information recorded about data stored in the socket buffers. The fields are: R-MBUF Number of mbufs in the receive queue. S-MBUF Number of mbufs in the send queue. R-CLUS Number of clusters, of any type, in the recieve queue. S-CLUS Number of clusters, of any type, in the send queue. R-HIWA Receive buffer high water mark, in bytes. S-HIWA Send buffer high water mark, in bytes. R-LOWA Receive buffer low water mark, in bytes. S-LOWA Send buffer low water mark, in bytes. R-BCNT Receive buffer byte count. S-BCNT Send buffer byte count. R-BMAX Maximum bytes that can be used in the receive buffer. S-BMAX Maximum bytes that can be used in the send buffer. Please email me comments. I'd like to commit this to HEAD soon. It can't be put into 7 without removing the cluster and mbuf counting, but I might do that as well if there is interest. Best, George -------------- next part -------------- A non-text attachment was scrubbed... Name: netstat.diff Type: application/octet-stream Size: 8920 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080515/117616e4/netstat.obj From bms at FreeBSD.org Thu May 15 08:50:12 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu May 15 08:50:19 2008 Subject: Proposed patch to the kernel and to netstat... In-Reply-To: References: Message-ID: <482BF941.30108@FreeBSD.org> gnn@freebsd.org wrote: > ... > Please email me comments. I'd like to commit this to HEAD soon. It > can't be put into 7 without removing the cluster and mbuf counting, > but I might do that as well if there is interest. > People writing servers are going to find the watermark stuff useful. I'm thinking being able to watch the the buffer stats (possibly also in a way which we can graph) for a single socket, given its inpcb or so address, would also be a neat trick... cheers BMS From john at dnepro.net Thu May 15 16:08:16 2008 From: john at dnepro.net (Eugene Perevyazko) Date: Thu May 15 16:08:23 2008 Subject: How to inject fullsize 802.1q-tagged frame through BPF? Message-ID: <20080515152607.GA36663@roof1.dnepro.net> Hello, I have an ethernet interface with several vlans on it (FreeBSD 6.2-RELEASE #0). My program opens BPF on the parent device, receives tagged frames and responds by writing tagged frame to the BPF fd. It all works good, until size of response frame w/o tag becomes larger than 1496 bytes (1500 with tag inserted) - mtu of parent device.i I'm a bit confused as mtu is 1500 on both vlanN and it's parent fxp0. I've tried to "ifconfig fxp0 mtu 1504" to make room for vlan tag, but the response is ifconfig: ioctl (set mtu): Invalid argument Trying "ifconfig fxp0 -vlanmtu" also makes no difference. Is there a way to inject full-mtu vlan-tagged frame through BPF on parent device? I'd like not to open several tenths of BPFs for each vlanN if it's possible. I've tried on bge also with same results, so that is not connected with fxp driver. Eugene Perevyazko From sam at freebsd.org Thu May 15 16:21:31 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu May 15 16:21:56 2008 Subject: How to inject fullsize 802.1q-tagged frame through BPF? In-Reply-To: <20080515152607.GA36663@roof1.dnepro.net> References: <20080515152607.GA36663@roof1.dnepro.net> Message-ID: <482C6303.9000904@freebsd.org> Eugene Perevyazko wrote: > Hello, > I have an ethernet interface with several vlans on it (FreeBSD 6.2-RELEASE #0). > My program opens BPF on the parent device, receives tagged frames and responds > by writing tagged frame to the BPF fd. > It all works good, until size of response frame w/o tag becomes larger than > 1496 bytes (1500 with tag inserted) - mtu of parent device.i > I'm a bit confused as mtu is 1500 on both vlanN and it's parent fxp0. > I've tried to "ifconfig fxp0 mtu 1504" to make room for vlan tag, but > the response is > ifconfig: ioctl (set mtu): Invalid argument > > Trying "ifconfig fxp0 -vlanmtu" also makes no difference. > > Is there a way to inject full-mtu vlan-tagged frame through BPF on parent > device? > I'd like not to open several tenths of BPFs for each vlanN if it's possible. > > I've tried on bge also with same results, so that is not connected with fxp > driver. bpf write code in the kernel calculates header size when packets are injected. This is likely based on the frames being stock 802.3 so would require mods to the bpf code to handle the additional space for the tag. Sam From crapsh at monkeybrains.net Fri May 16 02:30:03 2008 From: crapsh at monkeybrains.net (Rudy) Date: Fri May 16 02:30:10 2008 Subject: carp oddness... BACKUP is ARPing! Message-ID: <482CEC29.9000509@monkeybrains.net> The CARP in BACKUP is arping... why? Rudy First, arp -d ns2, then ping ns2 to refresh arp to machine testing. # arp ns2; arp jamon; arp cabrillo ns2.monkeybrains.NET (208.69.40.4) at 00:30:48:88:e7:98 on em0 [ethernet] jamon.monkeybrains.NET (208.69.40.5) at 00:15:f2:4b:60:49 on em0 [ethernet] cabrillo.monkeybrains.NET (208.69.40.7) at 00:30:48:88:e7:98 on em0 [ethernet] CABRILLO# ifconfig bge0: flags=8943 mtu 1500 options=1b inet 208.69.40.7 netmask 0xffffff00 broadcast 208.69.40.255 ether 00:30:48:88:e7:98 media: Ethernet autoselect (100baseTX ) status: active carp1: flags=49 mtu 1500 inet 208.69.40.4 netmask 0xffffffff carp: BACKUP vhid 2 advbase 4 advskew 180 JAMON# ifconfig fxp0: flags=8943 mtu 1500 options=8 inet 208.69.40.5 netmask 0xffffff00 broadcast 208.69.40.255 ether 00:15:f2:4b:60:49 media: Ethernet autoselect (100baseTX ) status: active carp1: flags=41 mtu 1500 inet 208.69.40.4 netmask 0xffffffff carp: MASTER vhid 2 advbase 4 advskew 0 FreeBSD jamon.monkeybrains.net 5.5-STABLE FreeBSD cabrillo.monkeybrains.net 6.2-STABLE sysctl net.inet.carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 From bms at FreeBSD.org Fri May 16 09:14:37 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri May 16 09:14:41 2008 Subject: carp oddness... BACKUP is ARPing! In-Reply-To: <482CEC29.9000509@monkeybrains.net> References: <482CEC29.9000509@monkeybrains.net> Message-ID: <482D5079.60608@FreeBSD.org> Rudy wrote: > > The CARP in BACKUP is arping... why? Without looking at the carp code, I can tell you that its addressing hook is implemented as a pass-through in ether_input(). carps are not IFT_ETHER, therefore they shouldn't emit gratuitous ARP or otherwise when an address is configured on one. So I'll leave this up to someone who knows the carp code, as this is most likely where the ARP originated from. cheers BMS From proks at logos.sky.od.ua Fri May 16 15:29:30 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Fri May 16 15:29:34 2008 Subject: em0: watchdog timeout -- resetting Message-ID: <20080516164544.Y80938@logos.sky.od.ua> Hi All! I have a problem with Intel NIC after upgrade from 7-STABLE(25Mar2008,) to 7-STABLE(5May2008,) on motherboard Supermicro PDSMi-LN4+ http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm The NIC em0 is hangup at 16May with messages: May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN >kenv | grep smbios: smbios.bios.reldate="08/27/2007" smbios.bios.vendor="Phoenix Technologies LTD" smbios.bios.version="6.00" smbios.chassis.maker="Supermicro" smbios.chassis.serial="0123456789" smbios.chassis.tag=" " smbios.chassis.version="0123456789" smbios.planar.maker="Supermicro" smbios.planar.product="PDSMi-LN4+" smbios.planar.serial="0123456789" smbios.planar.version="PCB Version" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Supermicro" smbios.system.product="PDSMi-LN4" smbios.system.serial="0123456789" smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" smbios.system.version="0123456789" >pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 rev=0xc0 hdr=0x00 vendor = 'Intel Corporation' device = 'E7230/3000/3010 Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 rev=0xc0 hdr=0x01 vendor = 'Intel Corporation' device = 'E7230/3000/3010 PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub SATA cc=AHCI' class = mass storage ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '6700/6702PXH I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca rev=0x00 hdr=0x00 vendor = 'XGI Technology Inc' class = display subclass = VGA >dmesg: Copyright (c) 1992-2008 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 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2094850048 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard 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 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est0: Setting 1200 MHz p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Setting 1200 MHz p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 17 at device 28.0 on pci0 pci9: on pcib3 em0: port 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:91:44:c8 pcib4: irq 16 at device 28.1 on pci0 pci10: on pcib4 em1: port 0x5000-0x501f mem 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:91:44:c9 pcib5: irq 18 at device 28.2 on pci0 pci11: on pcib5 em2: port 0x6000-0x601f mem 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:91:44:ca pcib6: irq 19 at device 28.3 on pci0 pci12: on pcib6 em3: port 0x7000-0x701f mem 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:91:44:cb pcib7: at device 30.0 on pci0 pci15: on pcib7 vgapci0: port 0x8000-0x807f mem 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 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 NULL mp in getnewvnode() Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 200 packets/entry by default acd0: CDROM at ata0-master UDMA33 ad4: 239372MB at ata2-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a Sincerely yours, Sergey Prokofiev From proks at logos.sky.od.ua Fri May 16 15:58:41 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Fri May 16 15:58:43 2008 Subject: em0: watchdog timeout -- resetting Message-ID: <20080516185813.H866@logos.sky.od.ua> Hi All! I have a problem with Intel NIC after upgrade from 7-STABLE(25Mar2008,) to 7-STABLE(5May2008,) on motherboard Supermicro PDSMi-LN4+ http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm The NIC em0 is hangup at 16May with messages: May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN > kenv | grep smbios: smbios.bios.reldate="08/27/2007" smbios.bios.vendor="Phoenix Technologies LTD" smbios.bios.version="6.00" smbios.chassis.maker="Supermicro" smbios.chassis.serial="0123456789" smbios.chassis.tag=" " smbios.chassis.version="0123456789" smbios.planar.maker="Supermicro" smbios.planar.product="PDSMi-LN4+" smbios.planar.serial="0123456789" smbios.planar.version="PCB Version" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Supermicro" smbios.system.product="PDSMi-LN4" smbios.system.serial="0123456789" smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" smbios.system.version="0123456789" > pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 rev=0xc0 hdr=0x00 vendor = 'Intel Corporation' device = 'E7230/3000/3010 Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 rev=0xc0 hdr=0x01 vendor = 'Intel Corporation' device = 'E7230/3000/3010 PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub SATA cc=AHCI' class = mass storage ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '6700/6702PXH I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca rev=0x00 hdr=0x00 vendor = 'XGI Technology Inc' class = display subclass = VGA > dmesg: Copyright (c) 1992-2008 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 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2094850048 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard 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 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est0: Setting 1200 MHz p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Setting 1200 MHz p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 17 at device 28.0 on pci0 pci9: on pcib3 em0: port 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:91:44:c8 pcib4: irq 16 at device 28.1 on pci0 pci10: on pcib4 em1: port 0x5000-0x501f mem 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:91:44:c9 pcib5: irq 18 at device 28.2 on pci0 pci11: on pcib5 em2: port 0x6000-0x601f mem 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:91:44:ca pcib6: irq 19 at device 28.3 on pci0 pci12: on pcib6 em3: port 0x7000-0x701f mem 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:91:44:cb pcib7: at device 30.0 on pci0 pci15: on pcib7 vgapci0: port 0x8000-0x807f mem 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 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 NULL mp in getnewvnode() Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 200 packets/entry by default acd0: CDROM at ata0-master UDMA33 ad4: 239372MB at ata2-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a Sincerely yours, Sergey Prokofiev From jfvogel at gmail.com Fri May 16 16:05:35 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri May 16 16:05:38 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <20080516185813.H866@logos.sky.od.ua> References: <20080516185813.H866@logos.sky.od.ua> Message-ID: <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> Did you ever install the fix to the 82573 NIC eeprom? If not search mail archive for 82573, it's a DOS binary that will patch your prom. Also check for BIOS update from SM. Jack On Fri, May 16, 2008 at 8:58 AM, Prokofiev S.P. wrote: > > Hi All! > > I have a problem with Intel NIC after upgrade from > 7-STABLE(25Mar2008,) > to 7-STABLE(5May2008,) > on motherboard Supermicro PDSMi-LN4+ > http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm > > The NIC em0 is hangup at 16May with messages: > > May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting > May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed > May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware > May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN > >> kenv | grep smbios: > > smbios.bios.reldate="08/27/2007" > smbios.bios.vendor="Phoenix Technologies LTD" > smbios.bios.version="6.00" > smbios.chassis.maker="Supermicro" > smbios.chassis.serial="0123456789" > smbios.chassis.tag=" " > smbios.chassis.version="0123456789" > smbios.planar.maker="Supermicro" > smbios.planar.product="PDSMi-LN4+" > smbios.planar.serial="0123456789" > smbios.planar.version="PCB Version" > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="Supermicro" > smbios.system.product="PDSMi-LN4" > smbios.system.serial="0123456789" > smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" > smbios.system.version="0123456789" > >> pciconf -lv > > hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 > rev=0xc0 hdr=0x00 > vendor = 'Intel Corporation' > device = 'E7230/3000/3010 Processor to I/O Controller' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 > rev=0xc0 hdr=0x01 > vendor = 'Intel Corporation' > device = 'E7230/3000/3010 PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 > rev=0xe1 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface > to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface > Controller - 27B8' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GB I/O Controller Hub SATA cc=AHCI' > class = mass storage > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) SMBus Controller' > class = serial bus > subclass = SMBus > pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 > rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = '6702PXH PCI Express-to-PCI Express Bridge' > class = bridge > subclass = PCI-PCI > ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '6700/6702PXH I/OxAPIC Interrupt Controller A' > class = base peripheral > subclass = interrupt controller > em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller > (Copper)' > class = network > subclass = ethernet > em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca > rev=0x00 hdr=0x00 > vendor = 'XGI Technology Inc' > class = display > subclass = VGA > >> dmesg: > > Copyright (c) 1992-2008 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 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 > proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 > Features=0xbfebfbff > Features2=0xe39d > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 2146304000 (2046 MB) > avail memory = 2094850048 (1997 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > 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 0x1008-0x100b on acpi0 > cpu0: on acpi0 > est0: on cpu0 > est0: Setting 1200 MHz > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est1: Setting 1200 MHz > p4tcc1: on cpu1 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 17 at device 28.0 on pci0 > pci9: on pcib3 > em0: port 0x4000-0x401f mem > 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:91:44:c8 > pcib4: irq 16 at device 28.1 on pci0 > pci10: on pcib4 > em1: port 0x5000-0x501f mem > 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:30:48:91:44:c9 > pcib5: irq 18 at device 28.2 on pci0 > pci11: on pcib5 > em2: port 0x6000-0x601f mem > 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 > em2: Using MSI interrupt > em2: [FILTER] > em2: Ethernet address: 00:30:48:91:44:ca > pcib6: irq 19 at device 28.3 on pci0 > pci12: on pcib6 > em3: port 0x7000-0x701f mem > 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 > em3: Using MSI interrupt > em3: [FILTER] > em3: Ethernet address: 00:30:48:91:44:cb > pcib7: at device 30.0 on pci0 > pci15: on pcib7 > vgapci0: port 0x8000-0x807f mem > 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem > 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > atapci1: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > ichsmb0: port 0x1100-0x111f irq 19 > at device 31.3 on pci0 > ichsmb0: [GIANT-LOCKED] > ichsmb0: [ITHREAD] > smbus0: on ichsmb0 > smb0: on smbus0 > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 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 > NULL mp in getnewvnode() > Timecounters tick every 1.000 msec > ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding > enabled, default to accept, logging limited to 200 packets/entry by default > acd0: CDROM at ata0-master UDMA33 > ad4: 239372MB at ata2-master SATA300 > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad4s1a > > Sincerely yours, > Sergey Prokofiev > _______________________________________________ > 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 proks at logos.sky.od.ua Fri May 16 18:09:54 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Fri May 16 18:09:59 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> Message-ID: <20080516210223.A19166@logos.sky.od.ua> How install the fix to the 82573 NIC eeprom? Please help... On Fri, 16 May 2008, Jack Vogel wrote: > Did you ever install the fix to the 82573 NIC eeprom? If not > search mail archive for 82573, it's a DOS binary that will > patch your prom. Also check for BIOS update from SM. > > Jack > From jfvogel at gmail.com Fri May 16 18:51:23 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri May 16 18:51:28 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <20080516210223.A19166@logos.sky.od.ua> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <20080516210223.A19166@logos.sky.od.ua> Message-ID: <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> On Fri, May 16, 2008 at 11:09 AM, Prokofiev S.P. wrote: > > > How install the fix to the 82573 NIC eeprom? > Please help... Once you locate the fix its a zip file as I recall, when unzipped it is a DOS executable, you can make a driver diskette and then put the patcher on that (or a USB drive if you have one that is bootable) then run the patcher from DOS. I am not sure this is the source of your problem, but absolutely any SuperMicro system that has an 82573 should have this fix applied. Regards, Jack > On Fri, 16 May 2008, Jack Vogel wrote: > >> Did you ever install the fix to the 82573 NIC eeprom? If not >> search mail archive for 82573, it's a DOS binary that will >> patch your prom. Also check for BIOS update from SM. >> >> Jack >> > From linimon at FreeBSD.org Fri May 16 22:58:08 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri May 16 22:58:10 2008 Subject: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Message-ID: <200805162258.m4GMw7Yr000244@freefall.freebsd.org> Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 16 22:57:55 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From remko at FreeBSD.org Sat May 17 01:45:01 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat May 17 01:45:03 2008 Subject: kern/123726: page fault after ppp restart and pf resync Message-ID: <200805170145.m4H1j1Zs015239@freefall.freebsd.org> Synopsis: page fault after ppp restart and pf resync Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat May 17 01:44:37 UTC 2008 Responsible-Changed-Why: This could be something for the networking team. http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From mav at FreeBSD.org Sat May 17 08:40:03 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 17 08:40:05 2008 Subject: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Message-ID: <200805170840.m4H8e3NM077767@freefall.freebsd.org> The following reply was made to PR kern/123741; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, mimielliot@gmail.com Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Date: Sat, 17 May 2008 11:33:29 +0300 Alexander Motin wrote: > It looks like crash due to unchecked netgraph data items exhaustion. > Attached patch should fix this crash, but problem may remain in some > other symptoms. It would be good to investigate the reason of this > exhaustion. It could be or just high netgraph load or some resource leak. I was wrong. Bug actually is not there. This patch was going to hide original items allocation problem with NG_WAITOK. That was already fixed in HEAD and going to be merged. -- Alexander Motin From dfilter at FreeBSD.ORG Sat May 17 08:50:03 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat May 17 08:50:05 2008 Subject: kern/123741: commit references a PR Message-ID: <200805170850.m4H8o293078819@freefall.freebsd.org> The following reply was made to PR kern/123741; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123741: commit references a PR Date: Sat, 17 May 2008 08:43:56 +0000 (UTC) mav 2008-05-17 08:43:50 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/netgraph ng_base.c Log: MFC rev. 1.158 Use separate UMA zone for data items allocation. It is a partial rev. 1.149 rework. It allows to save several percents of CPU time on SMP by using UMA's internal per-CPU allocation limits instead of own global variable each time updated with atomics. Also it restores NG_WAITOK flag processing. PR: kern/123741 Revision Changes Path 1.135.2.9 +70 -40 src/sys/netgraph/ng_base.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Sat May 17 08:50:05 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat May 17 08:50:09 2008 Subject: kern/123741: commit references a PR Message-ID: <200805170850.m4H8o4MF078837@freefall.freebsd.org> The following reply was made to PR kern/123741; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123741: commit references a PR Date: Sat, 17 May 2008 08:46:05 +0000 (UTC) mav 2008-05-17 08:45:58 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) sys/netgraph ng_base.c Log: MFC rev. 1.158 Use separate UMA zone for data items allocation. It is a partial rev. 1.149 rework. It allows to save several percents of CPU time on SMP by using UMA's internal per-CPU allocation limits instead of own global variable each time updated with atomics. Also it restores NG_WAITOK flag processing. PR: kern/123741 Revision Changes Path 1.102.2.20 +70 -40 src/sys/netgraph/ng_base.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From mav at FreeBSD.org Sat May 17 09:20:03 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat May 17 09:20:06 2008 Subject: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Message-ID: <200805170920.m4H9K39h081328@freefall.freebsd.org> The following reply was made to PR kern/123741; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, mimielliot@gmail.com Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Date: Sat, 17 May 2008 11:15:52 +0300 This is a multi-part message in MIME format. --------------070906020506060104050902 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit It looks like crash due to unchecked netgraph data items exhaustion. Attached patch should fix this crash, but problem may remain in some other symptoms. It would be good to investigate the reason of this exhaustion. It could be or just high netgraph load or some resource leak. -- Alexander Motin --------------070906020506060104050902 Content-Type: text/plain; name="ng_socket.c.enomem.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ng_socket.c.enomem.patch" --- ng_socket.c.prev 2008-03-11 23:58:48.000000000 +0200 +++ ng_socket.c 2008-05-17 10:36:46.000000000 +0300 @@ -732,7 +732,8 @@ ng_connect_data(struct sockaddr *nam, st sap = (struct sockaddr_ng *) nam; /* The item will hold the node reference. */ - item = ng_package_data(NULL, NG_WAITOK); + if ((item = ng_package_data(NULL, NG_WAITOK)) == NULL) + return (ENOMEM); if ((error = ng_address_path(NULL, item, sap->sg_data, 0))) return (error); /* item is freed on failure */ --------------070906020506060104050902-- From mav at FreeBSD.org Sat May 17 09:46:45 2008 From: mav at FreeBSD.org (mav@FreeBSD.org) Date: Sat May 17 09:46:48 2008 Subject: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Message-ID: <200805170946.m4H9kjhd083811@freefall.freebsd.org> Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd State-Changed-From-To: open->patched State-Changed-By: mav State-Changed-When: Sat May 17 09:44:34 UTC 2008 State-Changed-Why: Problem should be fixed with recent commits. http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From matteo at FreeBSD.org Sat May 17 10:52:53 2008 From: matteo at FreeBSD.org (matteo@FreeBSD.org) Date: Sat May 17 10:52:55 2008 Subject: kern/116185: [iwi] if_iwi driver leads system to reboot Message-ID: <200805171052.m4HAqrto091588@freefall.freebsd.org> Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: open->feedback State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 10:52:14 UTC State-Changed-Why: Can you still experience this problem on newer FreeBSD releases? http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From matteo at FreeBSD.org Sat May 17 12:32:52 2008 From: matteo at FreeBSD.org (matteo@FreeBSD.org) Date: Sat May 17 12:32:54 2008 Subject: kern/116185: [iwi] if_iwi driver leads system to reboot Message-ID: <200805171232.m4HCWp9M001730@freefall.freebsd.org> Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: feedback->closed State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 12:32:07 UTC State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From matteo at FreeBSD.org Sat May 17 12:33:27 2008 From: matteo at FreeBSD.org (matteo@FreeBSD.org) Date: Sat May 17 12:33:33 2008 Subject: kern/116185: [iwi] if_iwi driver leads system to reboot Message-ID: <200805171233.m4HCXQYb002061@freefall.freebsd.org> Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: closed->open State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 12:32:55 UTC State-Changed-Why: I wrongly closed this PR. Submitter cannot upgrade to 7.x so we still need to keep this open. http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From johan at stromnet.se Sat May 17 14:48:56 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sat May 17 14:49:00 2008 Subject: connect(): Operation not permitted Message-ID: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Hello I got a FreeBSD 7 machine running mail services (among other things). This machine recently replaced a FreeBSD 6.2 machine doing the same tasks. Now and then I need to send alot of mail to customers (mailing list), and one thing i've noticed now after the change is that when I use a lot of connections subsequently (high connection rate, even if they are very shortlived) inside a jail (dunno if that has anything to do with it though), I start to get Operation not permitted in return to connect(). I've seen this in the PHP app that sends mail, when it tried to connect to localhost, as well as from postfix when it have been trying to connect to amavisd on localhost, but also from postfix when it has tried to connect to remote SMTP servers. I do have PF for filtering, but there are no max-src-conn-rate limits enabled for any rules that is used for this. However, from one of the jail I do have a hfsc queue limiting the outgoing mail traffic from one jailed IP. But I'm not sure that this would be the problem, since I've also seen the problem when doing localhost connects in the jail, and also in other jails on an entierly different IP that is not affected. Does anyone have any clues about what I can look at and tune to fix this? Thanks! -- Johan Str?m Stromnet johan@stromnet.se http://www.stromnet.se/ From alex at trull.org Sat May 17 15:36:54 2008 From: alex at trull.org (Alex Trull) Date: Sat May 17 15:37:02 2008 Subject: connect(): Operation not permitted In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Message-ID: <1211037564.6326.27.camel@porksoda> Hi Johan and List, In my case a few months ago it was pahu. Don't give that fine fellow an account on your precious system ! But seriously, I had a pf-firewalled jail being being used for DNS testing, with large numbers of udp "connections" hanging around in pf state. While the default udp timeout settings in PF are lower than those of the tcp timeouts, it is was still too high for it to to remove the states in time before hitting the default 10k state limit! If this is the case with you - run 'pfctl -s state | wc -l' - when there is traffic load you may see that hitting 10k states if you've not tuned that variable. What to do next - up the state limit or lower the state timeouts. I did both, to be safe. in /etc/pf.conf these must be at the very top of the file: # options # 10k is insanely low, lets raise it.. set limit { frags 16384, states 32768 } # timeouts - see 'pfctl -s timeouts' for options - you will want to # change the tcp ones rather than the udp ones for your smtp setup. # but these are mine, I set them for the dns traffic. set timeout { udp.first 15, udp.single 5, udp.multiple 30 } don't forget to: $ /etc/rc.d/pf check && ?/etc/rc.d/pf reload HTH, Alex On Sat, 2008-05-17 at 16:33 +0200, Johan Str?m wrote: > Hello > > I got a FreeBSD 7 machine running mail services (among other things). > This machine recently replaced a FreeBSD 6.2 machine doing the same > tasks. > Now and then I need to send alot of mail to customers (mailing list), > and one thing i've noticed now after the change is that when I use a > lot of connections subsequently (high connection rate, even if they > are very shortlived) inside a jail (dunno if that has anything to do > with it though), I start to get Operation not permitted in return to > connect(). > I've seen this in the PHP app that sends mail, when it tried to > connect to localhost, as well as from postfix when it have been trying > to connect to amavisd on localhost, but also from postfix when it has > tried to connect to remote SMTP servers. > > I do have PF for filtering, but there are no max-src-conn-rate limits > enabled for any rules that is used for this. However, from one of the > jail I do have a hfsc queue limiting the outgoing mail traffic from > one jailed IP. But I'm not sure that this would be the problem, since > I've also seen the problem when doing localhost connects in the jail, > and also in other jails on an entierly different IP that is not > affected. > > Does anyone have any clues about what I can look at and tune to fix > this? > > Thanks! > > -- > Johan Str?m > Stromnet > johan@stromnet.se > http://www.stromnet.se/ > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080517/32b9a1b0/attachment.pgp From koitsu at FreeBSD.org Sat May 17 15:40:18 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat May 17 15:40:22 2008 Subject: connect(): Operation not permitted In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Message-ID: <20080517152348.GA64850@eos.sc1.parodius.com> On Sat, May 17, 2008 at 04:33:20PM +0200, Johan Str?m wrote: > Hello > > I got a FreeBSD 7 machine running mail services (among other things). This > machine recently replaced a FreeBSD 6.2 machine doing the same tasks. > Now and then I need to send alot of mail to customers (mailing list), and > one thing i've noticed now after the change is that when I use a lot of > connections subsequently (high connection rate, even if they are very > shortlived) inside a jail (dunno if that has anything to do with it > though), I start to get Operation not permitted in return to connect(). > I've seen this in the PHP app that sends mail, when it tried to connect to > localhost, as well as from postfix when it have been trying to connect to > amavisd on localhost, but also from postfix when it has tried to connect to > remote SMTP servers. > > I do have PF for filtering, but there are no max-src-conn-rate limits > enabled for any rules that is used for this. However, from one of the jail > I do have a hfsc queue limiting the outgoing mail traffic from one jailed > IP. But I'm not sure that this would be the problem, since I've also seen > the problem when doing localhost connects in the jail, and also in other > jails on an entierly different IP that is not affected. > > Does anyone have any clues about what I can look at and tune to fix this? Operation not permitted is most commonly seen on machines using pf(4), where there are rules blocking certain outbound traffic. I believe this has nothing to do with max-src-conn-rate. Chances are some of your pf(4) rules are wrong. There is also the possibility that jails are causing your problem. I have no experience with jails, so I cannot comment on that. I'd consider re-posting your problem to freebsd-pf@freebsd.org, and include your entire pf ruleset, so people could analyse it. Output from "pfctl -s info" would also be benefitial. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From johan at stromnet.se Sat May 17 16:01:19 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sat May 17 16:01:23 2008 Subject: connect(): Operation not permitted In-Reply-To: <1211037564.6326.27.camel@porksoda> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> Message-ID: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> First of all, for freebsd-pf subscribers, I posted my original problem (in the bottom) to freebsd-net earlier, but replies seems to point to PF so I'll CC there too.. On May 17, 2008, at 5:19 PM, Alex Trull wrote: > Hi Johan and List, > > In my case a few months ago it was pahu. Don't give that fine fellow > an > account on your precious system ! > > > But seriously, I had a pf-firewalled jail being being used for DNS > testing, with large numbers of udp "connections" hanging around in pf > state. While the default udp timeout settings in PF are lower than > those > of the tcp timeouts, it is was still too high for it to to remove the > states in time before hitting the default 10k state limit! > > If this is the case with you - run 'pfctl -s state | wc -l' - when > there > is traffic load you may see that hitting 10k states if you've not > tuned > that variable. > > What to do next - up the state limit or lower the state timeouts. I > did > both, to be safe. > > in /etc/pf.conf these must be at the very top of the file: > > # options > # 10k is insanely low, lets raise it.. > set limit { frags 16384, states 32768 } > # timeouts - see 'pfctl -s timeouts' for options - you will want to > # change the tcp ones rather than the udp ones for your smtp setup. > # but these are mine, I set them for the dns traffic. > set timeout { udp.first 15, udp.single 5, udp.multiple 30 } > > > don't forget to: > > $ /etc/rc.d/pf check && /etc/rc.d/pf reload Ok, looked over the PF states now, but I'm not quite sure thats what causing it. I have default limit on 10k states, normally I seem to have around ~800 states, and when I start my test script that tries to send as many mails as possible (using PHP's Pear::Mail, creating a connection, sending, disconnecting, creating new connection.. and so on), I can clearly see the PF state counter (pfctl -vsi) increase, but the script aborts with Operation not permitted way before I hit 10k, its rather around 3-4k.. If I then wait a few seconds and run the script again, I can see the number of states increase even more, and if I do this enough times I finally hit around 9700 states. But at this point (states exhausted), I don't get Operation not permitted, instead it just seems that the script blocks up a few seconds while states clear up, then continues running until it gets a Operation not permitted. So, from the above results, I cant say that it looks like its the states? Just tried to disable the altq rule now too, no changes (not that I expected one, since its on bce0 not lo0). Another thing, which might be more approriate in freebsd-pf though.. Why would it create states at all for this traffic, when my pf.conf rule is "pass on lo0 inet from $jail to $jail" (i have a block drop in rule to drop all traffic)? A check with pfctl -vsr reveals that the actual rule inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags S/SA keep state". Where did that "keep state" come from? Thanks for ideas :) > > > HTH, > > Alex > > On Sat, 2008-05-17 at 16:33 +0200, Johan Str?m wrote: >> Hello >> >> I got a FreeBSD 7 machine running mail services (among other things). >> This machine recently replaced a FreeBSD 6.2 machine doing the same >> tasks. >> Now and then I need to send alot of mail to customers (mailing list), >> and one thing i've noticed now after the change is that when I use a >> lot of connections subsequently (high connection rate, even if they >> are very shortlived) inside a jail (dunno if that has anything to do >> with it though), I start to get Operation not permitted in return to >> connect(). >> I've seen this in the PHP app that sends mail, when it tried to >> connect to localhost, as well as from postfix when it have been >> trying >> to connect to amavisd on localhost, but also from postfix when it has >> tried to connect to remote SMTP servers. >> >> I do have PF for filtering, but there are no max-src-conn-rate limits >> enabled for any rules that is used for this. However, from one of the >> jail I do have a hfsc queue limiting the outgoing mail traffic from >> one jailed IP. But I'm not sure that this would be the problem, since >> I've also seen the problem when doing localhost connects in the jail, >> and also in other jails on an entierly different IP that is not >> affected. >> >> Does anyone have any clues about what I can look at and tune to fix >> this? >> >> Thanks! >> >> -- >> Johan Str?m >> Stromnet >> johan@stromnet.se >> http://www.stromnet.se/ >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " From remko at FreeBSD.org Sat May 17 23:51:05 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat May 17 23:51:09 2008 Subject: kern/123147: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does Message-ID: <200805172351.m4HNp51n067623@freefall.freebsd.org> Synopsis: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does State-Changed-From-To: open->patched State-Changed-By: remko State-Changed-When: Sat May 17 23:50:45 UTC 2008 State-Changed-Why: reassign to myself after having this committed to HEAD Responsible-Changed-From-To: freebsd-net->remko Responsible-Changed-By: remko Responsible-Changed-When: Sat May 17 23:50:45 UTC 2008 Responsible-Changed-Why: reassign to myself after having this committed to HEAD http://www.freebsd.org/cgi/query-pr.cgi?pr=123147 From m.seaman at infracaninophile.co.uk Sun May 18 07:19:37 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun May 18 07:19:42 2008 Subject: connect(): Operation not permitted In-Reply-To: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> Message-ID: <482FD877.6050707@infracaninophile.co.uk> Johan Str?m wrote: > drop all traffic)? A check with pfctl -vsr reveals that the actual rule > inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 > flags S/SA keep state". Where did that "keep state" come from? 'flags S/SA keep state' is the default now for tcp filter rules -- that was new in 7.0 reflecting the upstream changes made between the 4.0 and 4.1 releases of OpenBSD. If you want a stateless rule, append 'no state'. http://www.openbsd.org/faq/pf/filter.html#state Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080518/3ba12348/signature.pgp From johan at stromnet.se Sun May 18 10:33:58 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sun May 18 10:34:01 2008 Subject: connect(): Operation not permitted In-Reply-To: <482FD877.6050707@infracaninophile.co.uk> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > Johan Str?m wrote: > >> drop all traffic)? A check with pfctl -vsr reveals that the actual >> rule inserted is "pass on lo0 inet from 123.123.123.123 to >> 123.123.123.123 flags S/SA keep state". Where did that "keep state" >> come from? > > 'flags S/SA keep state' is the default now for tcp filter rules -- > that > was new in 7.0 reflecting the upstream changes made between the 4.0 > and 4.1 > releases of OpenBSD. If you want a stateless rule, append 'no state'. > > http://www.openbsd.org/faq/pf/filter.html#state Thanks! I was actually looking around in the pf.conf manpage but failed to find it yesterday, but looking closer today I now saw it. Applied the no state (and quick) to the rule, and now no state is created. And the problem I had in the first place seems to have been resolved too now, even though it didn't look like a state problem.. (started to deny new connections much earlier than the states was full, altough maybee i wasnt looking for updates fast enough or something). Anyways, thanks to all helping me out, and of course thanks to everybody involved in FreeBSD/pf and all for great products! Cannot be said enough times ;) From vwe at FreeBSD.org Sun May 18 16:59:45 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun May 18 16:59:48 2008 Subject: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Message-ID: <200805181659.m4IGxisL085246@freefall.freebsd.org> Old Synopsis: page fault after ppp restart and pf resync New Synopsis: [panic] [altq] page fault after ppp restart and pf resync Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 18 16:57:03 UTC 2008 Responsible-Changed-Why: altq is Max' territory - reassign also please note, this PR is a slightly different DUP to similar PRs (problem is caused by altq when interfaces disappear) http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From kian.mohageri at gmail.com Sun May 18 17:54:57 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Sun May 18 17:55:00 2008 Subject: connect(): Operation not permitted In-Reply-To: References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: > On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > >> Johan Str?m wrote: >> >>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>> S/SA keep state". Where did that "keep state" come from? >> >> 'flags S/SA keep state' is the default now for tcp filter rules -- that >> was new in 7.0 reflecting the upstream changes made between the 4.0 and >> 4.1 >> releases of OpenBSD. If you want a stateless rule, append 'no state'. >> >> http://www.openbsd.org/faq/pf/filter.html#state > > Thanks! I was actually looking around in the pf.conf manpage but failed to > find it yesterday, but looking closer today I now saw it. > Applied the no state (and quick) to the rule, and now no state is created. > And the problem I had in the first place seems to have been resolved too > now, even though it didn't look like a state problem.. (started to deny new > connections much earlier than the states was full, altough maybee i wasnt > looking for updates fast enough or something). > I'd be willing to bet it's because you're reusing the source port on a new connection before the old state expires. You'll know if you check the state-mismatch counter. Anyway, glad you found a resolution. -Kian From jay at jcornwall.me.uk Sun May 18 20:27:23 2008 From: jay at jcornwall.me.uk (Jay L. T. Cornwall) Date: Sun May 18 20:27:28 2008 Subject: if_bridge with two subnets In-Reply-To: <48286052.6000507@sepehrs.com> References: <4825EF8D.1050304@jcornwall.me.uk> <4826EB42.104@sepehrs.com> <48274E6D.9060704@jcornwall.me.uk> <48286052.6000507@sepehrs.com> Message-ID: <48309128.1020101@jcornwall.me.uk> H.fazaeli wrote: > It does work. However, if I understand your setup correctly, the freebsd > box > has been setup to act as a bridge, not as a router (routing is enabled with > sysctl net.inet.ip.forwarding=1). Bridging works when the forwarding is > between the same subnets. > > For freebsd box to route between subnets: > - enable routing: sysctl net.inet.ip.forwarding=1 > - clients must use the freebsd box as gateway. > - IP addresses must be removed from the bridge and assigned to > the member interfaces. (the bridge is no longer needed). > > You may have bridging & routing on the same box at the same time but > note that a single packet coming into the system either goes through > bridging _or_ routing code, but not both. The former case happens > if packet's destination MAC address is not that of box. The > latter case happens when destination MAC address is that of receiving > interface. Thank you very much for your explanation. I had misunderstood precisely how routing and bridging are done in FreeBSD but it now makes sense. > If you provide a network diagram along with your requirements, > we can better discuss the matter. I now have a working network configuration. For completeness I will explain how it's set up. I have a small, publicly routable netblock to serve a larger LAN of machines. Thus some of the machines draw IPs from a non-routable private pool and are NAT'd to a one of the public IPs. It looks like this: [Gateway] XX.XX.XXX.22 | [FreeBSD] XX.XX.XXX.20-21 | [L2 Switch] | PCs XX.XX.XXX.17-19 192.168.1.0/24 The gateway must have one of the public IPs to communicate with its upstream correctly. On the other side of the FreeBSD server the rest of those IPs are used. So a traditional gateway setup would not work here: it would imply that the FreeBSD server has two interfaces from two different subnets, rather than one split subnet. Perhaps a static route for the gateway would work, but it would be messy. So I bridge the two interfaces to join the public subnet. Following your advice I have set the FreeBSD server to the network gateway - previously it was the .22 gateway - and now all of the LAN PCs can communicate without additional routing information. Inter-subnet packets will bounce off the FreeBSD server, rather than staying inside the L2 switch, but that's OK. -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From linimon at FreeBSD.org Sun May 18 22:47:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun May 18 22:47:37 2008 Subject: kern/123796: FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work Message-ID: <200805182247.m4IMlYqq015759@freefall.freebsd.org> Old Synopsis: Port mapping does not work New Synopsis: FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 18 22:45:21 UTC 2008 Responsible-Changed-Why: Rescue this PR from the 'pending' category. http://www.freebsd.org/cgi/query-pr.cgi?pr=123796 From mjl at luckie.org.nz Mon May 19 08:17:41 2008 From: mjl at luckie.org.nz (Matthew Luckie) Date: Mon May 19 08:17:45 2008 Subject: rtadvd/rrenum.c:179 Message-ID: <20080519074852.GA62290@spandex.luckie.org.nz> When rtadvd is compiled on 7.0, the following warning is emitted: /usr/src/usr.sbin/rtadvd/rrenum.c:179: warning: overflow in implicit constant conversion I have not determined if the code works correct or not, but I wonder if it does. the line in question is this: struct irr_raflagmask { u_char onlink : 1; u_char autonomous : 1; u_char reserved : 6; } irr_raflagmask; irr->irr_raf_mask_onlink = (rpu->rpu_ramask & ICMP6_RR_PCOUSE_RAFLAGS_ONLINK); rpu_ramask is unsigned char, the constant is 0x80, and irr_raf_mask_onlink is a single bit value. This troubles me, and the compiler. I'm only raising this for consideration; if it can be determined that the code works correctly, maybe a commit can be made to silence the warnings. --- rrenum.c.orig 2004-03-10 21:46:39.000000000 +1300 +++ rrenum.c 2008-05-19 19:39:52.000000000 +1200 @@ -176,9 +176,9 @@ do_use_prefix(int len, struct rr_pco_mat irr->irr_u_uselen = rpu->rpu_uselen; irr->irr_u_keeplen = rpu->rpu_keeplen; irr->irr_raf_mask_onlink = - (rpu->rpu_ramask & ICMP6_RR_PCOUSE_RAFLAGS_ONLINK); + (rpu->rpu_ramask & ICMP6_RR_PCOUSE_RAFLAGS_ONLINK) == 0 ? 0 : 1; irr->irr_raf_mask_auto = - (rpu->rpu_ramask & ICMP6_RR_PCOUSE_RAFLAGS_AUTO); + (rpu->rpu_ramask & ICMP6_RR_PCOUSE_RAFLAGS_AUTO) == 0 ? 0 : 1; irr->irr_vltime = ntohl(rpu->rpu_vltime); irr->irr_pltime = ntohl(rpu->rpu_pltime); irr->irr_raf_onlink = From mlaier at FreeBSD.org Mon May 19 09:14:33 2008 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Mon May 19 09:14:36 2008 Subject: kern/78090: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Message-ID: <200805190914.m4J9EXq8000504@freefall.freebsd.org> Synopsis: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Responsible-Changed-From-To: freebsd-pf->freebsd-net Responsible-Changed-By: mlaier Responsible-Changed-When: Mon May 19 09:12:31 UTC 2008 Responsible-Changed-Why: This is not a pf problem. Also note that the old bridge implementation, to which this PR relates to, is obsolete by if_bridge(4) and likely no longer maintained. Over to freebsd-net in case somebody is still interested. http://www.freebsd.org/cgi/query-pr.cgi?pr=78090 From mlaier at FreeBSD.org Mon May 19 09:17:11 2008 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Mon May 19 09:17:14 2008 Subject: kern/102344: [ipf] Some packets do not pass through network interface Message-ID: <200805190917.m4J9HAMx000563@freefall.freebsd.org> Synopsis: [ipf] Some packets do not pass through network interface State-Changed-From-To: open->feedback State-Changed-By: mlaier State-Changed-When: Mon May 19 09:15:26 UTC 2008 State-Changed-Why: The submitter has been asked for configuration details over a year ago. Responsible-Changed-From-To: freebsd-pf->freebsd-net Responsible-Changed-By: mlaier Responsible-Changed-When: Mon May 19 09:15:26 UTC 2008 Responsible-Changed-Why: Not a pf problem. Reassign to freebsd-net. http://www.freebsd.org/cgi/query-pr.cgi?pr=102344 From bugmaster at FreeBSD.org Mon May 19 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:07:38 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200805191106.m4JB6uxc011656@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123123 net [re][patch] Realtek RTL8111C detection and failure o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not 79 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re][patch] re(4) unsupported hardware revision (8168/ 45 problems total. From marcolz at stack.nl Mon May 19 12:10:04 2008 From: marcolz at stack.nl (Marc Olzheim) Date: Mon May 19 12:10:06 2008 Subject: kern/116185: [iwi] if_iwi driver leads system to reboot Message-ID: <200805191210.m4JCA3D4019959@freefall.freebsd.org> The following reply was made to PR kern/116185; it has been noted by GNATS. From: Marc Olzheim To: matteo@FreeBSD.org, bug-followup@FreeBSD.org Cc: ggg_mail@inbox.ru, freebsd-net@FreeBSD.org, Marc Olzheim Subject: Re: kern/116185: [iwi] if_iwi driver leads system to reboot Date: Mon, 19 May 2008 14:00:45 +0200 > Can you still experience this problem on newer FreeBSD releases? Something similar, probably related happens on my laptop (HP pavillion dv6570ed) with a 3945abg chipset. wpa_supplicant can negotiate fine, but as soon as dhclient runs, the box panics. I haven't had time to set up proper dumping yet, so alas, I have no detailed information at this point. Marc From sclark46 at earthlink.net Mon May 19 12:17:13 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Mon May 19 12:17:17 2008 Subject: kern/123796: FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work In-Reply-To: <200805182247.m4IMlYqq015759@freefall.freebsd.org> References: <200805182247.m4IMlYqq015759@freefall.freebsd.org> Message-ID: <48316B98.5010503@earthlink.net> linimon@freebsd.org wrote: > Old Synopsis: Port mapping does not work > New Synopsis: FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not work > > Responsible-Changed-From-To: gnats-admin->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun May 18 22:45:21 UTC 2008 > Responsible-Changed-Why: > Rescue this PR from the 'pending' category. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=123796 > _______________________________________________ > 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" > I had a similar problem until I turned on "options IPSEC_FILTERGIF" in my kernel config. Otherwise stuff coming out of the vpn tunnel doesn't go thru ipf. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From proks at logos.sky.od.ua Mon May 19 12:20:39 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Mon May 19 12:20:44 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <20080516210223.A19166@logos.sky.od.ua> <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> Message-ID: <20080519150851.W43593@logos.sky.od.ua> I understand it, but where is the patch ? I found the mailist http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-10/msg00754.html and that http://blog.pfsense.org/?m=200711 but link http://www.higherorder.com.au/2007/6/25/intel_82573_patch is broked... On Fri, 16 May 2008, Jack Vogel wrote: > On Fri, May 16, 2008 at 11:09 AM, Prokofiev S.P. wrote: >> >> >> How install the fix to the 82573 NIC eeprom? >> Please help... > > Once you locate the fix its a zip file as I recall, when unzipped it is > a DOS executable, you can make a driver diskette and then put > the patcher on that (or a USB drive if you have one that is bootable) > then run the patcher from DOS. > > I am not sure this is the source of your problem, but absolutely any > SuperMicro system that has an 82573 should have this fix applied. > > Regards, > > Jack > >> On Fri, 16 May 2008, Jack Vogel wrote: >> >>> Did you ever install the fix to the 82573 NIC eeprom? If not >>> search mail archive for 82573, it's a DOS binary that will >>> patch your prom. Also check for BIOS update from SM. >>> >>> Jack >>> >> > From marcolz at stack.nl Mon May 19 12:32:15 2008 From: marcolz at stack.nl (Marc Olzheim) Date: Mon May 19 12:32:20 2008 Subject: kern/116185: [iwi] if_iwi driver leads system to reboot In-Reply-To: <200805171052.m4HAqrto091588@freefall.freebsd.org> References: <200805171052.m4HAqrto091588@freefall.freebsd.org> Message-ID: <20080519120045.GA22238@zlo.nu> > Can you still experience this problem on newer FreeBSD releases? Something similar, probably related happens on my laptop (HP pavillion dv6570ed) with a 3945abg chipset. wpa_supplicant can negotiate fine, but as soon as dhclient runs, the box panics. I haven't had time to set up proper dumping yet, so alas, I have no detailed information at this point. Marc From mk at neon1.net Mon May 19 12:50:04 2008 From: mk at neon1.net (Manuel Kasper) Date: Mon May 19 12:50:06 2008 Subject: kern/78090: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Message-ID: <200805191250.m4JCo44W024651@freefall.freebsd.org> The following reply was made to PR kern/78090; it has been noted by GNATS. From: Manuel Kasper To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/78090: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Date: Mon, 19 May 2008 14:13:43 +0200 This PR can be closed as far as I'm concerned. It's been more than three years anyway :) m0n0wall has a workaround/fix for this now (see http://svn.m0n0.ch/wall/branches/freebsd6/build/patches/kernel/kernel-6.patch) , and as mlaier pointed out, BRIDGE is deprecated anyway and we should switch to if_bridge. - Manuel From john at dnepro.net Mon May 19 13:07:27 2008 From: john at dnepro.net (Eugene Perevyazko) Date: Mon May 19 13:07:34 2008 Subject: How to inject fullsize 802.1q-tagged frame through BPF? In-Reply-To: <482C6303.9000904@freebsd.org> References: <20080515152607.GA36663@roof1.dnepro.net> <482C6303.9000904@freebsd.org> Message-ID: <20080519130722.GA40822@roof1.dnepro.net> On Thu, May 15, 2008 at 12:21:23PM -0400, Sam Leffler wrote: > Eugene Perevyazko wrote: > > Is there a way to inject full-mtu vlan-tagged frame through BPF on parent > >device? > > I'd like not to open several tenths of BPFs for each vlanN if it's > > possible. > > bpf write code in the kernel calculates header size when packets are > injected. This is likely based on the frames being stock 802.3 so would > require mods to the bpf code to handle the additional space for the tag. I've made a simple patch that works for me on FreeBSD 6.2-RELEASE #1. Not sure if this is the way to do it, but it "just works". May be someone else will need such feature too. Eugene Perevyazko --- bpf.c.old Mon May 19 10:47:55 2008 +++ bpf.c Mon May 19 10:57:44 2008 @@ -64,6 +64,7 @@ #include #include +#include #include #include @@ -617,7 +618,9 @@ return (0); bzero(&dst, sizeof(dst)); - error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, ifp->if_mtu, + /* Use VLAN_MTU capability, if supported */ + error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, + ifp->if_mtu + ( (ifp->if_capenable & IFCAP_VLAN_MTU) ? ETHER_VLAN_ENCAP_LEN : 0 ), &m, &dst, d->bd_wfilter); if (error) return (error); From jhb at freebsd.org Mon May 19 15:10:03 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 19 15:10:09 2008 Subject: amd64/123603: tcp_do_segment and Received duplicate SYN Message-ID: <200805191510.m4JFA2vP035587@freefall.freebsd.org> The following reply was made to PR kern/123603; it has been noted by GNATS. From: John Baldwin To: freebsd-amd64@freebsd.org Cc: John , freebsd-gnats-submit@freebsd.org, andre@FreeBSD.org Subject: Re: amd64/123603: tcp_do_segment and Received duplicate SYN Date: Mon, 19 May 2008 10:06:40 -0400 On Monday 12 May 2008 03:45:16 am John wrote: > >Number: 123603 > >Category: amd64 > >Synopsis: tcp_do_segment and Received duplicate SYN > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Mon May 12 07:50:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: John > >Release: FB7.0 (x64) > >Organization: > > NULL > > >Environment: > > FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar 6 > 12:04:57 HKT 2008 root@mydomain.com:/usr/src/sys/amd64/compile/FB7NEW > amd64 > > >Description: > > A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and patchs. > when a client connect and view a static HTML file, At the first time > (before web server idle time), it needs to wait a long time to establish a > connection, OR when this server try to download file from Internet, there > are lots of logs messages just like below: > > May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44]:80 > tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer > and retransmitting SYN|ACK > May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to > [11.22.33.44]:63372 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: > Received 1448 bytes of data after socket was closed, sending RST and > removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to > [11.22.33.44]:55007 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: > Received 13 bytes of data after socket was closed, sending RST and removing > tcpcb > > >How-To-Repeat: > > any type of connection will generate above log messages. You can either comment out all the log(LOG_DEBUG, ...) calls in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send kern.debug messages to the console. I think these messages should probably be conditional on a kernel option FWIW. -- John Baldwin From proks at logos.sky.od.ua Mon May 19 15:55:32 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Mon May 19 15:55:36 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <20080516210223.A19166@logos.sky.od.ua> <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> Message-ID: <20080519185013.O80128@logos.sky.od.ua> I found the fix utility on link http://www.mullet.se/support/dcgdis.zip and run under DOS, but it answer - " Update not needed" ! Sergey From mwm at mired.org Mon May 19 16:46:46 2008 From: mwm at mired.org (Mike Meyer) Date: Mon May 19 16:46:49 2008 Subject: Net Mask Prob! In-Reply-To: <20080519063133.GA54791@eos.sc1.parodius.com> References: <130587.38887.qm@web46316.mail.sp1.yahoo.com> <20080519063133.GA54791@eos.sc1.parodius.com> Message-ID: <20080519122000.526b2964@mbook.local> On Sun, 18 May 2008 23:31:33 -0700 Jeremy Chadwick wrote: > On Sun, May 18, 2008 at 09:40:37PM -0700, John Timony wrote: > > Hi,all > > ? > > I have installed Freebsd 7.0 on my Acer TravelMate 220,my router ip is 192.168.0.1,the ip of my Freebsd is 192.168.1.4,Net Mask is 255.255.0.0,Why my system can not connect wiht the router? > > ? > > any idea? > > Chances are your router uses 255.255.255.0 as a default netmask; most > residential routers do. FreeBSD doesn't have any issues/bugs relating > to netmasks which would cause what you're seeing. Freebsd should be using 255.255.255.0 as a default netmask for the 192.168 block as well. That's what it's defined to be. Changing that means fixing it everywhere. Also, as you get further from common setups, residential and soho routers tend to get flakier. Given that most users of such don't have hundreds of hosts and don't need two internal networks, a /23 in 192.168.0.0 qualifies as uncommon; it certainly gave me fits. I found that splitting the /24 into a pair of /25s worked better. > Additionally, your request probably should have gone to -net, not > -hackers. Yup. Hi all, In an attempt to change from pppoed + ppp to mpd I'm having some strange behaviour with the later on the same host that usually handles 100+ clients with the former. Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. Users can connect without any problem. After a few minutes a SECOND mpd process is initiated and this one consumes all idle processing of the host. Whoever is connected before that still remains connected but no new user can get in anymore. Also logging stops being generated. The only solution is a killall -KILL on mpd. On another host I have the same configuration working as expected but with less than 50 clients. Both configurations are the same from mpd.conf.sample. So I'm looking for any suggestions that somebody has been using to handle that many pppoe connections (100+) with mpd. Thanks, -- Einstein Oliveira einstein@yawl.com.br ___________________________________________________ Yawl Internet Ltda. http://www.yawl.com.br/ From julian at elischer.org Mon May 19 17:55:59 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 19 17:56:04 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831B670.7060502@yawl.com.br> References: <4831B670.7060502@yawl.com.br> Message-ID: <4831BF2D.3040802@elischer.org> Einstein Oliveira wrote: > Hi all, > > In an attempt to change from pppoed + ppp to mpd I'm having some strange > behaviour with the later on the same host that usually handles 100+ > clients with the former. > > Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. > Users can connect without any problem. > > After a few minutes a SECOND mpd process is initiated and this one > consumes all idle processing of the host. > > Whoever is connected before that still remains connected but no new user > can get in anymore. Also logging stops being generated. > > The only solution is a killall -KILL on mpd. > > On another host I have the same configuration working as expected but > with less than 50 clients. > > Both configurations are the same from mpd.conf.sample. > > So I'm looking for any suggestions that somebody has been using to > handle that many pppoe connections (100+) with mpd. > > > > Thanks, > people have handled many more than 100 I think.. however there is no reason that a 2nd should start up. what is teh PPID of the 2nd? are you sure that it isn't being started up by whatever starts up the first? From einstein at yawl.com.br Mon May 19 18:22:05 2008 From: einstein at yawl.com.br (Einstein Oliveira) Date: Mon May 19 18:22:09 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831BF2D.3040802@elischer.org> References: <4831B670.7060502@yawl.com.br> <4831BF2D.3040802@elischer.org> Message-ID: <4831C56C.8090708@yawl.com.br> Julian Elischer wrote: > Einstein Oliveira wrote: >> Hi all, >> >> In an attempt to change from pppoed + ppp to mpd I'm having some >> strange behaviour with the later on the same host that usually handles >> 100+ clients with the former. >> >> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. >> Users can connect without any problem. >> >> After a few minutes a SECOND mpd process is initiated and this one >> consumes all idle processing of the host. >> >> Whoever is connected before that still remains connected but no new >> user can get in anymore. Also logging stops being generated. >> >> The only solution is a killall -KILL on mpd. >> >> On another host I have the same configuration working as expected but >> with less than 50 clients. >> >> Both configurations are the same from mpd.conf.sample. >> >> So I'm looking for any suggestions that somebody has been using to >> handle that many pppoe connections (100+) with mpd. >> >> >> >> Thanks, >> > > > people have handled many more than 100 I think.. > however there is no reason that a 2nd should start up. > what is teh PPID of the 2nd? > > are you sure that it isn't being started up by whatever starts up the > first? > > The second process has a bigger PID than the first and I'm using the default /usr/local/etc/rc.d/mpd5 as startup script with mpd_enable="YES" on /etc/rc.conf. -- Einstein Oliveira einstein@yawl.com.br ___________________________________________________ Yawl Internet Ltda. http://www.yawl.com.br/ From einstein at yawl.com.br Mon May 19 18:27:58 2008 From: einstein at yawl.com.br (Einstein Oliveira) Date: Mon May 19 18:28:02 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831BF2D.3040802@elischer.org> References: <4831B670.7060502@yawl.com.br> <4831BF2D.3040802@elischer.org> Message-ID: <4831C6CD.3070701@yawl.com.br> Julian Elischer wrote: > Einstein Oliveira wrote: >> Hi all, >> >> In an attempt to change from pppoed + ppp to mpd I'm having some >> strange behaviour with the later on the same host that usually handles >> 100+ clients with the former. >> >> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. >> Users can connect without any problem. >> >> After a few minutes a SECOND mpd process is initiated and this one >> consumes all idle processing of the host. >> >> Whoever is connected before that still remains connected but no new >> user can get in anymore. Also logging stops being generated. >> >> The only solution is a killall -KILL on mpd. >> >> On another host I have the same configuration working as expected but >> with less than 50 clients. >> >> Both configurations are the same from mpd.conf.sample. >> >> So I'm looking for any suggestions that somebody has been using to >> handle that many pppoe connections (100+) with mpd. >> >> >> >> Thanks, >> > > > people have handled many more than 100 I think.. > however there is no reason that a 2nd should start up. > what is teh PPID of the 2nd? Right now I can't try to run mpd to verify this information but as soon as I can I'll send this to the list. > > are you sure that it isn't being started up by whatever starts up the > first? > > -- Einstein Oliveira einstein@yawl.com.br ___________________________________________________ Yawl Internet Ltda. http://www.yawl.com.br/ From rahman.sazzadur at gmail.com Mon May 19 18:36:22 2008 From: rahman.sazzadur at gmail.com (sazzadur rahman) Date: Mon May 19 18:36:28 2008 Subject: A query regarding interop between BSD SCTP and lksctp Message-ID: <82bdb5ec0805191111h17fa4391uf2021104adbf606f@mail.gmail.com> Hello, We are using SCTP client on Linux (Fedora 5) and SCTP server on FreeBSD 7.0. Client-Server communication works fine. However, when we send ASCONF (ADD_IP) from Client to the server, it seems that FreeBSD does not respond with ASCONF_ACK to the Client. Is there any interop issue between BSD SCTP and lksctp? Please let us know if you have any questions. Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer Science, University of Oklahoma, Norman, Oklahoma, USA From julian at elischer.org Mon May 19 18:58:59 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 19 18:59:05 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831C56C.8090708@yawl.com.br> References: <4831B670.7060502@yawl.com.br> <4831BF2D.3040802@elischer.org> <4831C56C.8090708@yawl.com.br> Message-ID: <4831CDEE.8060106@elischer.org> Einstein Oliveira wrote: > Julian Elischer wrote: >> Einstein Oliveira wrote: >>> Hi all, >>> >>> In an attempt to change from pppoed + ppp to mpd I'm having some >>> strange behaviour with the later on the same host that usually >>> handles 100+ clients with the former. >>> >>> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. >>> Users can connect without any problem. >>> >>> After a few minutes a SECOND mpd process is initiated and this one >>> consumes all idle processing of the host. >>> >>> Whoever is connected before that still remains connected but no new >>> user can get in anymore. Also logging stops being generated. >>> >>> The only solution is a killall -KILL on mpd. >>> >>> On another host I have the same configuration working as expected but >>> with less than 50 clients. >>> >>> Both configurations are the same from mpd.conf.sample. >>> >>> So I'm looking for any suggestions that somebody has been using to >>> handle that many pppoe connections (100+) with mpd. >>> >>> >>> >>> Thanks, >>> >> >> >> people have handled many more than 100 I think.. >> however there is no reason that a 2nd should start up. >> what is teh PPID of the 2nd? >> >> are you sure that it isn't being started up by whatever starts up the >> first? >> >> > > The second process has a bigger PID than the first and I'm using the > default /usr/local/etc/rc.d/mpd5 as startup script with mpd_enable="YES" > on /etc/rc.conf. what about the PPID? (Parent PID) ps alx shows this. > From peter.lei at ieee.org Mon May 19 19:00:53 2008 From: peter.lei at ieee.org (Peter Lei) Date: Mon May 19 19:00:57 2008 Subject: A query regarding interop between BSD SCTP and lksctp In-Reply-To: <82bdb5ec0805191111h17fa4391uf2021104adbf606f@mail.gmail.com> References: <82bdb5ec0805191111h17fa4391uf2021104adbf606f@mail.gmail.com> Message-ID: <4831CA98.7050807@ieee.org> Can you verify that the version of the stack in Fedora 5 implements the SCTP AUTH chunk? The FreeBSD stack will silently discard the ADD-IP chunk if it's not wrapped with an AUTH chunk as per the RFC. --peter sazzadur rahman wrote: > Hello, > We are using SCTP client on Linux (Fedora 5) and SCTP server on FreeBSD 7.0. > Client-Server communication works fine. However, when we send ASCONF > (ADD_IP) from Client to the server, it seems that FreeBSD does not respond > with ASCONF_ACK to the Client. Is there any interop issue between BSD SCTP > and lksctp? > > Please let us know if you have any questions. > > > Best Regards, > Md Sazzadur Rahman > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, Oklahoma, USA > _______________________________________________ > 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 einstein at yawl.com.br Mon May 19 22:08:45 2008 From: einstein at yawl.com.br (Einstein Oliveira) Date: Mon May 19 22:08:50 2008 Subject: Suggestions on a PPPoE server with mpd Message-ID: <4831FA6A.1080906@yawl.com.br> > Einstein Oliveira wrote: >> Julian Elischer wrote: >>> Einstein Oliveira wrote: >>>> Hi all, >>>> >>>> In an attempt to change from pppoed + ppp to mpd I'm having some >>>> strange behaviour with the later on the same host that usually >>>> handles 100+ clients with the former. >>>> >>>> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. >>>> Users can connect without any problem. >>>> >>>> After a few minutes a SECOND mpd process is initiated and this one >>>> consumes all idle processing of the host. >>>> >>>> Whoever is connected before that still remains connected but no new >>>> user can get in anymore. Also logging stops being generated. >>>> >>>> The only solution is a killall -KILL on mpd. >>>> >>>> On another host I have the same configuration working as expected but >>>> with less than 50 clients. >>>> >>>> Both configurations are the same from mpd.conf.sample. >>>> >>>> So I'm looking for any suggestions that somebody has been using to >>>> handle that many pppoe connections (100+) with mpd. >>>> >>>> >>>> >>>> Thanks, >>>> >>> >>> >>> people have handled many more than 100 I think.. >>> however there is no reason that a 2nd should start up. >>> what is teh PPID of the 2nd? >>> >>> are you sure that it isn't being started up by whatever starts up the >>> first? >>> >>> >> >> The second process has a bigger PID than the first and I'm using the >> default /usr/local/etc/rc.d/mpd5 as startup script with mpd_enable="YES" >> on /etc/rc.conf. > > what about the PPID? (Parent PID) ps alx shows this. > >> here is the output of ps -alx: 0 12573 1 0 20 0 5424 3468 kserel Ss ?? 0:00.15 /usr/local/sbin/mpd5 -p /va 0 12629 12573 283 131 0 5424 3452 - R ?? 0:36.94 /usr/local/sbin/mpd5 -p /va 0 12707 11713 0 96 0 1528 868 - R+ p0 0:00.00 grep mpd5 -- Einstein Oliveira einstein@yawl.com.br ___________________________________________________ Yawl Internet Ltda. http://www.yawl.com.br/ From julian at elischer.org Mon May 19 22:25:14 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 19 22:25:19 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831FA6A.1080906@yawl.com.br> References: <4831FA6A.1080906@yawl.com.br> Message-ID: <4831FE4A.8010002@elischer.org> Einstein Oliveira wrote: >> Einstein Oliveira wrote: >>> Julian Elischer wrote: >>>> Einstein Oliveira wrote: >>>>> Hi all, >>>>> >>>>> In an attempt to change from pppoed + ppp to mpd I'm having some >>>>> strange behaviour with the later on the same host that usually >>>>> handles 100+ clients with the former. >>>>> >>>>> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB Ram. >>>>> Users can connect without any problem. >>>>> >>>>> After a few minutes a SECOND mpd process is initiated and this one >>>>> consumes all idle processing of the host. >>>>> >>>>> Whoever is connected before that still remains connected but no new >>>>> user can get in anymore. Also logging stops being generated. >>>>> >>>>> The only solution is a killall -KILL on mpd. >>>>> >>>>> On another host I have the same configuration working as expected >>>>> but with less than 50 clients. >>>>> >>>>> Both configurations are the same from mpd.conf.sample. >>>>> >>>>> So I'm looking for any suggestions that somebody has been using to >>>>> handle that many pppoe connections (100+) with mpd. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>> >>>> >>>> people have handled many more than 100 I think.. >>>> however there is no reason that a 2nd should start up. >>>> what is teh PPID of the 2nd? >>>> >>>> are you sure that it isn't being started up by whatever starts up >>>> the first? >>>> >>>> >>> >>> The second process has a bigger PID than the first and I'm using the >>> default /usr/local/etc/rc.d/mpd5 as startup script with >>> mpd_enable="YES" on /etc/rc.conf. >> >> what about the PPID? (Parent PID) ps alx shows this. >> >>> > > here is the output of ps -alx: > > 0 12573 1 0 20 0 5424 3468 kserel Ss ?? 0:00.15 > /usr/local/sbin/mpd5 -p /va > 0 12629 12573 283 131 0 5424 3452 - R ?? 0:36.94 > /usr/local/sbin/mpd5 -p /va > 0 12707 11713 0 96 0 1528 868 - R+ p0 0:00.00 > grep mpd5 > > sorry I repeated myself.. hmmm kserel... it's threaded? I didn't know that.. does top -H show a bunch of threads? So the first copy of mpd has spawned another while threaded. have you applied the patch for 6.3 in the 6.3 errata notifications? http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc From einstein at yawl.com.br Mon May 19 22:38:53 2008 From: einstein at yawl.com.br (Einstein Oliveira) Date: Mon May 19 22:38:58 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4831FE4A.8010002@elischer.org> References: <4831FA6A.1080906@yawl.com.br> <4831FE4A.8010002@elischer.org> Message-ID: <4832017B.30003@yawl.com.br> Julian Elischer wrote: > Einstein Oliveira wrote: >>> Einstein Oliveira wrote: >>>> Julian Elischer wrote: >>>>> Einstein Oliveira wrote: >>>>>> Hi all, >>>>>> >>>>>> In an attempt to change from pppoed + ppp to mpd I'm having some >>>>>> strange behaviour with the later on the same host that usually >>>>>> handles 100+ clients with the former. >>>>>> >>>>>> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB >>>>>> Ram. Users can connect without any problem. >>>>>> >>>>>> After a few minutes a SECOND mpd process is initiated and this one >>>>>> consumes all idle processing of the host. >>>>>> >>>>>> Whoever is connected before that still remains connected but no >>>>>> new user can get in anymore. Also logging stops being generated. >>>>>> >>>>>> The only solution is a killall -KILL on mpd. >>>>>> >>>>>> On another host I have the same configuration working as expected >>>>>> but with less than 50 clients. >>>>>> >>>>>> Both configurations are the same from mpd.conf.sample. >>>>>> >>>>>> So I'm looking for any suggestions that somebody has been using to >>>>>> handle that many pppoe connections (100+) with mpd. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>> >>>>> >>>>> people have handled many more than 100 I think.. >>>>> however there is no reason that a 2nd should start up. >>>>> what is teh PPID of the 2nd? >>>>> >>>>> are you sure that it isn't being started up by whatever starts up >>>>> the first? >>>>> >>>>> >>>> >>>> The second process has a bigger PID than the first and I'm using the >>>> default /usr/local/etc/rc.d/mpd5 as startup script with >>>> mpd_enable="YES" on /etc/rc.conf. >>> >>> what about the PPID? (Parent PID) ps alx shows this. >>> >>>> >> >> here is the output of ps -alx: >> >> 0 12573 1 0 20 0 5424 3468 kserel Ss ?? 0:00.15 >> /usr/local/sbin/mpd5 -p /va >> 0 12629 12573 283 131 0 5424 3452 - R ?? 0:36.94 >> /usr/local/sbin/mpd5 -p /va >> 0 12707 11713 0 96 0 1528 868 - R+ p0 0:00.00 >> grep mpd5 >> >> > sorry I repeated myself.. > hmmm kserel... it's threaded? I didn't know that.. > does top -H show a bunch of threads? 12720 root 96 0 8252K 5656K select 0:26 0.00% mpd5 12720 root 20 0 8252K 5656K kserel 0:26 0.00% mpd5 12720 root 20 0 8252K 5656K ksesig 0:26 0.00% mpd5 > > So the first copy of mpd has spawned another while threaded. > have you applied the patch for 6.3 in the 6.3 errata notifications? > > http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc > > Not yet. This host is using the RELENG_6_3 tag but I can do that if you think it can help. -- Einstein Oliveira einstein@yawl.com.br ___________________________________________________ Yawl Internet Ltda. http://www.yawl.com.br/ From julian at elischer.org Mon May 19 22:41:35 2008 From: julian at elischer.org (Julian Elischer) Date: Mon May 19 22:41:39 2008 Subject: Suggestions on a PPPoE server with mpd In-Reply-To: <4832017B.30003@yawl.com.br> References: <4831FA6A.1080906@yawl.com.br> <4831FE4A.8010002@elischer.org> <4832017B.30003@yawl.com.br> Message-ID: <4832021F.7070007@elischer.org> Einstein Oliveira wrote: > Julian Elischer wrote: >> Einstein Oliveira wrote: >>>> Einstein Oliveira wrote: >>>>> Julian Elischer wrote: >>>>>> Einstein Oliveira wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> In an attempt to change from pppoed + ppp to mpd I'm having some >>>>>>> strange behaviour with the later on the same host that usually >>>>>>> handles 100+ clients with the former. >>>>>>> >>>>>>> Basically it's a i386 FreeBSD 6.3 system with mpd-5.1 and 1 GB >>>>>>> Ram. Users can connect without any problem. >>>>>>> >>>>>>> After a few minutes a SECOND mpd process is initiated and this >>>>>>> one consumes all idle processing of the host. >>>>>>> >>>>>>> Whoever is connected before that still remains connected but no >>>>>>> new user can get in anymore. Also logging stops being generated. >>>>>>> >>>>>>> The only solution is a killall -KILL on mpd. >>>>>>> >>>>>>> On another host I have the same configuration working as expected >>>>>>> but with less than 50 clients. >>>>>>> >>>>>>> Both configurations are the same from mpd.conf.sample. >>>>>>> >>>>>>> So I'm looking for any suggestions that somebody has been using >>>>>>> to handle that many pppoe connections (100+) with mpd. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>> >>>>>> >>>>>> people have handled many more than 100 I think.. >>>>>> however there is no reason that a 2nd should start up. >>>>>> what is teh PPID of the 2nd? >>>>>> >>>>>> are you sure that it isn't being started up by whatever starts up >>>>>> the first? >>>>>> >>>>>> >>>>> >>>>> The second process has a bigger PID than the first and I'm using >>>>> the default /usr/local/etc/rc.d/mpd5 as startup script with >>>>> mpd_enable="YES" on /etc/rc.conf. >>>> >>>> what about the PPID? (Parent PID) ps alx shows this. >>>> >>>>> >>> >>> here is the output of ps -alx: >>> >>> 0 12573 1 0 20 0 5424 3468 kserel Ss ?? 0:00.15 >>> /usr/local/sbin/mpd5 -p /va >>> 0 12629 12573 283 131 0 5424 3452 - R ?? 0:36.94 >>> /usr/local/sbin/mpd5 -p /va >>> 0 12707 11713 0 96 0 1528 868 - R+ p0 0:00.00 >>> grep mpd5 >>> >>> >> sorry I repeated myself.. >> hmmm kserel... it's threaded? I didn't know that.. >> does top -H show a bunch of threads? > > 12720 root 96 0 8252K 5656K select 0:26 0.00% mpd5 > 12720 root 20 0 8252K 5656K kserel 0:26 0.00% mpd5 > 12720 root 20 0 8252K 5656K ksesig 0:26 0.00% mpd5 > >> >> So the first copy of mpd has spawned another while threaded. >> have you applied the patch for 6.3 in the 6.3 errata notifications? >> >> http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc >> >> > > Not yet. This host is using the RELENG_6_3 tag but I can do that if you > think it can help. check to see if the patch is applied. If not it should be because it will screw any process that is threaded and does forks. If that does not help we can look further, but first make sure this is done. > From csjp at FreeBSD.org Mon May 19 23:40:33 2008 From: csjp at FreeBSD.org (Christian S.J. Peron) Date: Mon May 19 23:40:36 2008 Subject: How to inject fullsize 802.1q-tagged frame through BPF? In-Reply-To: <20080519130722.GA40822@roof1.dnepro.net> References: <20080515152607.GA36663@roof1.dnepro.net> <482C6303.9000904@freebsd.org> <20080519130722.GA40822@roof1.dnepro.net> Message-ID: <20080519232451.GA52560@sub.vaned.net> Eugene, Thanks for the report. I will look into this. Although this patch technically works, I think the right solution to this problem is to introduce a new DLT_ for VLAN encapsulated frames. I will look into this problem in a bit more detail. On Mon, May 19, 2008 at 04:07:22PM +0300, Eugene Perevyazko wrote: > On Thu, May 15, 2008 at 12:21:23PM -0400, Sam Leffler wrote: > > Eugene Perevyazko wrote: > > > Is there a way to inject full-mtu vlan-tagged frame through BPF on parent > > >device? > > > I'd like not to open several tenths of BPFs for each vlanN if it's > > > possible. > > > > bpf write code in the kernel calculates header size when packets are > > injected. This is likely based on the frames being stock 802.3 so would > > require mods to the bpf code to handle the additional space for the tag. > > I've made a simple patch that works for me on FreeBSD 6.2-RELEASE #1. > Not sure if this is the way to do it, but it "just works". May be someone > else will need such feature too. > > Eugene Perevyazko > > > --- bpf.c.old Mon May 19 10:47:55 2008 > +++ bpf.c Mon May 19 10:57:44 2008 > @@ -64,6 +64,7 @@ > #include > > #include > +#include > #include > #include > > @@ -617,7 +618,9 @@ > return (0); > > bzero(&dst, sizeof(dst)); > - error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, ifp->if_mtu, > + /* Use VLAN_MTU capability, if supported */ > + error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, > + ifp->if_mtu + ( (ifp->if_capenable & IFCAP_VLAN_MTU) ? ETHER_VLAN_ENCAP_LEN : 0 ), > &m, &dst, d->bd_wfilter); > if (error) > return (error); > _______________________________________________ > 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 yes298 at gmail.com Tue May 20 04:00:04 2008 From: yes298 at gmail.com (yes298 yes298) Date: Tue May 20 04:00:07 2008 Subject: amd64/123603: tcp_do_segment and Received duplicate SYN Message-ID: <200805200400.m4K403Nn001163@freefall.freebsd.org> The following reply was made to PR kern/123603; it has been noted by GNATS. From: "yes298 yes298" To: "John Baldwin" Cc: freebsd-gnats-submit@freebsd.org, andre@freebsd.org Subject: Re: amd64/123603: tcp_do_segment and Received duplicate SYN Date: Tue, 20 May 2008 11:24:32 +0800 ------=_Part_19869_29339230.1211253872117 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir, Thank you so much for your reply. My FreeBSD 7.0(x64) Lighttpd web server connects to a 100M broadband line, after testing many times, I found that, when first time to view my website, it needed to take almost 5~8 seconds to completely open the homepage which is only a static HTML file with content "coming soon", and there are some error log about TCP connection found on our web server, it seems that my FreeBSD 7.0 web server has problem to establish TCP connection. Before the web server idle time (30s), there are no any delay to re-view the homepage (Press F5), but after 30 seconds, it needed to take another 5~8 seconds to re-view, and the log messages will be repeated. May 15 15:18:21 mail kernel: TCP: [203.186.95.8]:12728 to [58.177.222.113]:80 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK May 15 15:19:03 mail kernel: TCP: [221.127.88.188]:5128 to [58.177.222.113]:80 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK I know how to disable these log messages, but I would like to know that the delay is because of receiving duplicate SYN? is it normal message? Please help me to solve the problem, thanks !!!! Thank you so much! Best regards, Victor 2008/5/19 John Baldwin : > On Monday 12 May 2008 03:45:16 am John wrote: > > >Number: 123603 > > >Category: amd64 > > >Synopsis: tcp_do_segment and Received duplicate SYN > > >Confidential: no > > >Severity: critical > > >Priority: high > > >Responsible: freebsd-amd64 > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Mon May 12 07:50:01 UTC 2008 > > >Closed-Date: > > >Last-Modified: > > >Originator: John > > >Release: FB7.0 (x64) > > >Organization: > > > > NULL > > > > >Environment: > > > > FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar 6 > > 12:04:57 HKT 2008 root@mydomain.com: > /usr/src/sys/amd64/compile/FB7NEW > > amd64 > > > > >Description: > > > > A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and > patchs. > > when a client connect and view a static HTML file, At the first time > > (before web server idle time), it needs to wait a long time to establish > a > > connection, OR when this server try to download file from Internet, there > > are lots of logs messages just like below: > > > > May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44 > ]:80 > > tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer > > and retransmitting SYN|ACK > > May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to > > [11.22.33.44]:63372 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: > > Received 1448 bytes of data after socket was closed, sending RST and > > removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to > > [11.22.33.44]:55007 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: > > Received 13 bytes of data after socket was closed, sending RST and > removing > > tcpcb > > > > >How-To-Repeat: > > > > any type of connection will generate above log messages. > > You can either comment out all the log(LOG_DEBUG, ...) calls > in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send > kern.debug > messages to the console. > > I think these messages should probably be conditional on a kernel option > FWIW. > > -- > John Baldwin > ------=_Part_19869_29339230.1211253872117 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Sir,
 
Thank you so much for your reply.
 
My FreeBSD 7.0(x64) Lighttpd web server connects to a 100M broadband line, after testing many times, I found that, when first time to view my website, it needed to take almost 5~8 seconds to completely open the homepage which is only a static HTML file with content "coming soon", and there are some  error log about TCP connection found on our web server, it seems that my FreeBSD 7.0 web server has problem to establish TCP connection. Before the we b server idle time (30s), there are no any delay to re-view the homepage (Press F5), but after 30 seconds, it needed to take another 5~8 seconds to re-view, and the log messages will be repeated.
 
May 15 15:18:21 mail kernel: TCP: [203.186.95.8]:12728 to [58.177.222.113]:80 tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK
May 15 15:19:03 mail kernel: TCP: [221.127.88.188]:5128 to [58.177.222.113]:80 tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK
 
I know how to disable these log messages, but I would like to know that the delay is because
of receiving duplicate SYN? is it normal message? Please help me to solve the problem, thanks !!!!
Thank you so much!
 
Best regards,
Victor
 
2008/5/19 John Baldwin <jhb@freebsd.org>:
On Monday 12 May 2008 03:45:16 am John wrote:
> >Number:         123603
> >Category:       amd64
> >Synopsis:       tcp_do_segment and Received duplicate SYN
> >Confidential:   no
> >Severity:       critical
> >Priority:       high
> >Responsible:    freebsd-amd64
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Mon May 12 07:50:01 UTC 2008
> >Closed-Date:
> >Last-Modified:
> >Originator:     John
> >Release:        FB7.0 (x64)
> >Organization:
>
> NULL
>
> >Environment:
>
> FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar  6
> 12:04:57 HKT 2008     root@mydomain.com:/usr/src/sys/amd64/compile/FB7NEW
> amd64
>
> >Description:
>
> A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and patchs.
> when a client connect and view a static HTML file, At the first time
> (before web server idle time), it needs to wait a long time to establish a
> connection, OR when this server try to download file from Internet, there
> are lots of logs messages just like below:
>
> May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44]:80
> tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer
> and retransmitting SYN|ACK
> May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to
> [11.22.33.44]:63372 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_1:
> Received 1448 bytes of data after socket was closed, sending RST and
> removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to
> [11.22.33.44]:55007 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2:
> Received 13 bytes of data after socket was closed, sending RST and removing
> tcpcb
>
> >How-To-Repeat:
>
> any type of  connection will generate above log messages.

You can either comment out all the log(LOG_DEBUG, ...) calls
in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send kern.debug
messages to the console.

I think these messages should probably be conditional on a kernel option FWIW.

--
John Baldwin

------=_Part_19869_29339230.1211253872117-- From john at dnepro.net Tue May 20 07:29:09 2008 From: john at dnepro.net (Eugene Perevyazko) Date: Tue May 20 07:29:15 2008 Subject: How to inject fullsize 802.1q-tagged frame through BPF? In-Reply-To: <20080519232451.GA52560@sub.vaned.net> References: <20080515152607.GA36663@roof1.dnepro.net> <482C6303.9000904@freebsd.org> <20080519130722.GA40822@roof1.dnepro.net> <20080519232451.GA52560@sub.vaned.net> Message-ID: <20080520072905.GA28615@roof1.dnepro.net> On Mon, May 19, 2008 at 06:24:51PM -0500, Christian S.J. Peron wrote: > Eugene, > > Thanks for the report. I will look into this. Although this patch technically > works, I think the right solution to this problem is to introduce a new DLT_ > for VLAN encapsulated frames. I will look into this problem in a bit more > detail. Thanks for your attention, Christian, but please consider that it's possible to mix tagged and untagged frames on interface and such DLT_ will put an artificial limit on this while technically there's no such limitation. Eugene Perevyazko From andre at freebsd.org Tue May 20 15:10:05 2008 From: andre at freebsd.org (Andre Oppermann) Date: Tue May 20 15:10:15 2008 Subject: amd64/123603: tcp_do_segment and Received duplicate SYN Message-ID: <200805201510.m4KFA5TK086435@freefall.freebsd.org> The following reply was made to PR kern/123603; it has been noted by GNATS. From: Andre Oppermann To: yes298 yes298 Cc: John Baldwin , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/123603: tcp_do_segment and Received duplicate SYN Date: Tue, 20 May 2008 16:40:08 +0200 Victor, Please try two things: 1. Make sure that you don't have a problem with MTU sizes. Some ADSL customers with PPPoE have slightly smaller MTU sizes than normal ethernet. Make sure that ICMP unreach packets are not firewalled or filtered on your side. 2. There was a bug in the TCP options in FreeBSD 7.0-RELEASE that was giving problems with a smaller number of CPE devices for ADSL and Cablemodem customers. The problem is fixed in 7-STABLE. Only upgrading the kernel is sufficient. I hope this helps. If not, please provide some tcpdumps so we can see the packets that are exchanged. -- Andre yes298 yes298 wrote: > Dear Sir, > > Thank you so much for your reply. > > My FreeBSD 7.0(x64) Lighttpd web server connects to a 100M broadband line, > after testing many times, I found that, when first time to view my website, > it needed to take almost 5~8 seconds to completely open the homepage which > is only a static HTML file with content "coming soon", and there are some > error log about TCP connection found on our web server, it seems that my > FreeBSD 7.0 web server has problem to establish TCP connection. Before the > web server idle time (30s), there are no any delay to re-view the homepage > (Press F5), but after 30 seconds, it needed to take another 5~8 seconds to > re-view, and the log messages will be repeated. > > May 15 15:18:21 mail kernel: TCP: [203.186.95.8]:12728 to [58.177.222.113]:80 > tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and > retransmitting SYN|ACK > May 15 15:19:03 mail kernel: TCP: [221.127.88.188]:5128 to [58.177.222.113]:80 > tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and > retransmitting SYN|ACK > > I know how to disable these log messages, but I would like to know that the > delay is because > of receiving duplicate SYN? is it normal message? Please help me to solve > the problem, thanks !!!! > Thank you so much! > > Best regards, > Victor > > 2008/5/19 John Baldwin : > >> On Monday 12 May 2008 03:45:16 am John wrote: >>>> Number: 123603 >>>> Category: amd64 >>>> Synopsis: tcp_do_segment and Received duplicate SYN >>>> Confidential: no >>>> Severity: critical >>>> Priority: high >>>> Responsible: freebsd-amd64 >>>> State: open >>>> Quarter: >>>> Keywords: >>>> Date-Required: >>>> Class: sw-bug >>>> Submitter-Id: current-users >>>> Arrival-Date: Mon May 12 07:50:01 UTC 2008 >>>> Closed-Date: >>>> Last-Modified: >>>> Originator: John >>>> Release: FB7.0 (x64) >>>> Organization: >>> NULL >>> >>>> Environment: >>> FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar 6 >>> 12:04:57 HKT 2008 root@mydomain.com: >> /usr/src/sys/amd64/compile/FB7NEW >>> amd64 >>> >>>> Description: >>> A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and >> patchs. >>> when a client connect and view a static HTML file, At the first time >>> (before web server idle time), it needs to wait a long time to establish >> a >>> connection, OR when this server try to download file from Internet, there >>> are lots of logs messages just like below: >>> >>> May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44 >> ]:80 >>> tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer >>> and retransmitting SYN|ACK >>> May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to >>> [11.22.33.44]:63372 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: >>> Received 1448 bytes of data after socket was closed, sending RST and >>> removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to >>> [11.22.33.44]:55007 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: >>> Received 13 bytes of data after socket was closed, sending RST and >> removing >>> tcpcb >>> >>>> How-To-Repeat: >>> any type of connection will generate above log messages. >> You can either comment out all the log(LOG_DEBUG, ...) calls >> in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send >> kern.debug >> messages to the console. >> >> I think these messages should probably be conditional on a kernel option >> FWIW. >> >> -- >> John Baldwin >> > From rpaulo at FreeBSD.org Wed May 21 10:36:57 2008 From: rpaulo at FreeBSD.org (rpaulo@FreeBSD.org) Date: Wed May 21 10:37:00 2008 Subject: kern/123123: [re][patch] Realtek RTL8111C detection and failure Message-ID: <200805211036.m4LAavaM019917@freefall.freebsd.org> Synopsis: [re][patch] Realtek RTL8111C detection and failure Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Wed May 21 10:36:18 UTC 2008 Responsible-Changed-Why: I'm working on a patch since NetBSD seems to support this card. http://www.freebsd.org/cgi/query-pr.cgi?pr=123123 From nike_d at cytexbg.com Wed May 21 17:31:46 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed May 21 17:31:51 2008 Subject: lagg0.2 style vlans on lagg(4) interface Message-ID: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> If one tries to use lagg0.2 style vlans on lagg0 interface configured from rc.conf it does't work. The problem is that all of the cloned interfaces (lagg0 , lagg0.2, etc) are created before any other interface configuration is done, and in this case lagg0 is created, then lagg0.2 is created. But because lagg0 does not have any members yet, it's MAC address is all zeroes, and this is inherited by the vlan interfaces. At the next step the members are added to the lagg0 interface and it's mac address gets set, but the vlan interfaces never see this change and remain with mac address 00:00:00:00:00:00 and in unusable state. Does it sound reasonable for the vlan(4) interfaces to update their mac address when their parent changes it. (this should probably look more like the parent telling the vlans attached to it that it's mac has changed, but i'm not sure if the parent knows about children interfaces) From max at love2party.net Wed May 21 17:45:02 2008 From: max at love2party.net (Max Laier) Date: Wed May 21 17:45:07 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> Message-ID: <200805211944.42418.max@love2party.net> On Wednesday 21 May 2008 19:31:46 Niki Denev wrote: > If one tries to use lagg0.2 style vlans on lagg0 interface configured > from rc.conf it does't work. > The problem is that all of the cloned interfaces (lagg0 , lagg0.2, etc) > are created before any other interface configuration is done, > and in this case lagg0 is created, then lagg0.2 is created. > But because lagg0 does not have any members yet, it's MAC address > is all zeroes, and this is inherited by the vlan interfaces. > At the next step the members are added to the lagg0 interface and it's > mac address gets set, > but the vlan interfaces never see this change and remain with mac > address 00:00:00:00:00:00 and in unusable state. > > Does it sound reasonable for the vlan(4) interfaces to update their > mac address when their parent changes it. > (this should probably look more like the parent telling the vlans > attached to it that it's mac has changed, but > i'm not sure if the parent knows about children interfaces) It doesn't (and shouldn't have to). I'd simply add an EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do that for INET[6] address already. Then vlan (and any other device interested in LLaddress changes) can simply register to that eventhandler and resync. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From neil at hoggarth.me.uk Wed May 21 19:11:22 2008 From: neil at hoggarth.me.uk (Neil Hoggarth) Date: Wed May 21 19:11:25 2008 Subject: [em][panic] recursed on non-recursive mutex em0 Message-ID: Hi Folks, I opened PR kern/122928 last month, describing my problems with Intel PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driver: every so often the machine would get into a state where it would repeatedly watchdog timeout the em0 interface, and the interface would stop receiving packets. A few weeks ago I cvsupped a newer version of the 7-STABLE source tree, after v6.9.0 of the em driver was MFCed. Since I started running on the newer build watchdog timeouts appear to be followed by a system panic rather than the freezing up of the interface. I have no hard evidence but it "feels like" the panics are happening under the same sort of circumstance that was previously triggering my watchdog problem (basically network activity combined with CPU load). A similar observation was made by Yani Karydis on the freebsd-stable mailing list earlier in the month: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042311.html I've now got a serial console set up, and I'm running a kernel with DDB support compiled in. I managed to get the information below out of the most recent panic. Is anyone able to use this to debug the situation? What else might I try to gather useful information? em0: watchdog timeout -- resetting panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/em/if_em.c:1348 cpuid = 0 KDB: enter: panic [thread pid 14 tid 100005 ] Stopped at kdb_enter_why+0x3d: movq $0,0x5efc08(%rip) db> bt Tracing pid 14 tid 100005 td 0xffffff00012406a0 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x176 _mtx_lock_sleep() at _mtx_lock_sleep+0x181 _mtx_lock_flags() at _mtx_lock_flags+0xe1 em_init_locked() at em_init_locked+0x61 em_local_timer() at em_local_timer+0x195 softclock() at softclock+0x299 ithread_loop() at ithread_loop+0xda fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffd5599d30, rbp = 0 --- db> show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xffffff00036754a8) locked @ /usr/src/sys/dev/em/if_em.c:1302 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xffffff0003675478) locked @ /usr/src/sys/kern/kern_timeout.c:241 db> ps pid ppid pgrp uid state wmesg wchan cmd 50494 50493 41749 0 R+ make 50493 41749 41749 0 S+ wait 0xffffff01196a6468 sh 45511 45510 45511 1284 Ss sbwait 0xffffff00150257c4 sftp-server 45510 45135 45135 1284 S select 0xffffffff80b2f930 sshd 45135 932 45135 0 Ss sbwait 0xffffff001502c984 sshd 41749 1070 41749 0 S+ piperd 0xffffff0015ac45d0 initial thread 34233 34223 34073 0 S+ nanslp 0xffffffff80a9da68 initial thread 34223 34221 34073 0 S+ wait 0xffffff0009b62468 make 34221 34073 34073 0 S+ wait 0xffffff0015aa0468 sh 34073 33858 34073 0 S+ wait 0xffffff0125b6f8d0 make 33858 33834 33858 1284 Ss+ wait 0xffffff0009d528d0 bash 33834 33833 33833 1284 S select 0xffffffff80b2f930 xterm 33833 1066 33833 1284 Ss wait 0xffffff0125b6c468 sh 7250 1110 1110 1284 R+ initial thread 5215 1 1007 1284 S+ select 0xffffffff80b2f930 initial thread 5213 5209 1007 1284 S+ (threaded) firefox-bin 100203 S ucond 0xffffff009a318b00 firefox-bin 100202 S ucond 0xffffff00a0a25400 firefox-bin 100201 S ucond 0xffffff00a1dd4c00 firefox-bin 100200 S ucond 0xffffff00a4297580 firefox-bin 100195 S ucond 0xffffff0003e86900 firefox-bin 100194 S select 0xffffffff80b2f930 firefox-bin 100190 S select 0xffffffff80b2f930 initial thread 5209 5205 1007 1284 S+ wait 0xffffff0015aa58d0 sh 5205 5204 1007 1284 S+ wait 0xffffff0015aa1000 sh 5204 1034 1007 1284 S+ wait 0xffffff0015aa2468 sh 4977 4976 4976 1284 S+ (threaded) alpine 100147 S select 0xffffffff80b2f930 initial thread 4976 4973 4976 1284 S+ wait 0xffffff0015c6c000 sh 4973 4971 4973 1284 Ss+ wait 0xffffff0015c6b000 bash 4971 1034 1007 1284 S+ select 0xffffffff80b2f930 xterm 3249 919 919 80 S accept 0xffffff000929c5ce httpd 1110 1107 1110 1284 S+ wait 0xffffff0009b65000 sh 1107 1042 1107 1284 Ss+ wait 0xffffff000379e000 bash 1070 1068 1070 1284 Ss+ wait 0xffffff0009d51000 bash 1068 1067 1067 1284 S select 0xffffffff80b2f930 xterm 1067 1066 1067 1284 Ss wait 0xffffff0009d51468 sh 1066 1059 1059 1284 S+ select 0xffffffff80b2f930 ratpoison 1059 1052 1059 1284 S+ wait 0xffffff00037b28d0 sh 1054 0 0 0 RL CPU 1 [irq16: drm0] 1053 1052 1053 1284 S+ select 0xffffffff80b2f930 initial thread 1052 1051 1051 1284 S+ wait 0xffffff0009d54000 xinit 1051 1050 1051 1284 S+ wait 0xffffff0009d54468 sh 1050 1042 1050 1284 Ss+ wait 0xffffff0009b66000 bash 1048 1045 1048 1284 S+ kqread 0xffffff0003e60e00 rtorrent 1045 1042 1045 1284 Ss+ wait 0xffffff0003a45468 bash 1042 1041 1042 1284 Ss select 0xffffffff80b2f930 screen 1041 1006 1041 1284 S+ pause 0xffffff0009b620c0 screen 1034 1020 1007 1284 S+ select 0xffffffff80b2f930 initial thread 1033 1020 1033 1284 S+ select 0xffffffff80b2f930 initial thread 1027 1020 1007 1284 S+ select 0xffffffff80b2f930 initial thread 1020 1 1007 1284 S+ select 0xffffffff80b2f930 initial thread 1016 1 1007 1284 S+ select 0xffffffff80b2f930 Xvnc 1006 986 1006 1284 S+ wait 0xffffff000379f8d0 bash 1001 872 872 0 S select 0xffffffff80b2f930 perl5.8.8 1000 872 872 0 S select 0xffffffff80b2f930 perl5.8.8 999 919 919 80 S accept 0xffffff000929c5ce httpd 998 919 919 80 S accept 0xffffff000929c5ce httpd 997 919 919 80 S accept 0xffffff000929c5ce httpd 996 919 919 80 S accept 0xffffff000929c5ce httpd 995 919 919 80 S accept 0xffffff000929c5ce httpd 994 1 994 0 Ss+ ttyin 0xffffff0003689010 getty 993 1 993 0 Ss+ ttyin 0xffffff00036ab410 getty 992 1 992 0 Ss+ ttyin 0xffffff00036ac410 getty 991 1 991 0 Ss+ ttyin 0xffffff00036ac010 getty 990 1 990 0 Ss+ ttyin 0xffffff00036aac10 getty 989 1 989 0 Ss+ ttyin 0xffffff00036aa810 getty 988 1 988 0 Ss+ ttyin 0xffffff000369c810 getty 987 1 987 0 Ss+ ttyin 0xffffff000369cc10 getty 986 1 986 0 Ss+ wait 0xffffff0003a42000 login 965 1 965 0 Ss select 0xffffffff80b2f930 inetd 937 1 937 0 Ss nanslp 0xffffffff80a9da68 cron 932 1 932 0 Ss select 0xffffffff80b2f930 sshd 919 1 919 0 Ss select 0xffffffff80b2f930 httpd 894 1 894 25 Ss pause 0xffffff00037b0990 sendmail 890 1 890 0 Ss select 0xffffffff80b2f930 sendmail 872 1 872 0 Ss select 0xffffffff80b2f930 perl5.8.8 861 856 847 1003 S sbwait 0xffffff00092c16cc tinydns 860 857 847 1002 S piperd 0xffffff0003c27ba0 multilog 859 854 847 1001 S select 0xffffffff80b2f930 dnscache 858 855 847 1002 S piperd 0xffffff0003c39000 multilog 857 849 847 0 S select 0xffffffff80b2f930 supervise 856 849 847 0 S select 0xffffffff80b2f930 supervise 855 849 847 0 S select 0xffffffff80b2f930 supervise 854 849 847 0 S select 0xffffffff80b2f930 supervise 850 1 847 0 S piperd 0xffffff0003c278b8 readproctitle 849 1 847 0 S nanslp 0xffffffff80a9da68 svscan 833 1 833 1285 Ss select 0xffffffff80b2f930 dhcpd 799 1 799 0 Ss select 0xffffffff80b2f930 ntpd 775 1 775 0 Ss select 0xffffffff80b2f930 lpd 707 1 707 0 Ss select 0xffffffff80b2f930 syslogd 677 0 0 0 SL mdwait 0xffffff0003caa000 [md0] 633 1 633 0 Ss select 0xffffffff80b2f930 devd 169 0 0 0 SL zfs:(&tq 0xffffff0001349bc0 [zil_clean] 168 0 0 0 SL zfs:(&tq 0xffffff0001349940 [zil_clean] 167 0 0 0 SL zfs:(&tq 0xffffff00013496c0 [zil_clean] 105 0 0 0 SL zfs:(&tq 0xffffff0001349440 [zil_clean] 104 0 0 0 SL zfs:(&tx 0xffffff00038451a0 [txg_thread_enter] 103 0 0 0 SL zfs:(&tx 0xffffff0003845160 [txg_thread_enter] 102 0 0 0 SL zfs:(&tx 0xffffff0003845180 [txg_thread_enter] 101 0 0 0 SL vgeom:io 0xffffff00037c5810 [vdev:worker ad10] 100 0 0 0 SL vgeom:io 0xffffff0003760390 [vdev:worker ad8] 99 0 0 0 SL zfs:(&tq 0xffffff0001348080 [spa_zio_intr_5] 98 0 0 0 SL zfs:(&tq 0xffffff0001348080 [spa_zio_intr_5] 97 0 0 0 SL zfs:(&tq 0xffffff00013481c0 [spa_zio_issue_5] 96 0 0 0 SL zfs:(&tq 0xffffff00013481c0 [spa_zio_issue_5] 95 0 0 0 SL zfs:(&tq 0xffffff0001348300 [spa_zio_intr_4] 94 0 0 0 SL zfs:(&tq 0xffffff0001348300 [spa_zio_intr_4] 93 0 0 0 SL zfs:(&tq 0xffffff0001348440 [spa_zio_issue_4] 92 0 0 0 SL zfs:(&tq 0xffffff0001348440 [spa_zio_issue_4] 91 0 0 0 SL zfs:(&tq 0xffffff0001348580 [spa_zio_intr_3] 90 0 0 0 SL zfs:(&tq 0xffffff0001348580 [spa_zio_intr_3] 89 0 0 0 SL zfs:(&tq 0xffffff00013486c0 [spa_zio_issue_3] 88 0 0 0 SL zfs:(&tq 0xffffff00013486c0 [spa_zio_issue_3] 87 0 0 0 SL zfs:(&tq 0xffffff0001348800 [spa_zio_intr_2] 86 0 0 0 SL zfs:(&tq 0xffffff0001348800 [spa_zio_intr_2] 85 0 0 0 SL zfs:(&tq 0xffffff0001348940 [spa_zio_issue_2] 84 0 0 0 SL zfs:(&tq 0xffffff0001348940 [spa_zio_issue_2] 83 0 0 0 SL zfs:(&tq 0xffffff0001348a80 [spa_zio_intr_1] 82 0 0 0 SL zfs:(&tq 0xffffff0001348a80 [spa_zio_intr_1] 81 0 0 0 SL zfs:(&tq 0xffffff0001348bc0 [spa_zio_issue_1] 80 0 0 0 SL zfs:(&tq 0xffffff0001348bc0 [spa_zio_issue_1] 79 0 0 0 SL zfs:(&tq 0xffffff0001348d00 [spa_zio_intr_0] 78 0 0 0 SL zfs:(&tq 0xffffff0001348d00 [spa_zio_intr_0] 77 0 0 0 SL zfs:(&tq 0xffffff0001348e40 [spa_zio_issue_0] 76 0 0 0 SL zfs:(&tq 0xffffff0001348e40 [spa_zio_issue_0] 49 0 0 0 SL sdflush 0xffffffff80b3fc38 [softdepflush] 48 0 0 0 SL vlruwt 0xffffff00036a3468 [vnlru] 47 0 0 0 SL syncer 0xffffffff80a9d6e0 [syncer] 46 0 0 0 SL psleep 0xffffffff80b3013c [bufdaemon] 45 0 0 0 SL pgzero 0xffffffff80b416c4 [pagezero] 44 0 0 0 SL psleep 0xffffffff80b40a08 [vmdaemon] 43 0 0 0 SL psleep 0xffffffff80b409cc [pagedaemon] 42 0 0 0 SL zfs:(&ar 0xffffffff80d2a330 [arc_reclaim_thread] 41 0 0 0 SL waiting_ 0xffffffff80b33868 [sctp_iterator] 40 0 0 0 WL [irq1: atkbd0] 39 0 0 0 WL [swi0: sio] 38 0 0 0 WL [irq7: ppbus0 ppc0] 37 0 0 0 SL - 0xffffff000364cd80 [em0 taskq] 36 0 0 0 WL [irq17: atapci2+] 35 0 0 0 WL [irq15: ata1] 34 0 0 0 WL [irq14: ata0] 33 0 0 0 SL - 0xffffff0003600280 [nfe0 taskq] 32 0 0 0 SL usbevt 0xffffff00033da420 [usb2] 31 0 0 0 WL [irq22: ehci0] 30 0 0 0 SL usbevt 0xffffffff8103b420 [usb1] 29 0 0 0 WL [irq21: ohci1+] 28 0 0 0 SL usbtsk 0xffffffff80a98e48 [usbtask-dr] 27 0 0 0 SL usbtsk 0xffffffff80a98e20 [usbtask-hc] 26 0 0 0 SL usbevt 0xffffffff81039420 [usb0] 25 0 0 0 WL [irq20: nfe0 ohci0] 24 0 0 0 WL [irq9: acpi0] 23 0 0 0 SL - 0xffffff000138b000 [kqueue taskq] 22 0 0 0 SL - 0xffffff000138b080 [acpi_task_2] 21 0 0 0 SL - 0xffffff000138b080 [acpi_task_1] 9 0 0 0 SL - 0xffffff000138b080 [acpi_task_0] 20 0 0 0 WL [swi2: cambio] 8 0 0 0 SL ccb_scan 0xffffffff80a66fe0 [xpt_thrd] 19 0 0 0 WL [swi6: task queue] 18 0 0 0 WL [swi6: Giant taskq] 7 0 0 0 SL - 0xffffff0001337600 [thread taskq] 17 0 0 0 WL [swi5: +] 6 0 0 0 SL zfs:(&tq 0xffffff0001349080 [system_taskq] 5 0 0 0 SL zfs:(&tq 0xffffff0001349080 [system_taskq] 16 0 0 0 SL - 0xffffffff80a9d6e8 [yarrow] 4 0 0 0 SL - 0xffffffff80a99778 [g_down] 3 0 0 0 SL - 0xffffffff80a99770 [g_up] 2 0 0 0 SL - 0xffffffff80a99760 [g_event] 15 0 0 0 WL [swi3: vm] 14 0 0 0 RL CPU 0 [swi4: clock sio] 13 0 0 0 WL [swi1: net] 12 0 0 0 RL [idle: cpu0] 11 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xffffff000122f8d0 [init] 10 0 0 0 SL audit_wo 0xffffffff80b3f0c0 [audit] 0 0 0 0 WLs [swapper] From nike_d at cytexbg.com Wed May 21 19:23:02 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed May 21 19:23:06 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <200805211944.42418.max@love2party.net> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805211944.42418.max@love2party.net> Message-ID: <2e77fc10805211223l7fd69e4cwdd488bada0dc7b95@mail.gmail.com> On Wed, May 21, 2008 at 8:44 PM, Max Laier wrote: > On Wednesday 21 May 2008 19:31:46 Niki Denev wrote: >> If one tries to use lagg0.2 style vlans on lagg0 interface configured >> from rc.conf it does't work. >> The problem is that all of the cloned interfaces (lagg0 , lagg0.2, etc) >> are created before any other interface configuration is done, >> and in this case lagg0 is created, then lagg0.2 is created. >> But because lagg0 does not have any members yet, it's MAC address >> is all zeroes, and this is inherited by the vlan interfaces. >> At the next step the members are added to the lagg0 interface and it's >> mac address gets set, >> but the vlan interfaces never see this change and remain with mac >> address 00:00:00:00:00:00 and in unusable state. >> >> Does it sound reasonable for the vlan(4) interfaces to update their >> mac address when their parent changes it. >> (this should probably look more like the parent telling the vlans >> attached to it that it's mac has changed, but >> i'm not sure if the parent knows about children interfaces) > > It doesn't (and shouldn't have to). I'd simply add an > EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do that for > INET[6] address already. Then vlan (and any other device interested in > LLaddress changes) can simply register to that eventhandler and resync. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Yes, you are absolutely right. I wasn't aware of EVENTHANDLER(4). Niki From jfvogel at gmail.com Wed May 21 20:26:11 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed May 21 20:26:15 2008 Subject: [em][panic] recursed on non-recursive mutex em0 In-Reply-To: References: Message-ID: <2a41acea0805211326v74baa017tc03fcd329a764ef5@mail.gmail.com> On Wed, May 21, 2008 at 12:11 PM, Neil Hoggarth wrote: > Hi Folks, > > I opened PR kern/122928 last month, describing my problems with Intel > PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driver: every > so often the machine would get into a state where it would repeatedly > watchdog timeout the em0 interface, and the interface would stop > receiving packets. > > A few weeks ago I cvsupped a newer version of the 7-STABLE source > tree, after v6.9.0 of the em driver was MFCed. Since I started running > on the newer build watchdog timeouts appear to be followed by a system > panic rather than the freezing up of the interface. I have no hard > evidence but it "feels like" the panics are happening under the same > sort of circumstance that was previously triggering my watchdog > problem (basically network activity combined with CPU load). A similar > observation was made by Yani Karydis on the freebsd-stable mailing > list earlier in the month: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042311.html > > I've now got a serial console set up, and I'm running a kernel with > DDB support compiled in. I managed to get the information below out of > the most recent panic. Is anyone able to use this to debug the > situation? What else might I try to gather useful information? This is a helpful start, I'll stare at the code and see... sounds like some rx lock design issue. Thanks Neil, Jack From nike_d at cytexbg.com Wed May 21 20:44:43 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed May 21 20:44:47 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805211223l7fd69e4cwdd488bada0dc7b95@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805211944.42418.max@love2party.net> <2e77fc10805211223l7fd69e4cwdd488bada0dc7b95@mail.gmail.com> Message-ID: <2e77fc10805211344m606886f9pd45ff7b001bc8da0@mail.gmail.com> On Wed, May 21, 2008 at 8:44 PM, Max Laier wrote: >> It doesn't (and shouldn't have to). I'd simply add an >> EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do that for >> INET[6] address already. Then vlan (and any other device interested in >> LLaddress changes) can simply register to that eventhandler and resync. >> Hi, Does this look like a reasonable solution? It passes my limited testing. Niki diff -ur /usr/src/sys/net/if.c /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if.c --- /usr/src/sys/net/if.c 2008-04-29 23:43:08.000000000 +0300 +++ /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if.c 2008-05-21 22:12:33.989318352 +0300 @@ -2647,6 +2647,11 @@ } #endif } + /* + * Notify interested parties (clonable children like if_vlan(4)) + * about the link layer address change + */ + EVENTHANDLER_INVOKE(ifaddr_event, ifp); return (0); } diff -ur /usr/src/sys/net/if_vlan.c /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if_vlan.c --- /usr/src/sys/net/if_vlan.c 2007-10-28 18:24:16.000000000 +0200 +++ /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if_vlan.c 2008-05-21 23:24:13.322156460 +0300 @@ -137,6 +137,7 @@ static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN Interface"); static eventhandler_tag ifdetach_tag; +static eventhandler_tag ifaddr_tag; /* * We have a global mutex, that is used to serialize configuration @@ -518,6 +519,33 @@ /* For if_link_state_change() eyes only... */ extern void (*vlan_link_state_p)(struct ifnet *, int); +/* + * Update vlan interface link layer address on + * parent interface link layer address change. + */ +static int +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) +{ + struct ifvlantrunk *trunk = ifp->if_vlantrunk; + struct ifvlan *ifv; + int i; + + TRUNK_LOCK(trunk); +#ifdef VLAN_ARRAY + for (i = 0; i < VLAN_ARRAY_SIZE; i++) + if (trunk->vlans[i] != NULL) { + ifv = trunk->vlans[i]; +#else + for (i = 0; i < (1 << trunk->hwidth); i++) { + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) +#endif + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), + ETHER_ADDR_LEN); + } + TRUNK_UNLOCK(trunk); + return 0; +} + static int vlan_modevent(module_t mod, int type, void *data) { @@ -528,6 +556,10 @@ vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); if (ifdetach_tag == NULL) return (ENOMEM); + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, + vlan_lladdr_update, NULL, EVENTHANDLER_PRI_ANY); + if (ifaddr_tag == NULL) + return (ENOMEM); VLAN_LOCK_INIT(); vlan_input_p = vlan_input; vlan_link_state_p = vlan_link_state; @@ -546,6 +578,7 @@ case MOD_UNLOAD: if_clone_detach(&vlan_cloner); EVENTHANDLER_DEREGISTER(ifnet_departure_event, ifdetach_tag); + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); vlan_input_p = NULL; vlan_link_state_p = NULL; vlan_trunk_cap_p = NULL; From jfvogel at gmail.com Wed May 21 20:52:19 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed May 21 20:52:22 2008 Subject: [em][panic] recursed on non-recursive mutex em0 In-Reply-To: <2a41acea0805211326v74baa017tc03fcd329a764ef5@mail.gmail.com> References: <2a41acea0805211326v74baa017tc03fcd329a764ef5@mail.gmail.com> Message-ID: <2a41acea0805211352s37e6fd40maaaac90e51912947@mail.gmail.com> On Wed, May 21, 2008 at 1:26 PM, Jack Vogel wrote: > On Wed, May 21, 2008 at 12:11 PM, Neil Hoggarth wrote: >> Hi Folks, >> >> I opened PR kern/122928 last month, describing my problems with Intel >> PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driver: every >> so often the machine would get into a state where it would repeatedly >> watchdog timeout the em0 interface, and the interface would stop >> receiving packets. >> >> A few weeks ago I cvsupped a newer version of the 7-STABLE source >> tree, after v6.9.0 of the em driver was MFCed. Since I started running >> on the newer build watchdog timeouts appear to be followed by a system >> panic rather than the freezing up of the interface. I have no hard >> evidence but it "feels like" the panics are happening under the same >> sort of circumstance that was previously triggering my watchdog >> problem (basically network activity combined with CPU load). A similar >> observation was made by Yani Karydis on the freebsd-stable mailing >> list earlier in the month: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042311.html >> >> I've now got a serial console set up, and I'm running a kernel with >> DDB support compiled in. I managed to get the information below out of >> the most recent panic. Is anyone able to use this to debug the >> situation? What else might I try to gather useful information? > > This is a helpful start, I'll stare at the code and see... sounds like some > rx lock design issue. OPPS, I think I found the problem, look for a delta on if_em.c shortly. Let me know if this fixes your problem. Jack From max at love2party.net Wed May 21 21:06:23 2008 From: max at love2party.net (Max Laier) Date: Wed May 21 21:06:27 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805211344m606886f9pd45ff7b001bc8da0@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <2e77fc10805211223l7fd69e4cwdd488bada0dc7b95@mail.gmail.com> <2e77fc10805211344m606886f9pd45ff7b001bc8da0@mail.gmail.com> Message-ID: <200805212305.58235.max@love2party.net> On Wednesday 21 May 2008 22:44:42 Niki Denev wrote: > On Wed, May 21, 2008 at 8:44 PM, Max Laier wrote: > >> It doesn't (and shouldn't have to). I'd simply add an > >> EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do > >> that for INET[6] address already. Then vlan (and any other device > >> interested in LLaddress changes) can simply register to that > >> eventhandler and resync. > > Hi, > Does this look like a reasonable solution? > It passes my limited testing. Looks good, though I'd probably move up the _INVOKE to before the ARPs are sent out. Probably between twiddling the hardware and sending ARPs (though that needs an else-case if the interface is still down). In fact the ARPs could be sent from an event hook, too. This would get rid of INET specific code in the LL-interface code. > Niki > > diff -ur /usr/src/sys/net/if.c > /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if.c > --- /usr/src/sys/net/if.c 2008-04-29 23:43:08.000000000 +0300 > +++ /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if.c > 2008-05-21 22:12:33.989318352 +0300 > @@ -2647,6 +2647,11 @@ > } > #endif > } > + /* > + * Notify interested parties (clonable children like > if_vlan(4)) + * about the link layer address change > + */ > + EVENTHANDLER_INVOKE(ifaddr_event, ifp); > return (0); > } > > diff -ur /usr/src/sys/net/if_vlan.c > /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if_vlan.c > --- /usr/src/sys/net/if_vlan.c 2007-10-28 18:24:16.000000000 +0200 > +++ /usr/src/.zfs/snapshot/vlan_lladdr_patch/sys/net/if_vlan.c > 2008-05-21 23:24:13.322156460 +0300 > @@ -137,6 +137,7 @@ > static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN > Interface"); > > static eventhandler_tag ifdetach_tag; > +static eventhandler_tag ifaddr_tag; > > /* > * We have a global mutex, that is used to serialize configuration > @@ -518,6 +519,33 @@ > /* For if_link_state_change() eyes only... */ > extern void (*vlan_link_state_p)(struct ifnet *, int); > > +/* > + * Update vlan interface link layer address on > + * parent interface link layer address change. > + */ > +static int > +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) > +{ > + struct ifvlantrunk *trunk = ifp->if_vlantrunk; > + struct ifvlan *ifv; > + int i; > + > + TRUNK_LOCK(trunk); > +#ifdef VLAN_ARRAY > + for (i = 0; i < VLAN_ARRAY_SIZE; i++) > + if (trunk->vlans[i] != NULL) { > + ifv = trunk->vlans[i]; > +#else > + for (i = 0; i < (1 << trunk->hwidth); i++) { > + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) > +#endif > + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), > + ETHER_ADDR_LEN); > + } > + TRUNK_UNLOCK(trunk); > + return 0; > +} > + > static int > vlan_modevent(module_t mod, int type, void *data) > { > @@ -528,6 +556,10 @@ > vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); > if (ifdetach_tag == NULL) > return (ENOMEM); > + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, > + vlan_lladdr_update, NULL, EVENTHANDLER_PRI_ANY); > + if (ifaddr_tag == NULL) > + return (ENOMEM); > VLAN_LOCK_INIT(); > vlan_input_p = vlan_input; > vlan_link_state_p = vlan_link_state; > @@ -546,6 +578,7 @@ > case MOD_UNLOAD: > if_clone_detach(&vlan_cloner); > EVENTHANDLER_DEREGISTER(ifnet_departure_event, > ifdetach_tag); + EVENTHANDLER_DEREGISTER(ifaddr_event, > ifaddr_tag); vlan_input_p = NULL; > vlan_link_state_p = NULL; > vlan_trunk_cap_p = NULL; -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From nike_d at cytexbg.com Wed May 21 21:22:53 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed May 21 21:22:55 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <200805212305.58235.max@love2party.net> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <2e77fc10805211223l7fd69e4cwdd488bada0dc7b95@mail.gmail.com> <2e77fc10805211344m606886f9pd45ff7b001bc8da0@mail.gmail.com> <200805212305.58235.max@love2party.net> Message-ID: <2e77fc10805211422q75603d54h5709ed3e5be37d0a@mail.gmail.com> On Thu, May 22, 2008 at 12:05 AM, Max Laier wrote: > Looks good, though I'd probably move up the _INVOKE to before the ARPs are > sent out. Probably between twiddling the hardware and sending ARPs > (though that needs an else-case if the interface is still down). In fact > the ARPs could be sent from an event hook, too. This would get rid of > INET specific code in the LL-interface code. > I thought about moving it up too, but in this case isn't it going to be called only if the interface is up (IFF_UP)? Here is an updated version that makes vlan_lladdr_update() check if ifp->if_vlantrunk exists, because otherwise we get a panic if there is a change of the link layer address on different interface that does not have vlan children. diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if.c /usr/src/sys/net/if.c --- /usr/src/.zfs/snapshot/orig/sys/net/if.c 2008-04-29 23:43:08.000000000 +0300 +++ /usr/src/sys/net/if.c 2008-05-21 23:48:59.621157217 +0300 @@ -2647,6 +2647,12 @@ } #endif } + /* + * Notify interested parties (clonable children like if_vlan(4)) + * about the link layer address change + */ + EVENTHANDLER_INVOKE(ifaddr_event, ifp); + return (0); } diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c /usr/src/sys/net/if_vlan.c --- /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c 2007-10-28 18:24:16.000000000 +0200 +++ /usr/src/sys/net/if_vlan.c 2008-05-22 00:18:57.128613715 +0300 @@ -137,6 +137,7 @@ static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN Interface"); static eventhandler_tag ifdetach_tag; +static eventhandler_tag ifaddr_tag; /* * We have a global mutex, that is used to serialize configuration @@ -518,6 +519,35 @@ /* For if_link_state_change() eyes only... */ extern void (*vlan_link_state_p)(struct ifnet *, int); +/* + * Update vlan interface link layer address on + * parent interface link layer address change. + */ +static int +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) +{ + struct ifvlantrunk *trunk = ifp->if_vlantrunk; + struct ifvlan *ifv; + int i; + + if (trunk) { + TRUNK_LOCK(trunk); +#ifdef VLAN_ARRAY + for (i = 0; i < VLAN_ARRAY_SIZE; i++) + if (trunk->vlans[i] != NULL) { + ifv = trunk->vlans[i]; +#else + for (i = 0; i < (1 << trunk->hwidth); i++) { + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) +#endif + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), + ETHER_ADDR_LEN); + } + TRUNK_UNLOCK(trunk); + } + return (0); +} + static int vlan_modevent(module_t mod, int type, void *data) { @@ -528,6 +558,10 @@ vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); if (ifdetach_tag == NULL) return (ENOMEM); + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, + vlan_lladdr_update, NULL, EVENTHANDLER_PRI_ANY); + if (ifaddr_tag == NULL) + return (ENOMEM); VLAN_LOCK_INIT(); vlan_input_p = vlan_input; vlan_link_state_p = vlan_link_state; @@ -546,6 +580,7 @@ case MOD_UNLOAD: if_clone_detach(&vlan_cloner); EVENTHANDLER_DEREGISTER(ifnet_departure_event, ifdetach_tag); + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); vlan_input_p = NULL; vlan_link_state_p = NULL; vlan_trunk_cap_p = NULL; From max at love2party.net Wed May 21 21:32:33 2008 From: max at love2party.net (Max Laier) Date: Wed May 21 21:32:37 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805211422q75603d54h5709ed3e5be37d0a@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212305.58235.max@love2party.net> <2e77fc10805211422q75603d54h5709ed3e5be37d0a@mail.gmail.com> Message-ID: <200805212332.13993.max@love2party.net> On Wednesday 21 May 2008 23:22:52 Niki Denev wrote: > On Thu, May 22, 2008 at 12:05 AM, Max Laier wrote: > > Looks good, though I'd probably move up the _INVOKE to before the > > ARPs are sent out. Probably between twiddling the hardware and > > sending ARPs (though that needs an else-case if the interface is ^------------------------------------------------- > > still down). In fact the ARPs could be sent from an event hook, too. ---------^ > > This would get rid of INET specific code in the LL-interface code. > > I thought about moving it up too, but in this case isn't it going to > be called only if the interface is up (IFF_UP)? See above. > Here is an updated version that makes vlan_lladdr_update() check if > ifp->if_vlantrunk exists, > because otherwise we get a panic if there is a change of the link > layer address on different interface that > does not have vlan children. > > diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if.c /usr/src/sys/net/if.c > --- /usr/src/.zfs/snapshot/orig/sys/net/if.c 2008-04-29 > 23:43:08.000000000 +0300 +++ /usr/src/sys/net/if.c 2008-05-21 > 23:48:59.621157217 +0300 > @@ -2647,6 +2647,12 @@ > } > #endif > } > + /* > + * Notify interested parties (clonable children like if_vlan(4)) > + * about the link layer address change > + */ > + EVENTHANDLER_INVOKE(ifaddr_event, ifp); > + > return (0); > } > > diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c > /usr/src/sys/net/if_vlan.c > --- /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c 2007-10-28 > 18:24:16.000000000 +0200 > +++ /usr/src/sys/net/if_vlan.c 2008-05-22 00:18:57.128613715 +0300 > @@ -137,6 +137,7 @@ > static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN > Interface"); > > static eventhandler_tag ifdetach_tag; > +static eventhandler_tag ifaddr_tag; > > /* > * We have a global mutex, that is used to serialize configuration > @@ -518,6 +519,35 @@ > /* For if_link_state_change() eyes only... */ > extern void (*vlan_link_state_p)(struct ifnet *, int); > > +/* > + * Update vlan interface link layer address on > + * parent interface link layer address change. > + */ > +static int > +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) > +{ > + struct ifvlantrunk *trunk = ifp->if_vlantrunk; > + struct ifvlan *ifv; > + int i; > + > + if (trunk) { > + TRUNK_LOCK(trunk); > +#ifdef VLAN_ARRAY > + for (i = 0; i < VLAN_ARRAY_SIZE; i++) > + if (trunk->vlans[i] != NULL) { > + ifv = trunk->vlans[i]; > +#else > + for (i = 0; i < (1 << trunk->hwidth); i++) { > + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) > +#endif > + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), > + ETHER_ADDR_LEN); > + } > + TRUNK_UNLOCK(trunk); > + } > + return (0); > +} > + > static int > vlan_modevent(module_t mod, int type, void *data) > { > @@ -528,6 +558,10 @@ > vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); > if (ifdetach_tag == NULL) > return (ENOMEM); > + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, > + vlan_lladdr_update, NULL, EVENTHANDLER_PRI_ANY); > + if (ifaddr_tag == NULL) > + return (ENOMEM); > VLAN_LOCK_INIT(); > vlan_input_p = vlan_input; > vlan_link_state_p = vlan_link_state; > @@ -546,6 +580,7 @@ > case MOD_UNLOAD: > if_clone_detach(&vlan_cloner); > EVENTHANDLER_DEREGISTER(ifnet_departure_event, ifdetach_tag); > + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); > vlan_input_p = NULL; > vlan_link_state_p = NULL; > vlan_trunk_cap_p = NULL; -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From rwatson at FreeBSD.org Wed May 21 21:45:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed May 21 21:45:29 2008 Subject: netatm removal warning In-Reply-To: <20080310122338.T29929@fledge.watson.org> References: <20080310122338.T29929@fledge.watson.org> Message-ID: <20080521224350.T63482@fledge.watson.org> On Mon, 10 Mar 2008, Robert Watson wrote: > This is another of those boring e-mails about kernel subsystems that still > require Giant. Sorry about that! > > As previously published, netatm is a non-MPSAFE protocol stack largely > superseded by our two other ATM stacks, netnatm and the netgraph/atm (both > MPSAFE). netatm is currently non-functional and uncompileable because it > depends on the Giant compatibility shims for the protocol stack, which were > removed in FreeBSD 7.0. We left the code in place in case to make it easier > for any interested third parties to distribute patches against it (in > particular, patches to make it MPSAFE). > > The current plan is that we will remove the netatm code from HEAD and > RELENG_7 before FreeBSD 7.1. A specific schedue for 7.1 hasn't been > published yet, but in order to give plenty of warning, here's the proposed > netatm removal schedule: > > 10 March 2008 E-mail warning to arch@/net@ > 10 April 2008 E-mail warning to arch@/net@ > 10 May 2008 Removal of netatm from HEAD > 20 May 2008 Removal of netatm from RELENG_7 > > Obviously, netatm will remain in the revision control history should anyone > wish to ressurect it after that date. However, I suspect that those > interested in ATM on FreeBSD have long since been using Harti's netgraph ATM > framework. Somehow the dates slipped pasted more quickly than I had hoped -- this is the HEADS UP that, on a slightly delayed schedule, I will be trimming netatm from the src tree for HEAD, and then a week or two later, from RELENG_7. Assuming all goes well, this should result in no functional change at all. Robert N M Watson Computer Laboratory University of Cambridge From nike_d at cytexbg.com Wed May 21 22:14:37 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed May 21 22:14:41 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <200805212332.13993.max@love2party.net> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212305.58235.max@love2party.net> <2e77fc10805211422q75603d54h5709ed3e5be37d0a@mail.gmail.com> <200805212332.13993.max@love2party.net> Message-ID: <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> On Thu, May 22, 2008 at 12:32 AM, Max Laier wrote: > On Wednesday 21 May 2008 23:22:52 Niki Denev wrote: >> On Thu, May 22, 2008 at 12:05 AM, Max Laier wrote: >> > Looks good, though I'd probably move up the _INVOKE to before the >> > ARPs are sent out. Probably between twiddling the hardware and >> > sending ARPs (though that needs an else-case if the interface is > ^------------------------------------------------- >> > still down). In fact the ARPs could be sent from an event hook, too. > ---------^ >> > This would get rid of INET specific code in the LL-interface code. >> >> I thought about moving it up too, but in this case isn't it going to >> be called only if the interface is up (IFF_UP)? > > See above. > Oh, I've missed that. So, generating ARPs from an event handler looks to like the best solution. But in that case what would be the correct place for it? if_ethersubr.c and the others (fw,fddi,arc...) that may use ARP? Niki From max at love2party.net Wed May 21 22:41:44 2008 From: max at love2party.net (Max Laier) Date: Wed May 21 22:41:48 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212332.13993.max@love2party.net> <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> Message-ID: <200805220041.24096.max@love2party.net> On Thursday 22 May 2008 00:14:37 Niki Denev wrote: > On Thu, May 22, 2008 at 12:32 AM, Max Laier wrote: > > On Wednesday 21 May 2008 23:22:52 Niki Denev wrote: > >> On Thu, May 22, 2008 at 12:05 AM, Max Laier wrote: > >> > Looks good, though I'd probably move up the _INVOKE to before the > >> > ARPs are sent out. Probably between twiddling the hardware and > >> > sending ARPs (though that needs an else-case if the interface is > > > > ^------------------------------------------------- > > > >> > still down). In fact the ARPs could be sent from an event hook, > >> > too. > > > > ---------^ > > > >> > This would get rid of INET specific code in the LL-interface > >> > code. > >> > >> I thought about moving it up too, but in this case isn't it going to > >> be called only if the interface is up (IFF_UP)? > > > > See above. > > Oh, I've missed that. > > So, generating ARPs from an event handler looks to like the best > solution. But in that case what would be the correct place for it? > if_ethersubr.c and the others (fw,fddi,arc...) that may use ARP? I think if_ether.c would be good, where arp_ifinit() is. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From nike_d at cytexbg.com Thu May 22 03:57:05 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Thu May 22 03:57:09 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <200805220041.24096.max@love2party.net> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212332.13993.max@love2party.net> <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> <200805220041.24096.max@love2party.net> Message-ID: <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com> On Thu, May 22, 2008 at 1:41 AM, Max Laier wrote: > I think if_ether.c would be good, where arp_ifinit() is. > Here is what i've come up with (some comments after the patch) : diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if.c /usr/src/sys/net/if.c --- /usr/src/.zfs/snapshot/orig/sys/net/if.c 2008-04-29 23:43:08.000000000 +0300 +++ /usr/src/sys/net/if.c 2008-05-22 04:56:42.652730327 +0300 @@ -2636,17 +2636,12 @@ (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); IFF_UNLOCKGIANT(ifp); } -#ifdef INET - /* - * Also send gratuitous ARPs to notify other nodes about - * the address change. - */ - TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family == AF_INET) - arp_ifinit(ifp, ifa); - } -#endif } + /* + * Notify interested parties about the link layer address change. + */ + EVENTHANDLER_INVOKE(ifaddr_event, ifp); + return (0); } diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_ethersubr.c /usr/src/sys/net/if_ethersubr.c --- /usr/src/.zfs/snapshot/orig/sys/net/if_ethersubr.c 2008-05-21 23:29:07.899194044 +0300 +++ /usr/src/sys/net/if_ethersubr.c 2008-05-22 06:38:35.698083868 +0300 @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -99,6 +100,8 @@ #include +static eventhandler_tag ifaddr_tag; + /* netgraph node hooks for ng_ether(4) */ void (*ng_ether_input_p)(struct ifnet *ifp, struct mbuf **mp); void (*ng_ether_input_orphan_p)(struct ifnet *ifp, struct mbuf *m); @@ -910,6 +913,13 @@ if_printf(ifp, "Ethernet address: %6D\n", lla, ":"); if (ifp->if_flags & IFF_NEEDSGIANT) if_printf(ifp, "if_start running deferred for Giant\n"); +#ifdef INET + /* Register address change hook */ + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, arp_gratuit, + NULL, EVENTHANDLER_PRI_ANY); + //if (ifaddr_tag == NULL) + // return (ENOMEM); +#endif } /* @@ -924,6 +934,8 @@ (*ng_ether_detach_p)(ifp); } + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); + bpfdetach(ifp); if_detach(ifp); } diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c /usr/src/sys/net/if_vlan.c --- /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c 2007-10-28 18:24:16.000000000 +0200 +++ /usr/src/sys/net/if_vlan.c 2008-05-22 00:18:57.128613715 +0300 @@ -137,6 +137,7 @@ static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN Interface"); static eventhandler_tag ifdetach_tag; +static eventhandler_tag ifaddr_tag; /* * We have a global mutex, that is used to serialize configuration @@ -518,6 +519,35 @@ /* For if_link_state_change() eyes only... */ extern void (*vlan_link_state_p)(struct ifnet *, int); +/* + * Update vlan interface link layer address on + * parent interface link layer address change. + */ +static int +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) +{ + struct ifvlantrunk *trunk = ifp->if_vlantrunk; + struct ifvlan *ifv; + int i; + + if (trunk) { + TRUNK_LOCK(trunk); +#ifdef VLAN_ARRAY + for (i = 0; i < VLAN_ARRAY_SIZE; i++) + if (trunk->vlans[i] != NULL) { + ifv = trunk->vlans[i]; +#else + for (i = 0; i < (1 << trunk->hwidth); i++) { + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) +#endif + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), + ETHER_ADDR_LEN); + } + TRUNK_UNLOCK(trunk); + } + return (0); +} + static int vlan_modevent(module_t mod, int type, void *data) { @@ -528,6 +558,10 @@ vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); if (ifdetach_tag == NULL) return (ENOMEM); + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, + vlan_lladdr_update, NULL, EVENTHANDLER_PRI_ANY); + if (ifaddr_tag == NULL) + return (ENOMEM); VLAN_LOCK_INIT(); vlan_input_p = vlan_input; vlan_link_state_p = vlan_link_state; @@ -546,6 +580,7 @@ case MOD_UNLOAD: if_clone_detach(&vlan_cloner); EVENTHANDLER_DEREGISTER(ifnet_departure_event, ifdetach_tag); + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); vlan_input_p = NULL; vlan_link_state_p = NULL; vlan_trunk_cap_p = NULL; diff -ur /usr/src/.zfs/snapshot/orig/sys/netinet/if_ether.c /usr/src/sys/netinet/if_ether.c --- /usr/src/.zfs/snapshot/orig/sys/netinet/if_ether.c 2007-10-07 23:44:22.000000000 +0300 +++ /usr/src/sys/netinet/if_ether.c 2008-05-22 06:41:34.966106759 +0300 @@ -956,6 +956,16 @@ ifa->ifa_flags |= RTF_CLONING; } +void +arp_gratuit(void *arg __unused, struct ifnet *ifp) +{ + struct ifaddr *ifa; + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (ifa->ifa_addr->sa_family == AF_INET) + arp_ifinit(ifp, ifa); + } +} + static void arp_init(void) { diff -ur /usr/src/.zfs/snapshot/orig/sys/netinet/if_ether.h /usr/src/sys/netinet/if_ether.h --- /usr/src/.zfs/snapshot/orig/sys/netinet/if_ether.h 2005-02-22 15:04:03.000000000 +0200 +++ /usr/src/sys/netinet/if_ether.h 2008-05-22 05:24:06.749938771 +0300 @@ -113,6 +113,7 @@ struct mbuf *m, struct sockaddr *dst, u_char *desten); void arp_ifinit(struct ifnet *, struct ifaddr *); void arp_ifinit2(struct ifnet *, struct ifaddr *, u_char *); +void arp_gratuit(void *, struct ifnet *); #endif #endif I think arp_gratuit() needs a better name. Is if_ethersubr.c:ether_ifattach() good place to register the EVENT hook? And if yes, what would be the best way to handle failure to register the hook, as the function is void? Should I worry about that, or just print a warning message and continue? Niki From ganbold at micom.mng.net Thu May 22 07:38:30 2008 From: ganbold at micom.mng.net (Ganbold) Date: Thu May 22 07:38:34 2008 Subject: ipfw fwd layer2/ftp proxy Message-ID: <483522F3.4090200@micom.mng.net> Hi there, I'm having trouble allowing ftp connections through ipfw (default deny) enabled bridge firewall. I'm wondering whether it is possible to have some kind of transparent ftp proxy in such case. Is there anyway I can allow ftp proxying without layer2 forwarding on ipfw bridge? I thought of forwarding packets in layer2, however it seems like ipfw still doesn't support that. I saw old patches of luigi@ and if somebody already has adapted that patch for RELENG_6/7 please let me know. I know my last try is to deny everything I don't want and then allow the rest. However I would like to make it work in current configuration. Please let me know your ideas. thanks in advance, Ganbold -- Sometimes I simply feel that the whole world is a cigarette and I'm the only ashtray. From eugen at kuzbass.ru Thu May 22 08:03:49 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu May 22 08:03:53 2008 Subject: ipfw fwd layer2/ftp proxy In-Reply-To: <483522F3.4090200@micom.mng.net> References: <483522F3.4090200@micom.mng.net> Message-ID: <20080522080337.GA21814@svzserv.kemerovo.su> On Thu, May 22, 2008 at 03:38:27PM +0800, Ganbold wrote: > I'm having trouble allowing ftp connections through ipfw (default deny) > enabled bridge firewall. > I'm wondering whether it is possible to have some kind of transparent > ftp proxy in such case. > > Is there anyway I can allow ftp proxying without layer2 forwarding on > ipfw bridge? You need not ftp proxy to make it work. Just allow ports that your ftp server uses. Eugene Grosbein From ganbold at micom.mng.net Thu May 22 08:34:27 2008 From: ganbold at micom.mng.net (Ganbold) Date: Thu May 22 08:34:33 2008 Subject: ipfw fwd layer2/ftp proxy In-Reply-To: <20080522080337.GA21814@svzserv.kemerovo.su> References: <483522F3.4090200@micom.mng.net> <20080522080337.GA21814@svzserv.kemerovo.su> Message-ID: <48353010.20105@micom.mng.net> Eugene Grosbein wrote: > On Thu, May 22, 2008 at 03:38:27PM +0800, Ganbold wrote: > > >> I'm having trouble allowing ftp connections through ipfw (default deny) >> enabled bridge firewall. >> I'm wondering whether it is possible to have some kind of transparent >> ftp proxy in such case. >> >> Is there anyway I can allow ftp proxying without layer2 forwarding on >> ipfw bridge? >> > > You need not ftp proxy to make it work. Just allow ports that your > ftp server uses. > I know what you mean here. But ftp server is beyond my control (different ISP) and I don't know what ports it really uses. Ganbold > Eugene Grosbein > _______________________________________________ > 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" > > > > -- God made machine language; all the rest is the work of man. From eugen at kuzbass.ru Thu May 22 08:38:31 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu May 22 08:38:34 2008 Subject: ipfw fwd layer2/ftp proxy In-Reply-To: <48353010.20105@micom.mng.net> References: <483522F3.4090200@micom.mng.net> <20080522080337.GA21814@svzserv.kemerovo.su> <48353010.20105@micom.mng.net> Message-ID: <20080522083823.GA26482@svzserv.kemerovo.su> On Thu, May 22, 2008 at 04:34:24PM +0800, Ganbold wrote: > >You need not ftp proxy to make it work. Just allow ports that your > >ftp server uses. > > I know what you mean here. But ftp server is beyond my control > (different ISP) and > I don't know what ports it really uses. Then use ftp passive mode and you'll need not open a port locally. Eugene From vwe at FreeBSD.org Thu May 22 08:56:22 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Thu May 22 08:56:23 2008 Subject: kern/123053: [re][patch] re(4) unsupported hardware revision (8168/8111b) Message-ID: <200805220856.m4M8uLWV065867@freefall.freebsd.org> Synopsis: [re][patch] re(4) unsupported hardware revision (8168/8111b) Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: vwe Responsible-Changed-When: Thu May 22 08:53:48 UTC 2008 Responsible-Changed-Why: reassign to rpaulo who has a similar ticket with a similar patch assigned. Rui: Can you please bring this ticket with kern/123123 in line? Either of one can be closed IMHO as the patches are very close to each other. http://www.freebsd.org/cgi/query-pr.cgi?pr=123053 From bms at FreeBSD.org Thu May 22 12:42:56 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu May 22 12:43:01 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212332.13993.max@love2party.net> <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> <200805220041.24096.max@love2party.net> <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com> Message-ID: <48356A4D.2050404@FreeBSD.org> Hi, It looks like this patch will cause gratuitous ARP to be queued even when the interface is not IFF_UP, is this intentional? Niki Denev wrote: > > I think arp_gratuit() needs a better name. > arp_announce() ? > Is if_ethersubr.c:ether_ifattach() good place to register the EVENT hook? > ARP is also used by FDDI and IEEE 802.5, as well as anything which emulates this. Taking the call to arp_ifinit() out of if_setlladdr() is likely to break this code. > And if yes, what would be the best way to handle failure to register > the hook, as the function is void? > > Should I worry about that, or just print a warning message and continue? > I see the C++-style comments - perhaps someone who knows event handlers better than I can comment, I believe it's using one of the shared kernel malloc pools with M_WAIT. It looks like this won't run afoul of locking, but it is a change to a fairly central path which needs to be considered carefully as it affects consumers other than Ethernet drivers. cheers BMS From yes298 at gmail.com Thu May 22 13:40:04 2008 From: yes298 at gmail.com (yes298 yes298) Date: Thu May 22 13:40:06 2008 Subject: amd64/123603: tcp_do_segment and Received duplicate SYN Message-ID: <200805221340.m4MDe3YA092563@freefall.freebsd.org> The following reply was made to PR kern/123603; it has been noted by GNATS. From: "yes298 yes298" To: andre@freebsd.org Cc: "John Baldwin" , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/123603: tcp_do_segment and Received duplicate SYN Date: Thu, 22 May 2008 21:31:34 +0800 ------=_Part_11255_10246163.1211463094510 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir, Thank you so much for your reply. My FreeBSD 7.0-Release-p1 (x64) Lighttpd web server *directly connects* to ISP's Cisco 3400 Switch with a 100M broadband line, After ISP technician creating a ARP static mapping rule on the switch to map the IP and MAC of My web server NIC, the problem of 5 seconds delay to view homepage has been solved, now , it is quit normal , no any delay. But, my web server sill has received repeatly below log messages, May 21 15:17:53 mail kernel: TCP: [55.66.77.88]:45979 to [11.22.33.44]:63372 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: Received 1448 bytes of data after socket was closed, sending RST and removing tcpcb May 21 15:17:53 mail kernel: TCP: [55.66.77.88]:21 to [11.22.33.44]:55007 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 13 bytes of data after socket was closed, sending RST and removing tcpcb May 21 22:26:16 mail kernel: TCP: [55.66.77.88]:23439 to [11.22.33.44]:80 tcpflags 0x18; syncache_expand: SEQ 2071739782 != IRS+1 2071738353, segment rejected May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x10; syncache_expand: ACK 1544143634 != ISS+1 4145431138, segment rejected May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) May 22 11:33:20 mail kernel: TCP: [55.66.77.88]:32345 to [11.22.33.44]:80 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK I sure to you that there no one to hack my server, because 55.66.77.88 is my client computer IP. I would like to know that the above messages will cause any problem? and how to solve this problem? Thank you so much! Best regards, Victor ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Victor, Please try two things: 1. Make sure that you don't have a problem with MTU sizes. Some ADSL customers with PPPoE have slightly smaller MTU sizes than normal ethernet. Make sure that ICMP unreach packets are not firewalled or filtered on your side. 2. There was a bug in the TCP options in FreeBSD 7.0-RELEASE that was giving problems with a smaller number of CPE devices for ADSL and Cablemodem customers. The problem is fixed in 7-STABLE. Only upgrading the kernel is sufficient. I hope this helps. If not, please provide some tcpdumps so we can see the packets that are exchanged. -- Andre ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Dear Sir, Thank you so much for your reply. My FreeBSD 7.0(x64) Lighttpd web server connects to a 100M broadband line, after testing many times, I found that, when first time to view my website, it needed to take almost 5~8 seconds to completely open the homepage which is only a static HTML file with content "coming soon", and there are some error log about TCP connection found on our web server, it seems that my FreeBSD 7.0 web server has problem to establish TCP connection. Before the web server idle time (30s), there are no any delay to re-view the homepage (Press F5), but after 30 seconds, it needed to take another 5~8 seconds to re-view, and the log messages will be repeated. May 15 15:18:21 mail kernel: TCP: [203.186.95.8]:12728 to [58.177.222.113]:80 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK May 15 15:19:03 mail kernel: TCP: [221.127.88.188]:5128 to [58.177.222.113]:80 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK I know how to disable these log messages, but I would like to know that the delay is because of receiving duplicate SYN? is it normal message? Please help me to solve the problem, thanks !!!! Thank you so much! Best regards, Victor ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- On Monday 12 May 2008 03:45:16 am John wrote: > >Number: 123603 > >Category: amd64 > >Synopsis: tcp_do_segment and Received duplicate SYN > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Mon May 12 07:50:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: John > >Release: FB7.0 (x64) > >Organization: > > NULL > > >Environment: > > FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar 6 > 12:04:57 HKT 2008 root@mydomain.com:/usr/src/sys/amd64/compile/FB7NEW > amd64 > > >Description: > > A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and patchs. > when a client connect and view a static HTML file, At the first time > (before web server idle time), it needs to wait a long time to establish a > connection, OR when this server try to download file from Internet, there > are lots of logs messages just like below: > > May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44]:80 > tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer > and retransmitting SYN|ACK > May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to > [11.22.33.44]:63372 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: > Received 1448 bytes of data after socket was closed, sending RST and > removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to > [11.22.33.44]:55007 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: > Received 13 bytes of data after socket was closed, sending RST and removing > tcpcb > > >How-To-Repeat: > > any type of connection will generate above log messages. You can either comment out all the log(LOG_DEBUG, ...) calls in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send kern.debug messages to the console. I think these messages should probably be conditional on a kernel option FWIW. -- John Baldwin ------=_Part_11255_10246163.1211463094510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir,
 
Thank you so much for your reply.
 
My FreeBSD 7.0-Release-p1 (x64) Lighttpd web server directly connects to ISP's Cisco 3400 Switch with a 100M broadband line,
After ISP technician creating a ARP static mapping rule on the switch to map the IP and MAC of My web server NIC,
the problem of 5 seconds delay to view homepage has been solved, now , it is quit normal , no any delay.
But, my web server sill has received repeatly below log messages,

May 21 15:17:53 mail kernel: TCP: [55.66.77.88]:45979 to [11.22.33.44]:63372 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_1: Received 1448 bytes of data after socket was closed, sending RST and removing tcpcb
May 21 15:17:53 mail kernel: TCP: [55.66.77.88]:21 to [11.22.33.44]:55007 tcpflags 0x18<PUSH>; tcp_do_segment: FIN_WAIT_2: Received 13 bytes of data after socket was closed, sending RST and removing tcpcb
May 21 22:26:16 mail kernel: TCP: [55.66.77.88]:23439 to [11.22.33.44]:80 tcpflags 0x18<PUSH>; syncache_expand: SEQ 2071739782 != IRS+1 2071738353,
segment rejected
May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x10<ACK>; syncache_expand: ACK 1544143634 != ISS+1 4145431138, segment rejected
May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x18<PUSH,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed)
May 22 11:31:22 mail kernel: TCP: [55.66.77.88]:2988 to [11.22.33.44]:80 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed)
May 22 11:33:20 mail kernel: TCP: [55.66.77.88]:32345 to [11.22.33.44]:80 tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK

I sure to you that there no one to hack my server, because 55.66.77.88 is my client computer IP.
I would like to know that the above messages will cause any problem? and how to solve this problem?

Thank you so much!
 
Best regards,
Victor
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Victor,

Please try two things:

 1. Make sure that you don't have a problem with MTU sizes. Some ADSL
   customers with PPPoE have slightly smaller MTU sizes than normal
   ethernet. Make sure that ICMP unreach packets are not firewalled
   or filtered on your side.

 2. There was a bug in the TCP options in FreeBSD 7.0-RELEASE that was
   giving problems with a smaller number of CPE devices for ADSL and
   Cablemodem customers. The problem is fixed in 7-STABLE. Only upgrading
   the kernel is sufficient.

I hope this helps.  If not, please provide some tcpdumps so we can see
the packets that are exchanged.

--
Andre
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Dear Sir,
 
Thank you so much for your reply.
 
My FreeBSD 7.0(x64) Lighttpd web server connects to a 100M broadband line, after testing many times, I found that, when first time to view my website, it needed to take almost 5~8 seconds to completely open the homepage which is only a static HTML file with content "coming soon", and there are some  error log about TCP connection found on our web server, it seems that my FreeBSD 7.0 web server has problem to establish TCP connection. Before the web server idle time (30s), there are no any delay to re-view the homepage (Press F5), but after 30 seconds, it needed to take another 5~8 seconds to re-view, and the log messages will be repeated.
 
May 15 15:18:21 mail kernel: TCP: [203.186.95.8]:12728 to [58.177.222.113]:80 tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK
May 15 15:19:03 mail kernel: TCP: [221.127.88.188]:5128 to [58.177.222.113]:80 tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK
 
I know how to disable these log messages, but I would like to know that the delay is because
of receiving duplicate SYN? is it normal message? Please help me to solve the problem, thanks !!!!
Thank you so much!
 
Best regards,
Victor
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
On Monday 12 May 2008 03:45:16 am John wrote:
> >Number:         123603
> >Category:       amd64
> >Synopsis:       tcp_do_segment and Received duplicate SYN
> >Confidential:   no
> >Severity:       critical
> >Priority:       high
> >Responsible:    freebsd-amd64
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Mon May 12 07:50:01 UTC 2008
> >Closed-Date:
> >Last-Modified:
> >Originator:     John
> >Release:        FB7.0 (x64)
> >Organization:
>
> NULL
>
> >Environment:
>
> FreeBSD mail.mydomain.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Thu Mar  6
> 12:04:57 HKT 2008     root@mydomain.com:/usr/src/sys/amd64/compile/FB7NEW
> amd64
>
> >Description:
>
> A FreeBSD 7.0 (x64) Lighttpd Web Server with most-updated ports and patchs.
> when a client connect and view a static HTML file, At the first time
> (before web server idle time), it needs to wait a long time to establish a
> connection, OR when this server try to download file from Internet, there
> are lots of logs messages just like below:
>
> May 12 11:57:54 mail kernel: TCP: [55.66.77.88]:41792 to [11.22.33.44]:80
> tcpflags 0x2<SYN>; syncache_add: Received duplicate SYN, resetting timer
> and retransmitting SYN|ACK
> May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:45979 to
> [11.22.33.44]:63372 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_1:
> Received 1448 bytes of data after socket was closed, sending RST and
> removing tcpcb May 12 15:17:53 mail kernel: TCP: [193.166.3.2]:21 to
> [11.22.33.44]:55007 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2:
> Received 13 bytes of data after socket was closed, sending RST and removing
> tcpcb
>
> >How-To-Repeat:
>
> any type of  connection will generate above log messages.

You can either comment out all the log(LOG_DEBUG, ...) calls
in /sys/netinet/tcp*.c or change your /etc/syslog.conf to not send kern.debug
messages to the console.

I think these messages should probably be conditional on a kernel option FWIW.

--
John Baldwin ------=_Part_11255_10246163.1211463094510-- From julian at elischer.org Thu May 22 17:19:50 2008 From: julian at elischer.org (Julian Elischer) Date: Thu May 22 17:19:56 2008 Subject: ipfw fwd layer2/ftp proxy In-Reply-To: <483522F3.4090200@micom.mng.net> References: <483522F3.4090200@micom.mng.net> Message-ID: <4835AB38.40100@elischer.org> Ganbold wrote: > Hi there, > > I'm having trouble allowing ftp connections through ipfw (default deny) > enabled bridge firewall. > I'm wondering whether it is possible to have some kind of transparent > ftp proxy in such case. > > Is there anyway I can allow ftp proxying without layer2 forwarding on > ipfw bridge? > > I thought of forwarding packets in layer2, however it seems like ipfw > still doesn't support that. > I saw old patches of luigi@ and if somebody already has adapted that > patch for RELENG_6/7 please let me know. I have such patches for the old 'bridge' code that allow bridges to intercept IP sessions but not for the new 'if_bridge' code. The trick is to make a 'fwd localhost' on the Layer2 ipfw pass to result in the packet being passed to the IP stack regardless of where the header says it should go. In the IP stack a similar 'fwd localhost' rule (maybe the same one) will also trigger on the Layer 3 pass, and actually cause teh session to connect. For fully transparent (in both directions) you need to alter the IP code to allow you to bind the outgoing socket to a non-local address, and to capture the return packets you leed the L2 pirewall pass to do a test for 'uid' which has the side affect of noticing whether or not there is a local socket that matches a packet, even if it has a non local address on it. > > I know my last try is to deny everything I don't want and then allow the > rest. However I would > like to make it work in current configuration. > Please let me know your ideas. > > thanks in advance, > > Ganbold > From ganbold at micom.mng.net Fri May 23 03:05:39 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri May 23 03:05:44 2008 Subject: ipfw fwd layer2/ftp proxy In-Reply-To: <4835AB38.40100@elischer.org> References: <483522F3.4090200@micom.mng.net> <4835AB38.40100@elischer.org> Message-ID: <4836347B.9050808@micom.mng.net> Julian Elischer wrote: > Ganbold wrote: >> Hi there, >> >> I'm having trouble allowing ftp connections through ipfw (default >> deny) enabled bridge firewall. >> I'm wondering whether it is possible to have some kind of transparent >> ftp proxy in such case. >> >> Is there anyway I can allow ftp proxying without layer2 forwarding on >> ipfw bridge? >> >> I thought of forwarding packets in layer2, however it seems like ipfw >> still doesn't support that. >> I saw old patches of luigi@ and if somebody already has adapted that >> patch for RELENG_6/7 please let me know. > > > I have such patches for the old 'bridge' code that allow bridges to > intercept IP sessions but not for the new 'if_bridge' code. > The trick is to make a 'fwd localhost' on the Layer2 ipfw pass > to result in the packet being passed to the IP stack regardless > of where the header says it should go. > > In the IP stack a similar 'fwd localhost' rule (maybe the same one) > will also trigger on the Layer 3 pass, and actually cause teh session > to connect. > > For fully transparent (in both directions) you need to alter the IP > code to allow you to bind the outgoing socket to a non-local address, > and to capture the return packets you leed the L2 pirewall pass to > do a test for 'uid' which has the side affect of noticing whether or > not there is a local socket that matches a packet, even if it has > a non local address on it. Can you share your patch for old bride code? Yesterday I tried to look at ip_fw2.c and ip_input.c codes, but it is still new to me. thanks, Ganbold > > > >> >> I know my last try is to deny everything I don't want and then allow >> the rest. However I would >> like to make it work in current configuration. >> Please let me know your ideas. >> >> thanks in advance, >> >> Ganbold >> > > _______________________________________________ > 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" > > > -- Your fault - core dumped From mutex at unixtech.info Fri May 23 06:50:24 2008 From: mutex at unixtech.info (mutex@unixtech.info) Date: Fri May 23 06:50:28 2008 Subject: Atheros 5212 network issues. Message-ID: <52090.74.56.88.177.1211525413.squirrel@webmail.unixtech.info> Hello! I am running FreeBSD 7.0 stable. I am having speed issues that I was not experiencing before when I was running 6.3 stable. My wireless connection is now unstable and not as much consistent as it was before. The wired connection is as usual ~7000kb/up and 800kb/down. Each test (~20 per day during 5 days) I did was on a 10 second interval, speed is fluctuating from ~80kb to ~4000kb down and ~80kb to ~300kb up and some tests return both download and upload to be very low. Also, one test can return 300kb down and 80kb up when next one 10 seconds later returns 80kb down and 300kb up. Latency is fluctuating as well. I tried to use another channel, swap disk and wireless card to another machine, cvsup and upgrade again. I didn't changed network settings, firewall rules, and my hostapd config. Here are some more informations on my hardware: FreeBSD 7.0-STABLE #0: Mon May 19 23:10:53 EDT 2008 mutex@xxxxxxx:/usr/obj/usr/src/sys/MUTEX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 Features=0x3febfbff real memory = 805240832 (767 MB) avail memory = 774049792 (738 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) 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 0x4008-0x400b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x40bf on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xe0000000-0xe0ffffff,0xd8000000-0xdfffffff irq 16 at device 0.0 on pci1 uhci0: port 0xd800-0xd81f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe4000000-0xe40003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 fxp0: port 0xc000-0xc03f mem 0xe3050000-0xe3050fff,0xe3020000-0xe303ffff irq 18 at device 0.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:b6:af:59 fxp0: [ITHREAD] ath0: mem 0xe3040000-0xe304ffff irq 21 at device 1.0 on pci2 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:a5:0d:c0:91 ath0: mac 10.5 phy 6.1 radio 6.3 fxp1: port 0xc400-0xc43f mem 0xe3052000-0xe3052fff,0xe3000000-0xe301ffff irq 22 at device 2.0 on pci2 miibus1: on fxp1 inphy1: PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:02:b3:b6:af:09 fxp1: [ITHREAD] vr0: port 0xc800-0xc8ff mem 0xe3051000-0xe30510ff irq 16 at device 3.0 on pci2 vr0: Quirks: 0x0 vr0: Revision: 0x43 miibus2: on vr0 ukphy0: PHY 8 on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:50:ba:18:ff:5f vr0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcc7ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1716911056 Hz quality 800 Timecounters tick every 1.000 msec ad1: 19073MB at ata0-slave UDMA100 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad1s1a pciconf -lv | grep ath ath0@pci0:2:1:0: class=0x020000 card=0x000c17f9 chip=0x001b168c rev=0x01 hdr=0x00 athstats 36879 data frames received 50372 data frames transmit 135 tx frames with an alternate rate 3508 long on-chip tx retries 286 tx failed 'cuz too many retries 18M current transmit rate 1496 tx management frames 949 tx frames discarded prior to association 7427 tx frames with no ack marked 42411 tx frames with short preamble 76570 rx failed 'cuz of bad CRC 1980968 rx failed 'cuz of PHY err 1762216 OFDM timing 3 OFDM restart 218713 CCK timing 36 CCK restart 117021 beacons transmitted 420 periodic calibrations 55 rssi of last ack 29 avg recv rssi -96 rx noise floor 164 switched default/rx antenna Antenna profile: [1] tx 25569 rx 36157 [2] tx 24598 rx 36925 ifconfig: ath0: flags=8843 metric 0 mtu 2290 ether 00:14:a5:0d:c0:91 inet 10.0.3.1 netmask 0xffffff00 broadcast 10.0.3.255 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid mutex channel 1 (2412 Mhz 11g) bssid 00:14:a5:0d:c0:91 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 sysctl: net.wlan.0.%parent: ath0 debug.disablefullpath: 0 hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.ath.hal.version: 0.9.20.3 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: dev.npx.0.%desc: math processor dev.ath.0.%desc: Atheros 5212 dev.ath.0.%driver: ath dev.ath.0.%location: slot=1 function=0 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x17f9 subdevice=0x000c cl ass=0x020000 dev.ath.0.%parent: pci2 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 16 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 2 dev.ath.0.diversity: 0 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.fftxqmin: 2 dev.ath.0.fftxqmax: 50 dev.ath.0.monpass: 24 /etc/sysctl.conf *I didn't changed any other sysctl option* net.inet.ip.forwarding=1 Lines added to Generic kernel: # PF device pf device pflog device pfsync # ALTQ options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build Please help me troubleshoot and resolve this issue. Regards, Mutex. pub 4096R/C4CE4832 2007-02-01 Key fingerprint = 8DAE C29D 44B7 CA85 28A3 AF0A BE37 B1E2 C4CE 4832 From nike_d at cytexbg.com Fri May 23 07:43:07 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Fri May 23 07:43:11 2008 Subject: lagg0.2 style vlans on lagg(4) interface In-Reply-To: <48356A4D.2050404@FreeBSD.org> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212332.13993.max@love2party.net> <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> <200805220041.24096.max@love2party.net> <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com> <48356A4D.2050404@FreeBSD.org> Message-ID: <2e77fc10805230043x2d6d2d9dp69ce9543209ad4e5@mail.gmail.com> On Thu, May 22, 2008 at 3:42 PM, Bruce M. Simpson wrote: > Hi, > > It looks like this patch will cause gratuitous ARP to be queued even when > the interface is not IFF_UP, is this intentional? > > Niki Denev wrote: >> >> I think arp_gratuit() needs a better name. >> > > arp_announce() ? > >> Is if_ethersubr.c:ether_ifattach() good place to register the EVENT hook? >> > > ARP is also used by FDDI and IEEE 802.5, as well as anything which emulates > this. Taking the call to arp_ifinit() out of if_setlladdr() is likely to > break this code. > >> And if yes, what would be the best way to handle failure to register >> the hook, as the function is void? >> Should I worry about that, or just print a warning message and continue? >> > > I see the C++-style comments - perhaps someone who knows event handlers > better than I can comment, I believe it's using one of the shared kernel > malloc pools with M_WAIT. > > It looks like this won't run afoul of locking, but it is a change to a > fairly central path which needs to be considered carefully as it affects > consumers other than Ethernet drivers. > > cheers > BMS > > Well, yes, this change will have side effects... My initial problem was that vlan interfaces link layer address is not updated when the parents link layer address is changed, for example when adding the first member in a link aggregation lagg(4) interface. This patch seems to fix this for me : diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if.c /usr/src/sys/net/if.c --- /usr/src/.zfs/snapshot/orig/sys/net/if.c 2008-04-29 23:43:08.000000000 +0300 +++ /usr/src/sys/net/if.c 2008-05-22 17:15:15.681205282 +0300 @@ -2636,6 +2636,7 @@ (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); IFF_UNLOCKGIANT(ifp); } + EVENTHANDLER_INVOKE(ifaddr_event, ifp); #ifdef INET /* * Also send gratuitous ARPs to notify other nodes about @@ -2646,6 +2647,8 @@ arp_ifinit(ifp, ifa); } #endif + } else { + EVENTHANDLER_INVOKE(ifaddr_event, ifp); } return (0); } diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_lagg.c /usr/src/sys/net/if_lagg.c --- /usr/src/.zfs/snapshot/orig/sys/net/if_lagg.c 2008-04-19 14:45:20.055330961 +0300 +++ /usr/src/sys/net/if_lagg.c 2008-05-23 09:51:22.911830591 +0300 @@ -303,6 +303,7 @@ /* Let the protocol know the MAC has changed */ if (sc->sc_lladdr != NULL) (*sc->sc_lladdr)(sc); + EVENTHANDLER_INVOKE(ifaddr_event, ifp); } static void @@ -364,6 +365,7 @@ /* Update the lladdr even if pending, it may have changed */ llq->llq_ifp = ifp; bcopy(lladdr, llq->llq_lladdr, ETHER_ADDR_LEN); + EVENTHANDLER_INVOKE(ifaddr_event, ifp); if (!pending) SLIST_INSERT_HEAD(&sc->sc_llq_head, llq, llq_entries); diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c /usr/src/sys/net/if_vlan.c --- /usr/src/.zfs/snapshot/orig/sys/net/if_vlan.c 2007-10-28 18:24:16.000000000 +0200 +++ /usr/src/sys/net/if_vlan.c 2008-05-22 17:32:40.849337824 +0300 @@ -137,6 +137,7 @@ static MALLOC_DEFINE(M_VLAN, VLANNAME, "802.1Q Virtual LAN Interface"); static eventhandler_tag ifdetach_tag; +static eventhandler_tag ifaddr_tag; /* * We have a global mutex, that is used to serialize configuration @@ -190,6 +191,7 @@ static void vlan_link_state(struct ifnet *ifp, int link); static void vlan_capabilities(struct ifvlan *ifv); static void vlan_trunk_capabilities(struct ifnet *ifp); +static int vlan_lladdr_update(void *arg, struct ifnet *ifp); static struct ifnet *vlan_clone_match_ethertag(struct if_clone *, const char *, int *); @@ -528,6 +530,10 @@ vlan_ifdetach, NULL, EVENTHANDLER_PRI_ANY); if (ifdetach_tag == NULL) return (ENOMEM); + ifaddr_tag = EVENTHANDLER_REGISTER(ifaddr_event, vlan_lladdr_update, + NULL, EVENTHANDLER_PRI_ANY); + if (ifaddr_tag == NULL) + return (ENOMEM); VLAN_LOCK_INIT(); vlan_input_p = vlan_input; vlan_link_state_p = vlan_link_state; @@ -546,6 +552,7 @@ case MOD_UNLOAD: if_clone_detach(&vlan_cloner); EVENTHANDLER_DEREGISTER(ifnet_departure_event, ifdetach_tag); + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_tag); vlan_input_p = NULL; vlan_link_state_p = NULL; vlan_trunk_cap_p = NULL; @@ -1280,6 +1287,35 @@ TRUNK_UNLOCK(trunk); } +/* + * Update vlan interface link layer address on + * parent interface link layer address change. + */ +static int +vlan_lladdr_update(void *arg __unused, struct ifnet *ifp) +{ + struct ifvlantrunk *trunk = ifp->if_vlantrunk; + struct ifvlan *ifv; + int i; + + if (trunk) { + TRUNK_LOCK(trunk); +#ifdef VLAN_ARRAY + for (i=0; i < VLAN_ARRAY_SIZE; i++) + if (trunk->vlans[i] != NULL) { + ifv = trunk->vlans[i]; +#else + for (i=0; i < (1 << trunk->hwidth); i++) { + LIST_FOREACH(ifv, &trunk->hash[i], ifv_list) +#endif + bcopy(IF_LLADDR(ifp), IF_LLADDR(ifv->ifv_ifp), + ETHER_ADDR_LEN); + } + TRUNK_UNLOCK(trunk); + } + return (0); +} + static int vlan_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) { I have left the gratuitious arp sending alone in this one, also I wonder if there is a need for another kernel event like iflladdr_event? Another problem is that many drivers handle things internally by making bcopy's or memcpy's of the lladdr and not generating events, which probably should be done by some function. Niki From juri_mian at yahoo.com Fri May 23 10:00:16 2008 From: juri_mian at yahoo.com (Juri Mianovich) Date: Fri May 23 10:00:24 2008 Subject: minimum bandwidth per connection with dummynet ? Message-ID: <321306.67555.qm@web45605.mail.sp1.yahoo.com> I have two simple dummynet rules in place (with ipfw): - one pipe limits inbound - one pipe limits outbound However, if there are multiple connections taking place, all over fast links, the pipe gets saturated. This is not so bad, but I am not convinced it is allocating bandwidth fairly between all participants during saturation. Two questions: - is there a simple setting that says "allocate bandwidth evenly between all connections in a saturated pipe" ? - alternatively, is there a minimum speed per connection that I can establish for a dummynet pipe ? Presumably actual performance would drop below the minimum if the product of connections * minimum was less than the total bandwidth of the pipe, but as long as that wasn't true, everyone would at least get reasonable speed, instead of one client eating the pipe and everyone else trickling along... Thanks. From lev at serebryakov.spb.ru Fri May 23 18:10:07 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Fri May 23 18:10:09 2008 Subject: kern/121298: [em] [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) Message-ID: <200805231810.m4NIA69U061540@freefall.freebsd.org> The following reply was made to PR kern/121298; it has been noted by GNATS. From: Lev Serebryakov To: bug-followup@FreeBSD.org, admin@aknet.ru Cc: Subject: Re: kern/121298: [em] [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) Date: Fri, 23 May 2008 21:47:41 +0400 Hello, bug-followup. I've got very similar panic. `csup' from local (located in same segment) cvsup server via gigabit link and RAID5 (geom_raid5) synchronize newely-created array with 4 disks. csup writes on OTHER disk, not included in array. No crashdump, because core was not saved: machine hangs up right after panic message, without attempts to save dump or reboot. Crash dumps are enabled and I got previous one (other bug), but in this case no dumps, no reaction on keyboards, etc. Need to reboot with pwoer switch :( ==================== panic message, typed by hands em0: watchdog timeout -- resetting kernel trap 12 with interrupts disabled Fatal trap 12: page fault in kernnel mode cpuid = 1; apic id = 01 fault virtual addewaa = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80282c2f stack pointer = 0x10:0xffffffffabed4b20 frame pointer = 0x10:0xffffff00010c9000 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor efalgs = resume, IOPL = 1 current process = 23 (em0 taskq) trap number = 12 panic: page fault cpuid = 1 ==================== panic message, typed by hands ========================================= uname -a FreeBSD blob.home.serebryakov.spb.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon May 19 21:26:08 MSD 2008 lev@blob.home.serebryakov.spb.ru:/usr/obj/usr/src/sys/BLOB amd64 ========================================= uname -a ============================================ dmesg Copyright (c) 1992-2008 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 7.0-STABLE #0: Mon May 19 21:26:08 MSD 2008 lev@blob.home.serebryakov.spb.ru:/usr/obj/usr/src/sys/BLOB Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2200.09-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 6364114944 (6069 MB) avail memory = 6141857792 (5857 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfd00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 51, should be 4C [20070320] coretemp0: on cpu0 est0: on cpu0 est0: Setting 2200 MHz p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est1: Setting 2200 MHz p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xec00-0xec07 mem 0xfea80000-0xfeafffff,0xd0000000-0xdfffffff,0xfe900000-0xfe9fffff irq 16 at device 2.0 on pci0 pci0: at device 3.0 (no driver attached) em0: port 0xe880-0xe89f mem 0xfea40000-0xfea5ffff,0xfea7a000-0xfea7afff irq 20 at device 25.0 on pci0 em0: [FILTER] em0: Ethernet address: 00:1e:8c:75:03:0d uhci0: port 0xe400-0xe41f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe480-0xe49f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe800-0xe81f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfea7b800-0xfea7bbff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhci3: port 0xdc00-0xdc1f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe000-0xe01f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe080-0xe09f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfea7b400-0xfea7b7ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci1: on pcib1 fwohci0: mem 0xfebff000-0xfebfffff irq 20 at device 2.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:1e:8c:00:00:1a:5f:da fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd01f mem 0xfea79800-0xfea79fff irq 22 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.20 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ichsmb0: port 0x400-0x41f mem 0xfea7b000-0xfea7b0ff irq 18 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xcb800-0xcc7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ZFS filesystem version 6 ZFS storage pool version 6 ad4: 305245MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 ad10: 476940MB at ata5-master SATA300 ad12: 476940MB at ata6-master SATA300 ad14: 476940MB at ata7-master SATA300 SMP: AP CPU #1 Launched! GEOM_RAID5: storage: device created (stripesize=131072). GEOM_RAID5: storage: ad6(0): newest disk data (CALM): 0. GEOM_RAID5: storage: ad6(0): disk attached. GEOM_RAID5: storage: ad10(1): newest disk data (CALM): 1. GEOM_RAID5: storage: ad10(1): disk attached. GEOM_RAID5: storage: ad12(2): newest disk data (CALM): 2. GEOM_RAID5: storage: ad12(2): disk attached. GEOM_RAID5: storage: ad14(3): newest disk data (CALM): 3. GEOM_RAID5: storage: ad14(3): disk attached. GEOM_RAID5: storage: activated (need about 76MiB kmem (max)). Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 4 files 1 ============================================ dmesg ==================================== kernel config cpu HAMMER ident BLOB makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq device coretemp device smb device smbus device ichsmb device iicbus device iicsmb device iic # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) # FireWire support device firewire # FireWire bus code ==================================== kernel config -- // Black Lion AKA Lev Serebryakov From peterjeremy at optushome.com.au Fri May 23 22:13:10 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri May 23 22:13:14 2008 Subject: minimum bandwidth per connection with dummynet ? In-Reply-To: <321306.67555.qm@web45605.mail.sp1.yahoo.com> References: <321306.67555.qm@web45605.mail.sp1.yahoo.com> Message-ID: <20080523221306.GY1469@server.vk2pj.dyndns.org> On 2008-May-23 02:47:30 -0700, Juri Mianovich wrote: >- is there a simple setting that says "allocate >bandwidth evenly between all connections in a >saturated pipe" ? TCP does this automatically. >- alternatively, is there a minimum speed per >connection that I can establish for a dummynet pipe ? Not that I can see - you can use the 'mask' parameter to define a maximum per-connection rate. I don't believe there's any way to redirect "overflow" traffic though. You could probably write a divert(4) application to do the shaping you require. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080523/3e4dbd83/attachment.pgp From vwe at FreeBSD.org Fri May 23 23:19:45 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri May 23 23:19:47 2008 Subject: kern/123892: [tap] [patch] No buffer space available Message-ID: <200805232319.m4NNJjNW089121@freefall.freebsd.org> Synopsis: [tap] [patch] No buffer space available Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Fri May 23 23:19:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123892 From julian at elischer.org Sat May 24 00:39:13 2008 From: julian at elischer.org (Julian Elischer) Date: Sat May 24 00:39:22 2008 Subject: anyone tried the Multi routing table code yet? Message-ID: <483763B5.4030205@elischer.org> subject says it all really.. From alex.wilkinson at dsto.defence.gov.au Sat May 24 00:57:51 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Sat May 24 00:57:54 2008 Subject: anyone tried the Multi routing table code yet? In-Reply-To: <483763B5.4030205@elischer.org> References: <483763B5.4030205@elischer.org> Message-ID: <20080524005108.GA51044@stlux503.dsto.defence.gov.au> 0n Fri, May 23, 2008 at 05:39:17PM -0700, Julian Elischer wrote: >subject says it all really.. No, but I would like to ... if you could hold my hand :) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From linimon at FreeBSD.org Sat May 24 02:09:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 24 02:09:37 2008 Subject: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections Message-ID: <200805240209.m4O29YcU002017@freefall.freebsd.org> Old Synopsis: Turning on TCP blackholing causes slow localhost connections New Synopsis: [tcp] Turning on TCP blackholing causes slow localhost connections Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 24 02:09:06 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123881 From neil at hoggarth.me.uk Sat May 24 07:35:28 2008 From: neil at hoggarth.me.uk (Neil Hoggarth) Date: Sat May 24 07:35:31 2008 Subject: [em][panic] recursed on non-recursive mutex em0 In-Reply-To: <2a41acea0805211352s37e6fd40maaaac90e51912947@mail.gmail.com> References: <2a41acea0805211326v74baa017tc03fcd329a764ef5@mail.gmail.com> <2a41acea0805211352s37e6fd40maaaac90e51912947@mail.gmail.com> Message-ID: On Wed, 21 May 2008, Jack Vogel wrote: >>> I opened PR kern/122928 last month, describing my problems with Intel > > OPPS, I think I found the problem, look for a delta on if_em.c shortly. > > Let me know if this fixes your problem. Thanks. I picked up delta 1.184.2.3 to if_em.c on Thursday morning. The system no longer panics on watchdog timeout, but the original problem from PR kern/122928 remains - once a watchdog timeout occurs the interface no longer seems to receive packets and never properly recovers, short of rebooting the system (or perhaps the watchdog timeout is actually a symptom of whatever has "got stuck", rather than a cause?). The PR is still in "feedback" state, but I think I've provided the requested information. Is there anything else that I can do to help progress this? Regards, Neil. From neil at hoggarth.me.uk Sat May 24 08:40:02 2008 From: neil at hoggarth.me.uk (Neil Hoggarth) Date: Sat May 24 08:40:05 2008 Subject: kern/122928: [em] interface watchdog timeouts and stops receiving packets Message-ID: <200805240840.m4O8e2Xe062968@freefall.freebsd.org> The following reply was made to PR kern/122928; it has been noted by GNATS. From: Neil Hoggarth To: bug-followup@FreeBSD.org Cc: Subject: kern/122928: [em] interface watchdog timeouts and stops receiving packets Date: Sat, 24 May 2008 09:31:10 +0100 (BST) For the record, the problem persists following the recent MFC of the em driver and locking fix in delta 1.184.2.3 of if_em.c. ifconfig em0: em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0e:0c:06:c2:3a inet 10.0.0.7 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseTX ) status: active sysctl dev.em: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 dev.em.0.%driver: em dev.em.0.%location: slot=9 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x100e subvendor=0x8086 subdevice=0x002e class=0x020000 dev.em.0.%parent: pci2 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 From rwatson at FreeBSD.org Sat May 24 10:21:00 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 10:21:14 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) Message-ID: <20080524111715.T64552@fledge.watson.org> Dear all: Just as a reminder, we've just about reached the one month date before IFF_NEEDSGIANT drivers are disabled in the build. You can find a description of the general problem and list of specific drivers below. As USB work is on-going, I will *not* disable the USB drivers at this time, but all other drivers in the list below will be disabled on 26 June. They will remain in the tree, easily accessible for patch distribution and re-enabling, until October, when any remaining non-MPSAFE drivers will be deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to support non-MPSAFE network device drivers. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) From: Robert Watson To: arch@FreeBSD.org Subject: 8.0 network stack MPsafety goals (fwd) Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT network drivers are going to stop working in the forseeable future. Please review the attached driver list, and if you depend on or care about a Giant-dependent device driver, take action to make sure it doesn't remain on the list in a month's time! (As far as I'm aware, the list has not changed since my December posting.) Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) From: Robert Watson To: arch@FreeBSD.org Subject: 8.0 network stack MPsafety goals Dear all: With the 7.0 release around the corner, many developers are starting to think about (and in quite a few cases, work on) their goals for 8.0. One of our on-going kernel projects has been the elimination of the Giant lock, and that project has transformed into one of optimizating behavior on increasing numbers of processors. In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet and conditional network stack Gian acquisition, we were unable to fully eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition of the Giant lock around non-MPSAFE network device drivers. Primarily these drivers are aging ISA network device drivers, although there are some exceptions, such as the USB stack. This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and associated infrastructure in FreeBSD 8.0, meaning that all network device drivers must be able to operate without the Giant lock (largely the case already). Remaining drivers using the IFF_NEEDSGIANT flag must either be updated, or less ideally, removed. I propose the following schedule: Date Goals ---- ----- 26 Dec 2007 Post proposed schedule for flag and infrastructure removal Post affected driver list 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal Post updated affected driver list 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud warning. Post updated affected driver list 26 May 2008 Post HEADS UP of impending driver disabling Post updated affected driver list 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT Post updated affected driver list 26 Sep 2008 Post HEADS up of impending driver removal Post updated affected driver list 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT Remove flag and infrastructure Here is a list of potentially affected drivers: Name Bus Man page description --- --- -------------------- ar ISA/PCI synchronous Digi/Arnet device driver arl ISA Aironet Arlan 655 wireless network adapter driver awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network driver axe USB ASIX Electronics AX88172 USB Ethernet driver cdce USB USB Communication Device Class Ethernet driver cnw PCCARD Netwave AirSurfer wireless network driver cs ISA/PCCARD Ethernet device driver cue USB CATC USB-EL1210A USB Ethernet driver ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress Pro/10 and Pro/10+ fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters ic I2C I2C bus system ie ISA Ethernet device driver kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver oltr ISA/PCI Olicom Token Ring device driver plip PPBUS printer port Internet Protocol driver ppp TTY point to point protocol network interface ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver rue USB RealTek RTL8150 USB to Fast Ethernet controller driver rum USB Ralink Technology USB IEEE 802.11a/b/g wireless network device sbni ISA/PCI Granch SBNI12 leased line modem driver sbsh PCI Granch SBNI16 SHDSL modem device driver sl TTY slip network interface snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter driver sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver udav USB Davicom DM9601 USB Ethernet driver ural USB Ralink Technology RT2500USB IEEE 802.11 driver xe PCCARD Xircom PCMCIA Ethernet device driver zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device In some cases, the requirement for Giant is a property of a subsystem the driver depends on as the driver itself; for example, the tty subsystem for SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless drivers. With most of a year before to go on the proposed schedule, my hope is that we will have lots of time to address these issues, but wanted to get a roadmap out from a network protocol stack architecture perspective so that device driver and subsystem authors could have a schedule in mind. FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order to provide their own conditional MPSAFEty, which can be removed without affecting device driver functionality (I believe): Name Bus Man page description --- --- -------------------- ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters ctau ISA driver for synchronous Cronyx Tau WAN adapters cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN adapters Developers and users of the above drivers are heavily encouraged to update the drivers to remove dependence on Giant, and/or make other contingency plans. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From daniel at skytek.it Sat May 24 13:27:41 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sat May 24 13:27:49 2008 Subject: lagg interfaces on 6.3-Stable Message-ID: <483814C9.10301@skytek.it> Hello, i have configured lagg interface on two Broacom (bce0 bce1). I have tried with laggproto lacp (supported by the Nortel switch), with fce and failover, but they all shows the same symptom: Everything works fine until i unplug the cable of the first interface (bce0), it will show status: no carrier even on lagg0 interface, while bce0 shows no carrier (correct) and bce1 is active. Any ideas? Thanks! Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From linimon at FreeBSD.org Sat May 24 15:39:53 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 24 15:39:56 2008 Subject: kern/123950: [tcp] TH_RST packet sended if received out-of-order data (ACK) in SYN_RECEIVED state Message-ID: <200805241539.m4OFdqbD002226@freefall.freebsd.org> Old Synopsis: TH_RST packet sended if received out-of-order data (ACK) in SYN_RECEIVED state New Synopsis: [tcp] TH_RST packet sended if received out-of-order data (ACK) in SYN_RECEIVED state Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 24 15:39:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123950 From cokane at FreeBSD.org Sat May 24 15:49:28 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sat May 24 15:49:33 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524111715.T64552@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> Message-ID: <1211640498.1510.8.camel@localhost> On Sat, 2008-05-24 at 11:20 +0100, Robert Watson wrote: > Dear all: > > Just as a reminder, we've just about reached the one month date before > IFF_NEEDSGIANT drivers are disabled in the build. You can find a description > of the general problem and list of specific drivers below. > > As USB work is on-going, I will *not* disable the USB drivers at this time, > but all other drivers in the list below will be disabled on 26 June. They > will remain in the tree, easily accessible for patch distribution and > re-enabling, until October, when any remaining non-MPSAFE drivers will be > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to support > non-MPSAFE network device drivers. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals (fwd) > > > Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT network > drivers are going to stop working in the forseeable future. Please review the > attached driver list, and if you depend on or care about a Giant-dependent > device driver, take action to make sure it doesn't remain on the list in a > month's time! > > (As far as I'm aware, the list has not changed since my December posting.) > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals > > > Dear all: > > With the 7.0 release around the corner, many developers are starting to think > about (and in quite a few cases, work on) their goals for 8.0. One of our > on-going kernel projects has been the elimination of the Giant lock, and that > project has transformed into one of optimizating behavior on increasing numbers > of processors. > > In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet > and conditional network stack Gian acquisition, we were unable to fully > eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition > of the Giant lock around non-MPSAFE network device drivers. Primarily these > drivers are aging ISA network device drivers, although there are some > exceptions, such as the USB stack. > > This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and associated > infrastructure in FreeBSD 8.0, meaning that all network device drivers must be > able to operate without the Giant lock (largely the case already). Remaining > drivers using the IFF_NEEDSGIANT flag must either be updated, or less ideally, > removed. I propose the following schedule: > > Date Goals > ---- ----- > 26 Dec 2007 Post proposed schedule for flag and infrastructure removal > Post affected driver list > > 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal > Post updated affected driver list > > 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud > warning. > Post updated affected driver list > > 26 May 2008 Post HEADS UP of impending driver disabling > Post updated affected driver list > > 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT > Post updated affected driver list > > 26 Sep 2008 Post HEADS up of impending driver removal > Post updated affected driver list > > 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT > Remove flag and infrastructure > > Here is a list of potentially affected drivers: > > Name Bus Man page description > --- --- -------------------- > ar ISA/PCI synchronous Digi/Arnet device driver > arl ISA Aironet Arlan 655 wireless network adapter driver > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network > driver > axe USB ASIX Electronics AX88172 USB Ethernet driver > cdce USB USB Communication Device Class Ethernet driver > cnw PCCARD Netwave AirSurfer wireless network driver > cs ISA/PCCARD Ethernet device driver > cue USB CATC USB-EL1210A USB Ethernet driver > ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress > Pro/10 and Pro/10+ > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters > ic I2C I2C bus system > ie ISA Ethernet device driver > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver > oltr ISA/PCI Olicom Token Ring device driver > plip PPBUS printer port Internet Protocol driver > ppp TTY point to point protocol network interface > ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver > rue USB RealTek RTL8150 USB to Fast Ethernet controller driver > rum USB Ralink Technology USB IEEE 802.11a/b/g wireless > network device > sbni ISA/PCI Granch SBNI12 leased line modem driver > sbsh PCI Granch SBNI16 SHDSL modem device driver > sl TTY slip network interface > snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter > driver > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver > udav USB Davicom DM9601 USB Ethernet driver > ural USB Ralink Technology RT2500USB IEEE 802.11 driver > xe PCCARD Xircom PCMCIA Ethernet device driver > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless > network device > > In some cases, the requirement for Giant is a property of a subsystem the > driver depends on as the driver itself; for example, the tty subsystem for SLIP > and PPP, and the USB subsystem for a number of USB ethernet and wireless > drivers. With most of a year before to go on the proposed schedule, my hope is > that we will have lots of time to address these issues, but wanted to get a > roadmap out from a network protocol stack architecture perspective so that > device driver and subsystem authors could have a schedule in mind. > > FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order to > provide their own conditional MPSAFEty, which can be removed without affecting > device driver functionality (I believe): > > Name Bus Man page description > --- --- -------------------- > ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters > cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters > ctau ISA driver for synchronous Cronyx Tau WAN adapters > cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN > adapters > > Developers and users of the above drivers are heavily encouraged to update the > drivers to remove dependence on Giant, and/or make other contingency plans. > > Robert N M Watson > Computer Laboratory > University of Cambridge I've created a quick table of these at the following location: http://wiki.freebsd.org/NetworkNeedsGiant Please everyone feel free to fill in the blanks. I'll try to do it as well as time permits. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080524/b30b446f/attachment.pgp From rwatson at FreeBSD.org Sat May 24 15:56:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 15:56:25 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <1211640498.1510.8.camel@localhost> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> Message-ID: <20080524165519.K9809@fledge.watson.org> On Sat, 24 May 2008, Coleman Kane wrote: > I've created a quick table of these at the following location: > http://wiki.freebsd.org/NetworkNeedsGiant > > Please everyone feel free to fill in the blanks. I'll try to do it as well > as time permits. FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial once tty locking is in place -- a per-softc mutex and a bit of locking in the obvious spots would likely do it without too much trouble. In some paths, it might be necessary to inject data via the netisr, if that's not already being done (probably is) to avoid input/output lock order issues. Robert N M Watson Computer Laboratory University of Cambridge From sam at freebsd.org Sat May 24 16:15:35 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat May 24 16:15:47 2008 Subject: Atheros 5212 network issues. In-Reply-To: <52090.74.56.88.177.1211525413.squirrel@webmail.unixtech.info> References: <52090.74.56.88.177.1211525413.squirrel@webmail.unixtech.info> Message-ID: <48383F25.2020309@freebsd.org> mutex@unixtech.info wrote: > Hello! > I am running FreeBSD 7.0 stable. I am having speed issues that I was > not experiencing before when I was running 6.3 stable. > > My wireless connection is now unstable and not as much consistent as it > was before. The wired connection is as usual ~7000kb/up and 800kb/down. > > Each test (~20 per day during 5 days) I did was on a 10 second interval, > speed is fluctuating from ~80kb to ~4000kb down and ~80kb to ~300kb up and > some tests return both download and upload to be very low. > > Also, one test can return 300kb down and 80kb up when next one 10 seconds > later returns 80kb down and 300kb up. > > Latency is fluctuating as well. > > I tried to use another channel, swap disk and wireless card to another > machine, cvsup and upgrade again. > > I didn't changed network settings, firewall rules, and my hostapd config. > > Here are some more informations on my hardware: > > FreeBSD 7.0-STABLE #0: Mon May 19 23:10:53 EDT 2008 > mutex@xxxxxxx:/usr/obj/usr/src/sys/MUTEX > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.91-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 > Features=0x3febfbff > real memory = 805240832 (767 MB) > avail memory = 774049792 (738 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > wlan: mac acl policy registered > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > 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 0x4008-0x400b on acpi0 > cpu0: on acpi0 > p4tcc0: on cpu0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff,0x4000-0x40bf on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xe0000000-0xe0ffffff,0xd8000000-0xdfffffff irq 16 at device 0.0 on pci1 > uhci0: port 0xd800-0xd81f irq > 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xd000-0xd01f irq > 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xd400-0xd41f irq > 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xe4000000-0xe40003ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > fxp0: port 0xc000-0xc03f mem > 0xe3050000-0xe3050fff,0xe3020000-0xe303ffff irq 18 at device 0.0 on pci2 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:02:b3:b6:af:59 > fxp0: [ITHREAD] > ath0: mem 0xe3040000-0xe304ffff irq 21 at device 1.0 on pci2 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:14:a5:0d:c0:91 > ath0: mac 10.5 phy 6.1 radio 6.3 > fxp1: port 0xc400-0xc43f mem > 0xe3052000-0xe3052fff,0xe3000000-0xe301ffff irq 22 at device 2.0 on pci2 > miibus1: on fxp1 > inphy1: PHY 1 on miibus1 > inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp1: Ethernet address: 00:02:b3:b6:af:09 > fxp1: [ITHREAD] > vr0: port 0xc800-0xc8ff mem > 0xe3051000-0xe30510ff irq 16 at device 3.0 on pci2 > vr0: Quirks: 0x0 > vr0: Revision: 0x43 > miibus2: on vr0 > ukphy0: PHY 8 on miibus2 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr0: Ethernet address: 00:50:ba:18:ff:5f > vr0: [ITHREAD] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > pci0: at device 31.5 (no driver attached) > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcc7ff pnpid ORM0000 on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 1716911056 Hz quality 800 > Timecounters tick every 1.000 msec > ad1: 19073MB at ata0-slave UDMA100 > acd0: CDROM at ata1-master PIO4 > Trying to mount root from ufs:/dev/ad1s1a > > pciconf -lv | grep ath > ath0@pci0:2:1:0: class=0x020000 card=0x000c17f9 chip=0x001b168c > rev=0x01 hdr=0x00 > > athstats > 36879 data frames received > 50372 data frames transmit > 135 tx frames with an alternate rate > 3508 long on-chip tx retries > 286 tx failed 'cuz too many retries > 18M current transmit rate > 1496 tx management frames > 949 tx frames discarded prior to association > 7427 tx frames with no ack marked > 42411 tx frames with short preamble > 76570 rx failed 'cuz of bad CRC > 1980968 rx failed 'cuz of PHY err > 1762216 OFDM timing > 3 OFDM restart > 218713 CCK timing > 36 CCK restart > 117021 beacons transmitted > 420 periodic calibrations > 55 rssi of last ack > 29 avg recv rssi > -96 rx noise floor > 164 switched default/rx antenna > Antenna profile: > [1] tx 25569 rx 36157 > [2] tx 24598 rx 36925 > > ifconfig: > ath0: flags=8843 metric 0 mtu 2290 > ether 00:14:a5:0d:c0:91 > inet 10.0.3.1 netmask 0xffffff00 broadcast 10.0.3.255 > media: IEEE 802.11 Wireless Ethernet autoselect > (autoselect ) > status: associated > ssid mutex channel 1 (2412 Mhz 11g) bssid 00:14:a5:0d:c0:91 > authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit > txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 > roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 > > sysctl: > net.wlan.0.%parent: ath0 > debug.disablefullpath: 0 > hw.ath.hal.swba_backoff: 0 > hw.ath.hal.sw_brt: 10 > hw.ath.hal.dma_brt: 2 > hw.ath.hal.version: 0.9.20.3 > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.regdomain: 0 > hw.ath.countrycode: 0 > hw.ath.xchanmode: 1 > hw.ath.outdoor: 1 > hw.ath.calibrate: 30 > user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: > dev.npx.0.%desc: math processor > dev.ath.0.%desc: Atheros 5212 > dev.ath.0.%driver: ath > dev.ath.0.%location: slot=1 function=0 > dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x17f9 > subdevice=0x000c cl > ass=0x020000 > dev.ath.0.%parent: pci2 > dev.ath.0.smoothing_rate: 95 > dev.ath.0.sample_rate: 10 > dev.ath.0.countrycode: 0 > dev.ath.0.regdomain: 16 > dev.ath.0.slottime: 9 > dev.ath.0.acktimeout: 48 > dev.ath.0.ctstimeout: 48 > dev.ath.0.softled: 0 > dev.ath.0.ledpin: 0 > dev.ath.0.ledon: 0 > dev.ath.0.ledidle: 2700 > dev.ath.0.txantenna: 0 > dev.ath.0.rxantenna: 2 > dev.ath.0.diversity: 0 > dev.ath.0.txintrperiod: 5 > dev.ath.0.diag: 0 > dev.ath.0.tpscale: 0 > dev.ath.0.tpc: 0 > dev.ath.0.tpack: 63 > dev.ath.0.tpcts: 63 > dev.ath.0.fftxqmin: 2 > dev.ath.0.fftxqmax: 50 > dev.ath.0.monpass: 24 > > /etc/sysctl.conf *I didn't changed any other sysctl option* > net.inet.ip.forwarding=1 > > Lines added to Generic kernel: > > # PF > device pf > device pflog > device pfsync > > # ALTQ > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build > > > Please help me troubleshoot and resolve this issue. > > Simplify your configuration. First remove ALTQ and any packet processing in the tx/rx paths (e.g. pf). If that doesn't resolve the issues you are seeing try to isolate the problem to rx or tx by running unidirectional tests. Finally, if this is related to tx rate control then fix the tx rate to eliminate that variable. If you cannot resolve the issue please file a PR. Be sure to provide sufficient information for someone to exactly duplicate your setup. Sam From rwatson at FreeBSD.org Sat May 24 18:14:37 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 18:15:18 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <1211640498.1510.8.camel@localhost> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> Message-ID: <20080524191405.N9809@fledge.watson.org> On Sat, 24 May 2008, Coleman Kane wrote: > I've created a quick table of these at the following location: > http://wiki.freebsd.org/NetworkNeedsGiant > > Please everyone feel free to fill in the blanks. I'll try to do it as well > as time permits. You might also want to cross-link with the SMPTODO page. Robert N M Watson Computer Laboratory University of Cambridge From linimon at FreeBSD.org Sat May 24 19:52:30 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 24 19:52:37 2008 Subject: kern/123961: [vr] [patch] Allow vr interface to handle vlans Message-ID: <200805241952.m4OJqUg1026741@freefall.freebsd.org> Old Synopsis: Allow vr interface to handle vlans New Synopsis: [vr] [patch] Allow vr interface to handle vlans Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 24 19:52:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123961 From je.suis.bon at googlemail.com Sat May 24 22:40:03 2008 From: je.suis.bon at googlemail.com (Jonathan Crook) Date: Sat May 24 22:40:05 2008 Subject: kern/120966: [rum] kernel panic with if_rum and WPA encryption Message-ID: <200805242240.m4OMe36t042308@freefall.freebsd.org> The following reply was made to PR kern/120966; it has been noted by GNATS. From: Jonathan Crook To: bug-followup@FreeBSD.org, oliver@akephalos.de Cc: Subject: Re: kern/120966: [rum] kernel panic with if_rum and WPA encryption Date: Sat, 24 May 2008 23:05:12 +0100 I have encountered the same problem. Using a network device with an rt73 chipset (thus using the rum driver), and with WPA, I get a kernel panic within minutes. I have not yet tested the device without WPA. Unlike Oliver, I have an Intel ICH7 chipset. Thanks, Jonny. From peter at wemm.org Sun May 25 00:21:40 2008 From: peter at wemm.org (Peter Wemm) Date: Sun May 25 00:21:44 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524165519.K9809@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> Message-ID: On Sat, May 24, 2008 at 8:56 AM, Robert Watson wrote: > > On Sat, 24 May 2008, Coleman Kane wrote: > >> I've created a quick table of these at the following location: >> http://wiki.freebsd.org/NetworkNeedsGiant >> >> Please everyone feel free to fill in the blanks. I'll try to do it as well >> as time permits. > > FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial > once tty locking is in place -- a per-softc mutex and a bit of locking in > the obvious spots would likely do it without too much trouble. In some > paths, it might be necessary to inject data via the netisr, if that's not > already being done (probably is) to avoid input/output lock order issues. ppp_tty.c is kind of hairy and rather stale. I'd be inclined to drop strong hints about switching to either userland ppp(8), or mpd + netgraph if you want packets to stay in the kernel path and avoid userland. I was once a big user of pppd(8) and if_ppp.c / ppp_tty.c and maintained them for a while. But I use ppp(8) now and have no interest in maintaining it anymore. pppd/if_ppp.c/ppp_tty.c is many many years stale compared to what its vendor supplies. And, I think if_sl.c could probably do the same treatment. It would probably be a better investment in time to write a userland slip driver and if_tun.c and/or write a ng_slip.c module -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From rwatson at FreeBSD.org Sun May 25 09:58:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun May 25 09:59:04 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> Message-ID: <20080525105726.O39741@fledge.watson.org> On Sat, 24 May 2008, Peter Wemm wrote: >> FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial >> once tty locking is in place -- a per-softc mutex and a bit of locking in >> the obvious spots would likely do it without too much trouble. In some >> paths, it might be necessary to inject data via the netisr, if that's not >> already being done (probably is) to avoid input/output lock order issues. > > ppp_tty.c is kind of hairy and rather stale. I'd be inclined to drop strong > hints about switching to either userland ppp(8), or mpd + netgraph if you > want packets to stay in the kernel path and avoid userland. > > I was once a big user of pppd(8) and if_ppp.c / ppp_tty.c and maintained > them for a while. But I use ppp(8) now and have no interest in maintaining > it anymore. > > pppd/if_ppp.c/ppp_tty.c is many many years stale compared to what its vendor > supplies. > > And, I think if_sl.c could probably do the same treatment. It would > probably be a better investment in time to write a userland slip driver and > if_tun.c and/or write a ng_slip.c module While I'd be quite supportive of something along these lines, I think it probably is more work to port SLIP to userspace than to hack the current code a little bit to be MPSAFE, assuming it remains supported with the revised tty code. SLIP is a fairly straight-forward piece of code, as long as you don't try to understand the line discipline stuff. :-) Robert N M Watson Computer Laboratory University of Cambridge From martin.fuchs at trendchiller.com Sun May 25 10:38:00 2008 From: martin.fuchs at trendchiller.com (Fuchs, Martin) Date: Sun May 25 11:21:22 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 Message-ID: Hi ! I am in contact with Chris Buechler because of pfSense and we he told me to contact Jack Vogel because of some Intel NIC driver problem. FreeBSD detects them as fxp cards which is correct, but they do not work at all, i tried in ACPI and non-ACPI mode and with enabled ROM and disabled ROM and everything, but I cannot get them working... I always get "fxp0 timeout" or fxpX fort he corresponding card... I read it might have something to do with dynamic powersaving mode or else but have no clue how to deactivate, there's no option in the ROM for this. It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x ICH4 integrated LAN Int on board. I have attached the whitepaper with the specifications oft he board. Is there anything I can tot o make it work for now or is it a known problem or else ? Regards, looking forward to hear from you, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: ebc575_2007r1.0.pdf Type: application/octet-stream Size: 265516 bytes Desc: ebc575_2007r1.0.pdf Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080525/c9d2e426/ebc575_2007r1.0-0001.obj From rwatson at FreeBSD.org Sun May 25 23:06:34 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun May 25 23:06:39 2008 Subject: HEADS UP: netatm removed (was: Re: netatm removal warning) In-Reply-To: <20080521224350.T63482@fledge.watson.org> References: <20080310122338.T29929@fledge.watson.org> <20080521224350.T63482@fledge.watson.org> Message-ID: <20080526000329.K36357@fledge.watson.org> On Wed, 21 May 2008, Robert Watson wrote: >> 10 March 2008 E-mail warning to arch@/net@ >> 10 April 2008 E-mail warning to arch@/net@ >> 10 May 2008 Removal of netatm from HEAD >> 20 May 2008 Removal of netatm from RELENG_7 >> >> Obviously, netatm will remain in the revision control history should anyone >> wish to ressurect it after that date. However, I suspect that those >> interested in ATM on FreeBSD have long since been using Harti's netgraph >> ATM framework. > > Somehow the dates slipped pasted more quickly than I had hoped -- this is > the HEADS UP that, on a slightly delayed schedule, I will be trimming netatm > from the src tree for HEAD, and then a week or two later, from RELENG_7. > Assuming all goes well, this should result in no functional change at all. Per the long-announced schedule, netatm has now been removed from the CVS HEAD. Assuming no unexpected problems, it will likewise be removed from RELENG_7 in a few weeks. I apologize in advance if there's any build disruption; this touched a lot of Makefiles, and while netatm hasn't been connected to the build in ten months, there is always a risk of problems with a change of this scope. I'll keep an eye out for tinderbox warnings and correct as quickly as possible if any arise. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From linimon at FreeBSD.org Mon May 26 00:41:50 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 26 00:41:56 2008 Subject: kern/123968: [rum] [panic] rum driver causes kernel panic with WPA. Message-ID: <200805260041.m4Q0fnuK089939@freefall.freebsd.org> Old Synopsis: Rum driver causes kernel panic with WPA. New Synopsis: [rum] [panic] rum driver causes kernel panic with WPA. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 26 00:41:22 UTC 2008 Responsible-Changed-Why: Over to maintainer(s), although this sounds like it might not be specific to this one driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=123968 From aedwards at sandvine.com Mon May 26 01:40:37 2008 From: aedwards at sandvine.com (Andrew Edwards) Date: Mon May 26 01:40:41 2008 Subject: panic in nfsd in freebsd7-release and -stable Message-ID: <5230D3C40B842D4F9FB3CD368021BEF7020107F1@exchange-2.sandvine.com> I have a system that was running some version of redhat (I don't remember now) and I upgraded it to freebsd7 and I would get an immediate panic when nfsd is started. I then updated to 7-stable (on May 24th) and built a new kerenl and userland and the panic continued. This was happening 100% of the time whenever nfsd is started but what I later discovered was that because I had used the same IP's as the linux host there were some systems that still had a filesystem mounted from before the conversion. I put in an ipfw rule to block those hosts and then I was able to start nfsd without crashing and then create new mounts. I have been able to work-around the issue by forcing all of the servers that were mounting from the linux os to remount, I am only including this information just in case someone else runs into a similar problem. Thanks, Andrew Here's the backtrace Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06ce915 stack pointer = 0x28:0xe8f32a48 frame pointer = 0x28:0xe8f32a64 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 755 (nfsd) trap number = 12 panic: page fault cpuid = 1 Uptime: 40m22s Physical memory: 3318 MB Dumping 93 MB: 78 62 46 30 14 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc069a917 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc069ac13 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0926763 in trap_fatal (frame=0xe8f32a08, eva=24) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc09270ff in trap (frame=0xe8f32a08) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc090c84b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc06ce915 in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:835 #7 0xc068d292 in _mtx_unlock_sleep (m=0xc0a47e10, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:611 #8 0xc0849b79 in nfsrv3_access (nfsd=0xc6ba5d00, slp=0xc6b7f700, td=0xc6856c60, mrq=0xe8f32c58) at /usr/src/sys/nfsserver/nfs_serv.c:253 #9 0xc085bc71 in nfssvc (td=0xc6856c60, uap=0xe8f32cfc) at /usr/src/sys/nfsserver/nfs_syscalls.c:461 #10 0xc0926d35 in syscall (frame=0xe8f32d38) at /usr/src/sys/i386/i386/trap.c:1035 #11 0xc090c8b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #12 0x00000033 in ?? () From rwatson at FreeBSD.org Mon May 26 09:30:21 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 09:30:29 2008 Subject: Remaining non-MPSAFE netisr handlers Message-ID: <20080526102345.G26343@fledge.watson.org> Dear all: In the continuing campaign to eliminate the Giant lock from the dregs of the network stack, I thought I'd send out a list of non-MPSAFE netisr handlers: Location Handler Removed with IFF_NEEDSGIANT dev/usb/usb_ethersubr.c:120 usbintr Yes net/if_ppp.c:277 pppintr Yes netinet6/ip6_input.c ip6_input No The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. This doesn't prohibit acquiring Giant in the handler if required, although that's undesirable for the obvious reasons (potentially stalling interrupt handling, etc). Obviously, what would be most desirable is eliminating the remaining requirement for Giant in the IPv6 input path, primarily consisting of mld6 and nd6. With this in mind, my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon May 26 10:07:40 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 10:07:47 2008 Subject: Wiki page for non-MPSAFE network stack de-orbit scheduling Message-ID: <20080526110543.J26343@fledge.watson.org> Just to keep track of things: http://wiki.freebsd.org/NONMPSAFE_DEORBIT Robert N M Watson Computer Laboratory University of Cambridge From bugmaster at FreeBSD.org Mon May 26 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:07:32 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200805261106.m4QB6qqB064975@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123950 net [tcp] TH_RST packet sended if received out-of-order da o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. 89 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available o kern/123961 net [vr] [patch] Allow vr interface to handle vlans 50 problems total. From ade at FreeBSD.org Mon May 26 13:10:34 2008 From: ade at FreeBSD.org (Ade Lovett) Date: Mon May 26 13:10:39 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080525105726.O39741@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> Message-ID: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> On May 25, 2008, at 02:58 , Robert Watson wrote: > While I'd be quite supportive of something along these lines, I > think it probably is more work to port SLIP to userspace than to > hack the current code a little bit to be MPSAFE, assuming it remains > supported with the revised tty code. SLIP is a fairly straight- > forward piece of code, as long as you don't try to understand the > line discipline stuff. :-) Given that this is (a) 2008 and (b) 8.x we're talking about, are there really that many consumers of SLIP to warrant it being carried forward at all? Seems to me that it would not be unreasonable to give a heads up that the current kernel-space ppp/slip (and, for that matter, plip) drivers are going away some time before 8.0-RELEASE, pppd is more than adequately replaced by userland-ppp or netgraph, and if there's some critical need by someone to have SLIP and/or PLIP, then they'll need to step up to the plate to do the necessary re-implementation. Or stick with 7.x, which would be unaffected by this. We have a lot of network drivers that are potentially up for axing with the move to MPSAFE. Why not push just a little harder and slice out some serious legacy code? It's all well and good to be able to say that the current release of the kernel supports hardware that hasn't been used, other than in idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ years, but it seems that we have an opportunity here to break out the Danish Ax[tm] in anger, and do some heavy-duty culling before 8.0-REL. -aDe From rwatson at FreeBSD.org Mon May 26 13:42:42 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 13:42:52 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526142931.Q26343@fledge.watson.org> On Mon, 26 May 2008, Ade Lovett wrote: > On May 25, 2008, at 02:58 , Robert Watson wrote: > >> While I'd be quite supportive of something along these lines, I think it >> probably is more work to port SLIP to userspace than to hack the current >> code a little bit to be MPSAFE, assuming it remains supported with the >> revised tty code. SLIP is a fairly straight-forward piece of code, as long >> as you don't try to understand the line discipline stuff. :-) > > Given that this is (a) 2008 and (b) 8.x we're talking about, are there > really that many consumers of SLIP to warrant it being carried forward at > all? > > Seems to me that it would not be unreasonable to give a heads up that the > current kernel-space ppp/slip (and, for that matter, plip) drivers are going > away some time before 8.0-RELEASE, pppd is more than adequately replaced by > userland-ppp or netgraph, and if there's some critical need by someone to > have SLIP and/or PLIP, then they'll need to step up to the plate to do the > necessary re-implementation. The thread you're replying began with precisely such a heads up. :-) Robert N M Watson Computer Laboratory University of Cambridge From kostikbel at gmail.com Mon May 26 13:45:50 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 26 13:45:53 2008 Subject: panic in nfsd in freebsd7-release and -stable In-Reply-To: <5230D3C40B842D4F9FB3CD368021BEF7020107F1@exchange-2.sandvine.com> References: <5230D3C40B842D4F9FB3CD368021BEF7020107F1@exchange-2.sandvine.com> Message-ID: <20080526133045.GJ21317@deviant.kiev.zoral.com.ua> On Sun, May 25, 2008 at 09:28:36PM -0400, Andrew Edwards wrote: > I have a system that was running some version of redhat (I don't > remember now) and I upgraded it to freebsd7 and I would get an immediate > panic when nfsd is started. I then updated to 7-stable (on May 24th) > and built a new kerenl and userland and the panic continued. > > This was happening 100% of the time whenever nfsd is started but what I > later discovered was that because I had used the same IP's as the linux > host there were some systems that still had a filesystem mounted from > before the conversion. I put in an ipfw rule to block those hosts and > then I was able to start nfsd without crashing and then create new > mounts. I have been able to work-around the issue by forcing all of the > servers that were mounting from the linux os to remount, I am only > including this information just in case someone else runs into a similar > problem. > > Thanks, > Andrew > > Here's the backtrace > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 06 > fault virtual address = 0x18 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06ce915 > stack pointer = 0x28:0xe8f32a48 > frame pointer = 0x28:0xe8f32a64 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 755 (nfsd) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 40m22s > Physical memory: 3318 MB > Dumping 93 MB: 78 62 46 30 14 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc069a917 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc069ac13 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0926763 in trap_fatal (frame=0xe8f32a08, eva=24) > at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc09270ff in trap (frame=0xe8f32a08) at > /usr/src/sys/i386/i386/trap.c:280 > #5 0xc090c84b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #6 0xc06ce915 in turnstile_broadcast (ts=0x0, queue=0) > at /usr/src/sys/kern/subr_turnstile.c:835 > #7 0xc068d292 in _mtx_unlock_sleep (m=0xc0a47e10, opts=0, file=0x0, > line=0) > at /usr/src/sys/kern/kern_mutex.c:611 > #8 0xc0849b79 in nfsrv3_access (nfsd=0xc6ba5d00, slp=0xc6b7f700, > td=0xc6856c60, mrq=0xe8f32c58) at > /usr/src/sys/nfsserver/nfs_serv.c:253 > #9 0xc085bc71 in nfssvc (td=0xc6856c60, uap=0xe8f32cfc) > at /usr/src/sys/nfsserver/nfs_syscalls.c:461 > #10 0xc0926d35 in syscall (frame=0xe8f32d38) > at /usr/src/sys/i386/i386/trap.c:1035 > #11 0xc090c8b0 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:196 > #12 0x00000033 in ?? () Please, test the change below. The nfsm_srvmtofh() may execute nfsm_reply(), that contains the goto nfsmout. Since the code under the label includes conditional unlock of the Giant, vfslocked must be initialized prior to the nfsm_srvmtofh. I found three ommissions. The patch also contains the removal of the duplicated code for the rev. 1.179. diff --git a/sys/nfsserver/nfs_serv.c b/sys/nfsserver/nfs_serv.c index 5343627..6e716e4 100644 --- a/sys/nfsserver/nfs_serv.c +++ b/sys/nfsserver/nfs_serv.c @@ -210,6 +210,7 @@ nfsrv3_access(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, nfsdbprintf(("%s %d\n", __FILE__, __LINE__)); if (!v3) panic("nfsrv3_access: v3 proc called on a v2 connection"); + vfslocked = 0; fhp = &nfh.fh_generic; nfsm_srvmtofh(fhp); tl = nfsm_dissect_nonblock(u_int32_t *, NFSX_UNSIGNED); @@ -1285,6 +1286,7 @@ nfsrv_writegather(struct nfsrv_descript **ndp, struct nfssvc_sock *slp, i = 0; len = 0; #endif + vfslocked = 0; *mrq = NULL; if (*ndp) { nfsd = *ndp; @@ -2146,7 +2148,7 @@ nfsrv_remove(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, nfsfh_t nfh; fhandle_t *fhp; struct mount *mp = NULL; - int vfslocked, vfslocked1; + int vfslocked; nfsdbprintf(("%s %d\n", __FILE__, __LINE__)); ndclear(&nd); @@ -2168,11 +2170,7 @@ nfsrv_remove(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, nd.ni_cnd.cn_flags = LOCKPARENT | LOCKLEAF | MPSAFE; error = nfs_namei(&nd, fhp, len, slp, nam, &md, &dpos, &dirp, v3, &dirfor, &dirfor_ret, td, FALSE); - vfslocked1 = NDHASGIANT(&nd); - if (vfslocked && vfslocked1) - VFS_UNLOCK_GIANT(vfslocked1); - if (vfslocked || vfslocked1) - vfslocked = 1; + vfslocked = nfsrv_lockedpair_nd(vfslocked, &nd); if (dirp && !v3) { vrele(dirp); dirp = NULL; @@ -4132,6 +4130,7 @@ nfsrv_pathconf(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, nfsdbprintf(("%s %d\n", __FILE__, __LINE__)); if (!v3) panic("nfsrv_pathconf: v3 proc called on a v2 connection"); + vfslocked = 0; fhp = &nfh.fh_generic; nfsm_srvmtofh(fhp); error = nfsrv_fhtovp(fhp, 1, &vp, &vfslocked, cred, slp, -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080526/82e007cc/attachment.pgp From fullermd at over-yonder.net Mon May 26 15:05:57 2008 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Mon May 26 15:06:06 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526144701.GG1689@over-yonder.net> On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the voice of Ade Lovett, and lo! it spake thus: > > It's all well and good to be able to say that the current release of > the kernel supports hardware that hasn't been used, other than in > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ > years, [...] Neat, I didn't know I was idiosyncratic. % uname -sr FreeBSD 8.0-CURRENT % grep ^ahc /var/run/dmesg.boot ahc0: port 0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device 11.0 on pci0 ahc0: [ITHREAD] ahc1: port 0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at device 13.0 on pci0 ahc1: [ITHREAD] ahc2: port 0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at device 13.1 on pci0 ahc2: [ITHREAD] (all 3 in use) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From bms at FreeBSD.org Mon May 26 15:17:46 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon May 26 15:17:54 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <483AD498.6070207@FreeBSD.org> Ade Lovett wrote: > > On May 25, 2008, at 02:58 , Robert Watson wrote: >> While I'd be quite supportive of something along these lines, I think >> it probably is more work to port SLIP to userspace than to hack the >> current code a little bit to be MPSAFE, assuming it remains supported >> with the revised tty code. SLIP is a fairly straight-forward piece >> of code, as long as you don't try to understand the line discipline >> stuff. :-) > > Given that this is (a) 2008 and (b) 8.x we're talking about, are there > really that many consumers of SLIP to warrant it being carried forward > at all? It's kind of a basic. [C]SLIP has been historically handy to have around for situations which warrant it. Mind you, given that we have had tun(4) in the tree for years now, a userland implementation of SLIP is possible. As with all of these things it's down to someone sitting down and doing it. I'm not volunteering to support any of this as I don't use it myself (got enough on my plate), merely pointing out that support for SLIP in a system is something many people have taken for granted over the years, and for prototyping something or providing IP over a simple serial link without the configuration overhead of PPP, SLIP is something someone might be using. P.S. ahc(4) is commodity hardware, I think it can stay right where it is thank-you. From rwatson at FreeBSD.org Mon May 26 15:26:15 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 15:26:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483AD498.6070207@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> Message-ID: <20080526162427.X26343@fledge.watson.org> On Mon, 26 May 2008, Bruce M. Simpson wrote: >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there >> really that many consumers of SLIP to warrant it being carried forward at >> all? > > It's kind of a basic. [C]SLIP has been historically handy to have around for > situations which warrant it. Mind you, given that we have had tun(4) in the > tree for years now, a userland implementation of SLIP is possible. > > As with all of these things it's down to someone sitting down and doing it. > > I'm not volunteering to support any of this as I don't use it myself (got > enough on my plate), merely pointing out that support for SLIP in a system > is something many people have taken for granted over the years, and for > prototyping something or providing IP over a simple serial link without the > configuration overhead of PPP, SLIP is something someone might be using. > > P.S. ahc(4) is commodity hardware, I think it can stay right where it is > thank-you. My suspicion is that getting SLIP basically working in userspace is fairly straight forward, although I'm not sure how well-suited some of our current admin tools (slattach, etc) are for the purpose. If the new tty code maintains support for line disciplines, updating the existing SLIP code and adding locking code would probably be an equally sized (or shorter) task. SLIP has its subtleties, but the current implementation is relatively straight-forward, well-documented, etc. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon May 26 15:42:17 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 15:42:24 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080526144701.GG1689@over-yonder.net> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <20080526144701.GG1689@over-yonder.net> Message-ID: <20080526164151.D26343@fledge.watson.org> On Mon, 26 May 2008, Matthew D. Fuller wrote: > On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the voice of > Ade Lovett, and lo! it spake thus: >> >> It's all well and good to be able to say that the current release of the >> kernel supports hardware that hasn't been used, other than in idiosyncratic >> situations (yes, ahc(4), I'm looking at you) for 5+ years, [...] > > Neat, I didn't know I was idiosyncratic. Somehow it's always me who is idiosyncratic: ahc0: port 0xdc00-0xdcff mem 0xf9fff000-0xf9ffffff irq 14 at device 11.0 on pci2 da0 at ahc0 bus 0 target 0 lun 0 Robert N M Watson Computer Laboratory University of Cambridge > > % uname -sr > FreeBSD 8.0-CURRENT > > % grep ^ahc /var/run/dmesg.boot > ahc0: port 0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device 11.0 on pci0 > ahc0: [ITHREAD] > ahc1: port 0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at device 13.0 on pci0 > ahc1: [ITHREAD] > ahc2: port 0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at device 13.1 on pci0 > ahc2: [ITHREAD] > > (all 3 in use) > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. > From ed at 80386.nl Mon May 26 16:17:11 2008 From: ed at 80386.nl (Ed Schouten) Date: Mon May 26 16:17:14 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> Message-ID: <20080526161608.GE64397@hoeg.nl> Hello Robert, * Robert Watson wrote: > If the new tty code maintains support for line disciplines, updating > the existing SLIP code and adding locking code would probably be an > equally sized (or shorter) task. The new TTY layer should still support line disciplines, unfortunately I haven't implemented the line discipline switching (TIOCSETD) yet. I would really prefer to have this in userspace. There are several advantages of implementing this in userspace: - We don't have to port things twice (make it MPSAFE first and port it to the new TTY layer later, or the other way around). - It is less likely to break. The entire userspace TTY and Tun/Tap userspace programming interfaces are more likely to be stable than the kernel interfaces. - It will be easier to port to other operating systems. - Implementing this in userspace could make it easier to configure and more flexible. Any comments/ideas/etc? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080526/21a8c39b/attachment.pgp From sgk at troutmask.apl.washington.edu Mon May 26 16:45:48 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon May 26 16:45:54 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526163844.GA37636@troutmask.apl.washington.edu> On Mon, May 26, 2008 at 05:34:09AM -0700, Ade Lovett wrote: > > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ What's the problem with ahc(4)? My ahc controller is one of the most reliable pieces of hardware that I've purchased. It's also the only interface available to my external DLT tape drive. -- Steve From wjw at digiware.nl Mon May 26 17:51:45 2008 From: wjw at digiware.nl (Willem Jan Withagen) Date: Mon May 26 17:51:56 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <20080526163844.GA37636@troutmask.apl.washington.edu> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <20080526163844.GA37636@troutmask.apl.washington.edu> Message-ID: <483AF194.2020002@digiware.nl> Steve Kargl wrote: > On Mon, May 26, 2008 at 05:34:09AM -0700, Ade Lovett wrote: >> idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ > > What's the problem with ahc(4)? My ahc controller is one of > the most reliable pieces of hardware that I've purchased. > It's also the only interface available to my external DLT > tape drive. Not to forget the large amount of embedded ahc's that got implemented on all kinds of serverbords. I still have quite a large set of customers with such ASUS boards I sold to them over the years. Up 'till now I've been able to keep 'm running with the pace of FreeBSD. Removing this driver would "leave them behind". I can force them to upgrade, but thus far there has been little reason for that (hardware wise). Just my 2 ct's --WjW From scottl at samsco.org Mon May 26 18:13:02 2008 From: scottl at samsco.org (Scott Long) Date: Mon May 26 18:13:08 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <483AF77D.3030006@samsco.org> Ade Lovett wrote: > It's all well and good to be able to say that the current release of the > kernel supports hardware that hasn't been used, other than in > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ years, > but it seems that we have an opportunity here to break out the Danish > Ax[tm] in anger, and do some heavy-duty culling before 8.0-REL. > Why does this argument on hardware support keep on coming up? For christ sake, every year some yahoo speaks up and declares that he knows what hardware should stay and what should go, and every year that yahoo gets educated on how counterproductive that is to the project. I'll just skip to the end of the recording and say, "NO". Scott From ade at freebsd.org Mon May 26 19:08:55 2008 From: ade at freebsd.org (Ade Lovett) Date: Mon May 26 19:09:04 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483AF77D.3030006@samsco.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AF77D.3030006@samsco.org> Message-ID: On May 26, 2008, at 10:46 , Scott Long wrote: > I'll just skip to the end of the recording and say, "NO". I wasn't aware that Web 2.0 did away with implied tags, not forgetting mode(tongue, cheek), etc.. etc.. Ah well. -aDe From phk at phk.freebsd.dk Mon May 26 19:41:12 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon May 26 19:41:15 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: Your message of "Mon, 26 May 2008 18:16:08 +0200." <20080526161608.GE64397@hoeg.nl> Message-ID: <42521.1211829076@critter.freebsd.dk> In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: >The new TTY layer should still support line disciplines, [...] Actually... I think it shouldn't. Line-disc's were introduced to interface weird-ass hardware like digitizing tablets that had very high data rates, but very little information (16 bit X, 16 bit Y and a couple of buttons, like modern mice) which would cost inordinate amounts of CPU time to support in userland on a VAX computer. If_slip.c happened in the kernel because there was no tun device, people cranked the speed up all they could (Hands up: who has changed the Xtal on a VAX serial port for faster SLIP ?) if_ppp happened because that was how if_slip did it. Today there is no longer a market for line disciplines and in practice we have only one: the POSIX mandated "termios", which also emulates the older "termio" ioctls. Anybody who cares to browse the three pages of text that RFC1055 contains, will see that implementing SLIP in userland using tun(4) and the code on the other three pages of RFC1055 is a trivial task not even worthy of a SoC student. PPP over async is already much better handled in ppp(8) thanks to Brians valiant effort back in the stoneage of the internet. We should summarily kill the concept of line disciplines as a modular component and decide that TTYs can be used with termios(4) or raw mode and leave it at that. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From iaccounts at ibctech.ca Mon May 26 22:51:13 2008 From: iaccounts at ibctech.ca (Steve Bertrand) Date: Mon May 26 22:51:15 2008 Subject: IPv6/IPv4 DNS resolver source Message-ID: <483B3E7F.8000907@ibctech.ca> Hi everyone, Is there anyone here who can advise me where in the source tree I would find the DNS resolver code that performs AAAA/A record lookups, and more specifically, the fallback to A lookup if AAAA fails? I am not a programmer, but I want to look at, and possibly make some local changes for testing internally. Thanks, Steve From peter at wemm.org Tue May 27 06:15:21 2008 From: peter at wemm.org (Peter Wemm) Date: Tue May 27 06:15:36 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: On Mon, May 26, 2008 at 12:11 PM, Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > >>The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. > > Line-disc's were introduced to interface weird-ass hardware like > digitizing tablets that had very high data rates, but very little > information (16 bit X, 16 bit Y and a couple of buttons, like modern > mice) which would cost inordinate amounts of CPU time to support > in userland on a VAX computer. > > If_slip.c happened in the kernel because there was no tun device, > people cranked the speed up all they could (Hands up: who has changed > the Xtal on a VAX serial port for faster SLIP ?) > > if_ppp happened because that was how if_slip did it. > > Today there is no longer a market for line disciplines and in > practice we have only one: the POSIX mandated "termios", which also > emulates the older "termio" ioctls. > > Anybody who cares to browse the three pages of text that RFC1055 > contains, will see that implementing SLIP in userland using tun(4) > and the code on the other three pages of RFC1055 is a trivial task > not even worthy of a SoC student. > > PPP over async is already much better handled in ppp(8) thanks > to Brians valiant effort back in the stoneage of the internet. > > We should summarily kill the concept of line disciplines as a > modular component and decide that TTYs can be used with termios(4) > or raw mode and leave it at that. Amen brother!! I'd like if_sl.c and if_ppp.c/ppp_tty.c to go away simply so that we don't have to keep the line discipline switch in its current form. Let the tty layer rewrite have a free hand at doing whatever locking strategy is most appropriate for ttys, without having to worry about line disciplines and the lock order problems that come with if_sl.c. There is a reason why we merged the splnet() and spltty() interrupt masks back when we had spl()s. The tty stack cross called into the network stack via if_sl, and vice versa. ppp_tty.c had a hack to create a swi (thread) to partly hack around this where it was most critical to limit blocking of interrupts. To make this work is likely going to need a full taskq or thread for both if_sl.c and ppp_tty.c. It just isn't worth it. Especially when we have a better option in userland for ppp, and slip is a few dozen lines of code around a if_tun select loop. I've written 75% of what it would take to do slip in userland at least two or three times already, over the last 10 years. It just isn't worth it. Let line disciplines die and give Ed a free hand to do ttys "right". Line disciplines were there so that we could push processing for things like serial mice into the kernel and reduce context switches. We've been doing that in userland for the last 14+ years. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From ed at 80386.nl Tue May 27 06:28:49 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 06:28:54 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: <20080527062736.GF64397@hoeg.nl> * Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > > >The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. With the word `should' I meant that it would still be possible to implement multiple line disciplines with the mpsafetty code. But I really think line disciplines should go. What should happen with the NETGRAPHDISC? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080527/49f9a780/attachment.pgp From phk at phk.freebsd.dk Tue May 27 06:37:52 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue May 27 06:38:04 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: Your message of "Tue, 27 May 2008 08:27:36 +0200." <20080527062736.GF64397@hoeg.nl> Message-ID: <45633.1211870269@critter.freebsd.dk> In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: >> >The new TTY layer should still support line disciplines, [...] >> >> Actually... I think it shouldn't. > >With the word `should' I meant that it would still be possible to >implement multiple line disciplines with the mpsafetty code. But I >really think line disciplines should go. No, don't bother. Remove the entire "abstraction" of linedisciplines. >What should happen with the NETGRAPHDISC? It should be done in userland if it is necessary at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ed at 80386.nl Tue May 27 06:44:06 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 06:44:14 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <45633.1211870269@critter.freebsd.dk> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> Message-ID: <20080527064253.GG64397@hoeg.nl> * Poul-Henning Kamp wrote: > In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: > > >> >The new TTY layer should still support line disciplines, [...] > >> > >> Actually... I think it shouldn't. > > > >With the word `should' I meant that it would still be possible to > >implement multiple line disciplines with the mpsafetty code. But I > >really think line disciplines should go. > > No, don't bother. Remove the entire "abstraction" of linedisciplines. Your wish is my command. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080527/0654086b/attachment.pgp From julian at elischer.org Tue May 27 07:45:27 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 07:45:33 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <42521.1211829076@critter.freebsd.dk> Message-ID: <483BBC1B.6040905@elischer.org> Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > >> The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. > > Line-disc's were introduced to interface weird-ass hardware like > digitizing tablets that had very high data rates, but very little > information (16 bit X, 16 bit Y and a couple of buttons, like modern > mice) which would cost inordinate amounts of CPU time to support > in userland on a VAX computer. > > If_slip.c happened in the kernel because there was no tun device, > people cranked the speed up all they could (Hands up: who has changed > the Xtal on a VAX serial port for faster SLIP ?) > > if_ppp happened because that was how if_slip did it. > > Today there is no longer a market for line disciplines and in > practice we have only one: the POSIX mandated "termios", which also > emulates the older "termio" ioctls. > > Anybody who cares to browse the three pages of text that RFC1055 > contains, will see that implementing SLIP in userland using tun(4) > and the code on the other three pages of RFC1055 is a trivial task > not even worthy of a SoC student. > > PPP over async is already much better handled in ppp(8) thanks > to Brians valiant effort back in the stoneage of the internet. > > We should summarily kill the concept of line disciplines as a > modular component and decide that TTYs can be used with termios(4) > or raw mode and leave it at that. > > Poul-Henning > However the line discipline was a very convenient place for netgraph to hook in without leaving the kernel. If you can supply an equally effective way to hook into a serial device in such a way that it appears to be a source/sink of bits then I don't care about line disciplins, but until you have a suggested replacement then leave them alone. There are MANY people using mpd with the netgraph ppp moduel hooked directly to the serial port via the netgraph line discipline. From phk at phk.freebsd.dk Tue May 27 08:04:02 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue May 27 08:04:08 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: Your message of "Tue, 27 May 2008 00:45:31 MST." <483BBC1B.6040905@elischer.org> Message-ID: <51989.1211875439@critter.freebsd.dk> In message <483BBC1B.6040905@elischer.org>, Julian Elischer writes: >However the line discipline was a very convenient place for netgraph >to hook in without leaving the kernel. If you can supply an equally >effective way to hook into a serial device in such a way that it >appears to be a source/sink of bits then I don't care about >line disciplins, but until you have a suggested replacement then leave >them alone. There are MANY people using mpd with the netgraph ppp >moduel hooked directly to the serial port via the netgraph line >discipline. What exact value of "MANY" are we talking about here, and do you have any evidence that the systems in question will be updated to FreeBSD-8.0-RELEASE or later ? If, contrary to my expectation, that you can show a real market here, then we should make a better interface than linedisc for such hooks into serial ports. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From julian at elischer.org Tue May 27 08:06:10 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 08:06:15 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483BBC1B.6040905@elischer.org> References: <42521.1211829076@critter.freebsd.dk> <483BBC1B.6040905@elischer.org> Message-ID: <483BC0F6.4050700@elischer.org> Julian Elischer wrote: > Poul-Henning Kamp wrote: >> In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: >> >>> The new TTY layer should still support line disciplines, [...] >> >> Actually... I think it shouldn't. >> >> Line-disc's were introduced to interface weird-ass hardware like >> digitizing tablets that had very high data rates, but very little >> information (16 bit X, 16 bit Y and a couple of buttons, like modern >> mice) which would cost inordinate amounts of CPU time to support >> in userland on a VAX computer. >> >> If_slip.c happened in the kernel because there was no tun device, >> people cranked the speed up all they could (Hands up: who has changed >> the Xtal on a VAX serial port for faster SLIP ?) >> >> if_ppp happened because that was how if_slip did it. >> >> Today there is no longer a market for line disciplines and in >> practice we have only one: the POSIX mandated "termios", which also >> emulates the older "termio" ioctls. >> >> Anybody who cares to browse the three pages of text that RFC1055 >> contains, will see that implementing SLIP in userland using tun(4) >> and the code on the other three pages of RFC1055 is a trivial task >> not even worthy of a SoC student. >> >> PPP over async is already much better handled in ppp(8) thanks >> to Brians valiant effort back in the stoneage of the internet. >> >> We should summarily kill the concept of line disciplines as a >> modular component and decide that TTYs can be used with termios(4) >> or raw mode and leave it at that. >> >> Poul-Henning >> > > > However the line discipline was a very convenient place for netgraph to > hook in without leaving the kernel. If you can supply an equally > effective way to hook into a serial device in such a way that it appears > to be a source/sink of bits then I don't care about > line disciplins, but until you have a suggested replacement then leave > them alone. There are MANY people using mpd with the netgraph ppp moduel > hooked directly to the serial port via the netgraph line discipline. p.s "do it in userland" is not the right answer, but it should be able to hook into netgraph without all the requirements that were needed for a line discipline. let me contact you independently and we 'll see what can be done. > > _______________________________________________ > 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 julian at elischer.org Tue May 27 08:12:41 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 08:12:53 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <51989.1211875439@critter.freebsd.dk> References: <51989.1211875439@critter.freebsd.dk> Message-ID: <483BC27C.6010102@elischer.org> Poul-Henning Kamp wrote: > In message <483BBC1B.6040905@elischer.org>, Julian Elischer writes: > >> However the line discipline was a very convenient place for netgraph >> to hook in without leaving the kernel. If you can supply an equally >> effective way to hook into a serial device in such a way that it >> appears to be a source/sink of bits then I don't care about >> line disciplins, but until you have a suggested replacement then leave >> them alone. There are MANY people using mpd with the netgraph ppp >> moduel hooked directly to the serial port via the netgraph line >> discipline. > > What exact value of "MANY" are we talking about here, and do you > have any evidence that the systems in question will be updated > to FreeBSD-8.0-RELEASE or later ? judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. One that comes to mind is tha tthe way netgraph hooks to other modules assumes a possible queueing of data, and that decoupling could make it a lot easier to connect tehm that was required for slip and ppp. > > If, contrary to my expectation, that you can show a real market > here, then we should make a better interface than linedisc for > such hooks into serial ports. > From mohacsi at niif.hu Tue May 27 08:39:11 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue May 27 08:39:15 2008 Subject: page fault in nd6_output() Message-ID: <20080527083905.F0DB08450D@mail.ki.iif.hu> >Submitter-Id: current-users >Originator: Mohacsi Janos >Organization: NIIF >Confidential: no >Synopsis: page fault in nd6_output() >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: FreeBSD 6.3-STABLE i386 >Environment: System: FreeBSD mignon.ki.iif.hu 6.3-STABLE FreeBSD 6.3-STABLE #12: Mon May 19 18:48:06 CEST 2008 root@mignon.ki.iif.hu:/usr/obj/usr/src/sys/MIGNON2 i386 >Description: Kernel panicked in nd6_output() function. root@mignon# kgdb kernel.debug /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc055cc65 stack pointer = 0x28:0xef85289c frame pointer = 0x28:0xef8528b4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 30145 (sshd) trap number = 12 panic: page fault cpuid = 0 Uptime: 4d5h35m21s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/kernel/ispfw.ko...done. Loaded symbols for /boot/kernel/ispfw.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/fdescfs.ko...done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/pflog.ko...done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/accf_http.ko...done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/daemon_saver.ko...done. Loaded symbols for /boot/kernel/daemon_saver.ko #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc056802d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc05683de in panic (fmt=0xc0759e9a "%s") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc0729180 in trap_fatal (frame=0xef85285c, eva=0) at /usr/src/sys/i386/i386/trap.c:838 #4 0xc0728865 in trap (frame= {tf_fs = -276496376, tf_es = -1067188184, tf_ds = -276496344, tf_edi = -939729920, tf_esi = 4, tf_ebp = -276485964, tf_isp = -276486008, tf_ebx = -987277284, tf_edx = 6, tf_ecx = 3, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068118939, tf_cs = 32, tf_eflags = 65538, tf_esp = -987277284, tf_ss = -991664924}) at /usr/src/sys/i386/i386/trap.c:270 #5 0xc071186a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc055cc65 in _mtx_lock_sleep (m=0xc527581c, tid=3355237376, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 #7 0xc0642437 in nd6_output (ifp=0xc4c3e000, origifp=0x1, m0=0xc6c18300, dst=0xc4e464dc, rt0=0xc5275840) at /usr/src/sys/netinet6/nd6.c:2008 #8 0xc063b712 in ip6_output (m0=0xef852a78, opt=0x0, ro=0xef852a78, flags=0, im6o=0x0, ifpp=0x0, inp=0xc54ae2d0) at /usr/src/sys/netinet6/ip6_output.c:994 #9 0xc0619e31 in tcp_output (tp=0xc588acb0) at /usr/src/sys/netinet/tcp_output.c:1059 #10 0xc06225bb in tcp_usr_send (so=0xc589b000, flags=0, m=0xc7baaa00, nam=0x0, control=0x0, td=0xc7fcdc00) at /usr/src/sys/netinet/tcp_usrreq.c:698 #11 0xc05ad5df in sosend (so=0xc589b000, addr=0x0, uio=0xef852cb0, top=0xc7baaa00, control=0x0, flags=0, td=0xc7fcdc00) at /usr/src/sys/kern/uipc_socket.c:836 #12 0xc05992c7 in soo_write (fp=0x1, uio=0xef852cb0, active_cred=0xc5d60000, flags=0, td=0xc7fcdc00) at /usr/src/sys/kern/sys_socket.c:118 #13 0xc05923da in dofilewrite (td=0xc7fcdc00, fd=1, fp=0xc59ffd38, auio=0xef852cb0, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:253 #14 0xc059220b in kern_writev (td=0xc7fcdc00, fd=3, auio=0x1) at /usr/src/sys/kern/sys_generic.c:402 #15 0xc05920dd in write (td=0x1, uap=0x3) at /usr/src/sys/kern/sys_generic.c:326 #16 0xc0729567 in syscall (frame= {tf_fs = 134676539, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = 134701160, tf_esi = 80, tf_ebp = -1077941848, tf_isp = -276484764, tf_ebx = 672000184, tf_edx = 134701160, tf_ecx = 3, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 674877415, tf_cs = 51, tf_eflags = 518, tf_esp = -1077941876, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984 #17 0xc07118bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit >How-To-Repeat: This crash occurs basically every 2-3 months since FreeBSD 6.x >Fix: If you need more infromation about the crash and the kernel - I can provide you. From bzeeb-lists at lists.zabbadoz.net Tue May 27 08:50:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 27 08:50:14 2008 Subject: kern/124021: page fault in nd6_output() In-Reply-To: <20080527083905.F0DB08450D@mail.ki.iif.hu> References: <20080527083905.F0DB08450D@mail.ki.iif.hu> Message-ID: <20080527084426.D65662@maildrop.int.zabbadoz.net> On Tue, 27 May 2008, Mohacsi Janos wrote: >> Synopsis: page fault in nd6_output() This is most likely an issue because of missing proper locking and is well known. I bet one can find another 5 reports of this in gnats. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From rwatson at FreeBSD.org Tue May 27 08:54:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue May 27 08:55:05 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <45633.1211870269@critter.freebsd.dk> References: <45633.1211870269@critter.freebsd.dk> Message-ID: <20080527095317.R35026@fledge.watson.org> On Tue, 27 May 2008, Poul-Henning Kamp wrote: > In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: > >>>> The new TTY layer should still support line disciplines, [...] >>> >>> Actually... I think it shouldn't. >> >> With the word `should' I meant that it would still be possible to implement >> multiple line disciplines with the mpsafetty code. But I really think line >> disciplines should go. > > No, don't bother. Remove the entire "abstraction" of linedisciplines. > >> What should happen with the NETGRAPHDISC? > > It should be done in userland if it is necessary at all. It sounds like there is some disagreement on this point, given that that would require byte streams from serial lines to go into userspace just to be re-injected into the kernel in order to enter netgraph. Rather than do that, a more sensible route would be to look at converting ng_tty from a line discipline into a much more constrained set of I/O hooks, selected using the same ioctl but presumably a different discipline name. Unfortunately, it's not clear that snp would use the same hooks, as Netgraph presumably wants to eat the input, whereas snp just wants a copy, but perhaps there's a clean way to capture that distinction. Robert N M Watson Computer Laboratory University of Cambridge From stefan.lambrev at moneybookers.com Tue May 27 09:16:08 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue May 27 09:16:12 2008 Subject: Adjust Maximum Segment Size? Message-ID: <483BD151.3070900@moneybookers.com> Greetings, Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? I want to play only with MSS not with MTU. So far the only solution that I found is pf+scrub, but I wander if it is possible to do it without firewall. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From bzeeb-lists at lists.zabbadoz.net Tue May 27 09:25:06 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 27 09:25:09 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD151.3070900@moneybookers.com> References: <483BD151.3070900@moneybookers.com> Message-ID: <20080527092125.K65662@maildrop.int.zabbadoz.net> On Tue, 27 May 2008, Stefan Lambrev wrote: Hi, > Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? > I want to play only with MSS not with MTU. > So far the only solution that I found is pf+scrub, but I wander if it is > possible to do it without > firewall. depends on how you want to do it? Are you asking becuase you are running ppp or mpd? Or do you want to change it globally for everything of a machine? -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From stefan.lambrev at moneybookers.com Tue May 27 09:37:24 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue May 27 09:37:31 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <20080527092125.K65662@maildrop.int.zabbadoz.net> References: <483BD151.3070900@moneybookers.com> <20080527092125.K65662@maildrop.int.zabbadoz.net> Message-ID: <483BD650.9080002@moneybookers.com> Bjoern A. Zeeb wrote: > On Tue, 27 May 2008, Stefan Lambrev wrote: > > Hi, > >> Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? >> I want to play only with MSS not with MTU. >> So far the only solution that I found is pf+scrub, but I wander if it >> is possible to do it without >> firewall. > > depends on how you want to do it? Are you asking becuase you are > running ppp or mpd? Or do you want to change it globally for > everything of a machine? > I'm experimenting with gre tunnels - the problem comes from async routes. From gre0 I receive traffic, but replies are sent over Ethernet card. So I can't make mtu on if0 the same as the mtu on gre0. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From boris at ntmk.ru Tue May 27 10:21:49 2008 From: boris at ntmk.ru (Boris Kovalenko) Date: Tue May 27 10:21:53 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD151.3070900@moneybookers.com> References: <483BD151.3070900@moneybookers.com> Message-ID: <483BD3EC.4000909@ntmk.ru> Hello! Yes, You can with ng_tcpmss > Greetings, > > Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? > I want to play only with MSS not with MTU. > So far the only solution that I found is pf+scrub, but I wander if it > is possible to do it without > firewall. > Regards, Boris From stefan.lambrev at moneybookers.com Tue May 27 12:12:58 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue May 27 12:13:00 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD3EC.4000909@ntmk.ru> References: <483BD151.3070900@moneybookers.com> <483BD3EC.4000909@ntmk.ru> Message-ID: <483BFAC2.9040400@moneybookers.com> Boris Kovalenko wrote: > Hello! > > Yes, You can with ng_tcpmss Isn't it doable only with ipfw/divert when using ng_tcpmss? I have and some concerns about performance too .. >> Greetings, >> >> Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? >> I want to play only with MSS not with MTU. >> So far the only solution that I found is pf+scrub, but I wander if it >> is possible to do it without >> firewall. >> > Regards, > Boris > > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From gavin at FreeBSD.org Tue May 27 13:09:27 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue May 27 13:09:33 2008 Subject: bin/124004: [ifconfig] Cannot assign both an IP and a MAC address to a bridge in one command Message-ID: <200805271309.m4RD9QOP015687@freefall.freebsd.org> Old Synopsis: Cannot assign both an IP and a MAC address to a bridge in one command New Synopsis: [ifconfig] Cannot assign both an IP and a MAC address to a bridge in one command Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue May 27 13:09:08 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=124004 From nvass at teledomenet.gr Tue May 27 14:09:58 2008 From: nvass at teledomenet.gr (Nikos Vassiliadis) Date: Tue May 27 14:10:02 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD650.9080002@moneybookers.com> References: <483BD151.3070900@moneybookers.com> <20080527092125.K65662@maildrop.int.zabbadoz.net> <483BD650.9080002@moneybookers.com> Message-ID: <200805271651.38888.nvass@teledomenet.gr> On Tuesday 27 May 2008 12:37:20 Stefan Lambrev wrote: > I'm experimenting with gre tunnels - the problem comes from async > routes. From gre0 I receive traffic, but replies are sent over Ethernet > card. So I can't make mtu on if0 the same as the mtu on gre0. You could change the mtu size for certain destinations using route(8) and the -mtu modifier. Lower the mtu for the known destination or perhaps for the default route to keep your system from using the interface's mtu. Of course, this will influence mtu and not only mss... HTH, Nikos From iaccounts at ibctech.ca Tue May 27 14:13:43 2008 From: iaccounts at ibctech.ca (Steve Bertrand) Date: Tue May 27 14:13:45 2008 Subject: Dual stack with multiple addresses in rc.conf Message-ID: <483C169D.7030304@ibctech.ca> Hi all, I'm having a difficult time sorting out how to have all my required IP addresses (and gateways) configured correctly on boot up via rc.conf. I've tried all manner of methods using aliases etc, but somehow or another, the machine fails to configure all of the addresses correctly, and it never configures the IPv6 defaultrouter in the routing table. I must stand by the console of the machine if it needs to be rebooted so I can manually configure the addresses/routes that do not set themselves up correctly. Can someone please advise me on the proper configuration as it should be in rc.conf for the following addresses? All of the addresses need to be configured on a single interface (fxp0): ifconfig_fxp0="inet6 2607:f118::b6 prefixlen 64" ifconfig_fxp0_alias0="inet6 2607:f118::b7 prefixlen 64" ifconfig_fxp0="inet 208.70.104.210 255.255.255.248" ifconfig_fxp0_alias1="inet 208.70.104.211 netmask 255.255.255.255" defaultrouter="208.70.104.209" ipv6_defaultrouter="2607:f118::1" Regards, Steve From max at love2party.net Tue May 27 14:25:07 2008 From: max at love2party.net (Max Laier) Date: Tue May 27 14:25:12 2008 Subject: Dual stack with multiple addresses in rc.conf In-Reply-To: <483C169D.7030304@ibctech.ca> References: <483C169D.7030304@ibctech.ca> Message-ID: <200805271624.27922.max@love2party.net> On Tuesday 27 May 2008 16:11:41 Steve Bertrand wrote: > Hi all, > > I'm having a difficult time sorting out how to have all my required IP > addresses (and gateways) configured correctly on boot up via rc.conf. > > I've tried all manner of methods using aliases etc, but somehow or > another, the machine fails to configure all of the addresses correctly, > and it never configures the IPv6 defaultrouter in the routing table. I > must stand by the console of the machine if it needs to be rebooted so > I can manually configure the addresses/routes that do not set > themselves up correctly. > > Can someone please advise me on the proper configuration as it should > be in rc.conf for the following addresses? All of the addresses need to > be configured on a single interface (fxp0): > > ifconfig_fxp0="inet6 2607:f118::b6 prefixlen 64" > ifconfig_fxp0_alias0="inet6 2607:f118::b7 prefixlen 64" > ifconfig_fxp0="inet 208.70.104.210 255.255.255.248" > ifconfig_fxp0_alias1="inet 208.70.104.211 netmask 255.255.255.255" > > defaultrouter="208.70.104.209" > ipv6_defaultrouter="2607:f118::1" From rc.conf(5): Instead of setting the ifconfig variables as ifconfig_ they should be set as ipv6_ifconfig_. Aliases should be set as ipv6_ifconfig__alias. The default router should fall into place once you have an interface that is able to contact it - otherwise route will refuse to add. > Regards, > > Steve > _______________________________________________ > 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" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From bms at FreeBSD.org Tue May 27 15:19:08 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue May 27 15:19:13 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080527064253.GG64397@hoeg.nl> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> Message-ID: <483C2666.7010608@FreeBSD.org> Ed Schouten wrote: >>> With the word `should' I meant that it would still be possible to >>> implement multiple line disciplines with the mpsafetty code. But I >>> really think line disciplines should go. >>> >> No, don't bother. Remove the entire "abstraction" of linedisciplines. >> > > Your wish is my command. > Like Julian and Robert said, please don't break Netgraph. It still needs to hook into tty at a very low level; and the components such as Bluetooth which can use ttys for low level stream processing, are built on Netgraph. Both SLIP and PPP can be built using Netgraph. Other than that, line disciplines can go away. From peterjeremy at optushome.com.au Tue May 27 17:01:51 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 27 17:02:03 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: <20080527085913.GD1469@server.vk2pj.dyndns.org> On 2008-May-26 19:11:16 +0000, Poul-Henning Kamp wrote: >We should summarily kill the concept of line disciplines as a >modular component and decide that TTYs can be used with termios(4) >or raw mode and leave it at that. streams anyone? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080527/462ffe2d/attachment.pgp From xcllnt at mac.com Tue May 27 17:02:33 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 17:02:43 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483BC27C.6010102@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> Message-ID: <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: > judging by the bug reports when things get broken there are still a > lot of people connected to the internet via dial up lines in places > off the beaten track, and still a lot of people who when travelling > do use dialup still. Some of these also use mpd. I can not say how > many plan to keep using this in the future but it may be that the > simplest answer is a completely separate sio driver that > just has netgraph hooks. I haven't talked with Ed yet but there > may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, -- Marcel Moolenaar xcllnt@mac.com From julian at elischer.org Tue May 27 17:06:38 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:06:45 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD151.3070900@moneybookers.com> References: <483BD151.3070900@moneybookers.com> Message-ID: <483C3FA5.2070905@elischer.org> Stefan Lambrev wrote: > Greetings, > > Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? > I want to play only with MSS not with MTU. > So far the only solution that I found is pf+scrub, but I wander if it is > possible to do it without > firewall. > there is tcpmssd in ports but that also requires a firewall (ipfw) and divert. From julian at elischer.org Tue May 27 17:08:20 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:08:24 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483BD3EC.4000909@ntmk.ru> References: <483BD151.3070900@moneybookers.com> <483BD3EC.4000909@ntmk.ru> Message-ID: <483C400B.8050804@elischer.org> Boris Kovalenko wrote: > Hello! > > Yes, You can with ng_tcpmss >> Greetings, >> >> Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? >> I want to play only with MSS not with MTU. >> So far the only solution that I found is pf+scrub, but I wander if it >> is possible to do it without >> firewall. >> > Regards, > Boris > > _______________________________________________ > 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" gosh I didn't even know about that.... From julian at elischer.org Tue May 27 17:50:14 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:50:19 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> Message-ID: <483C49DC.3080108@elischer.org> Marcel Moolenaar wrote: > On May 27, 2008, at 1:12 AM, Julian Elischer wrote: > >> judging by the bug reports when things get broken there are still a >> lot of people connected to the internet via dial up lines in places >> off the beaten track, and still a lot of people who when travelling >> do use dialup still. Some of these also use mpd. I can not say how >> many plan to keep using this in the future but it may be that the >> simplest answer is a completely separate sio driver that >> just has netgraph hooks. I haven't talked with Ed yet but there >> may be may ways to solve this problem. > > Take a look at uart(4). It has been designed to allow different > kernel interfaces. It currently supports TTYs and keyboards. It > should not be too hard to have it hook into netgraph. > > FYI, > While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. From bms at FreeBSD.org Tue May 27 17:53:28 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue May 27 17:53:39 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C49DC.3080108@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> Message-ID: <483C4A94.4000107@FreeBSD.org> Julian Elischer wrote: > > While this is a good idea on it's own, the difference between > what that achieves and what a line discipline achieves is that > a line disciplin is hardware independent and can even be used > on a virtual device. I was under the impression that the back-end for UART was light weight enough that it could be used as a virtual device. For example: Many years ago I tried to get the WinModem working in my IBM ThinkPad T23. UART lends itself well to being a wrapper for the DSP microcode without having any of the historical tty baggage. In the case of UART the "translation shim" moves from on top of the device node to underneath, in much the same way as has happened for GEOM. From stefan.lambrev at moneybookers.com Tue May 27 18:05:01 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue May 27 18:05:04 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483C4636.7080608@mavhome.dp.ua> References: <1211891010.00075594.1211880013@10.7.7.3> <1211894613.00075634.1211884201@10.7.7.3> <1211901827.00075710.1211890802@10.7.7.3> <483C4636.7080608@mavhome.dp.ua> Message-ID: <483C4D48.6020106@moneybookers.com> Greetings, Alexander Motin wrote: > Stefan Lambrev wrote: >>> Yes, You can with ng_tcpmss >> Isn't it doable only with ipfw/divert when using ng_tcpmss? >> I have and some concerns about performance too .. > > There are several ways to inject packet to ng_tcpmss: > - ipfw + divert + ng_ksocket. It should be faster then usual > user-level implementation > - ipfw + netgraph as described in ng_tcpmss(4) > - use ng_tcpmss directly in some complicated netgraph setup. For > example, mpd is able to use it. This is probably the fastest and > easiest way, but only for some setups. > Thanks for all ideas. I think I'll try the route -mtu feature. Looks like easier for implementation and testing. :) Anyway it will be good if we have such feature in the base system. It shouldn't be very difficult? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From xcllnt at mac.com Tue May 27 18:11:41 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 18:11:55 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C49DC.3080108@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> Message-ID: <260F636A-8F72-411B-AED9-B029E1964003@mac.com> On May 27, 2008, at 10:50 AM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>> judging by the bug reports when things get broken there are still a >>> lot of people connected to the internet via dial up lines in places >>> off the beaten track, and still a lot of people who when travelling >>> do use dialup still. Some of these also use mpd. I can not say how >>> many plan to keep using this in the future but it may be that the >>> simplest answer is a completely separate sio driver that >>> just has netgraph hooks. I haven't talked with Ed yet but there >>> may be may ways to solve this problem. >> Take a look at uart(4). It has been designed to allow different >> kernel interfaces. It currently supports TTYs and keyboards. It >> should not be too hard to have it hook into netgraph. >> FYI, > > > While this is a good idea on it's own, the difference between > what that achieves and what a line discipline achieves is that > a line disciplin is hardware independent and can even be used > on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) -- Marcel Moolenaar xcllnt@mac.com From ermal.luci at gmail.com Tue May 27 18:14:14 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue May 27 18:14:21 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483C4D48.6020106@moneybookers.com> References: <1211891010.00075594.1211880013@10.7.7.3> <1211894613.00075634.1211884201@10.7.7.3> <1211901827.00075710.1211890802@10.7.7.3> <483C4636.7080608@mavhome.dp.ua> <483C4D48.6020106@moneybookers.com> Message-ID: <9a542da30805271114w6ad82569m43d89c4cd03a76fc@mail.gmail.com> On Tue, May 27, 2008 at 8:04 PM, Stefan Lambrev wrote: > Greetings, > > Alexander Motin wrote: >> >> Stefan Lambrev wrote: >>>> >>>> Yes, You can with ng_tcpmss >>> >>> Isn't it doable only with ipfw/divert when using ng_tcpmss? >>> I have and some concerns about performance too .. >> >> There are several ways to inject packet to ng_tcpmss: >> - ipfw + divert + ng_ksocket. It should be faster then usual user-level >> implementation >> - ipfw + netgraph as described in ng_tcpmss(4) >> - use ng_tcpmss directly in some complicated netgraph setup. For example, >> mpd is able to use it. This is probably the fastest and easiest way, but >> only for some setups. >> > > Thanks for all ideas. > I think I'll try the route -mtu feature. > Looks like easier for implementation and testing. :) > Anyway it will be good if we have such feature in the base system. > It shouldn't be very difficult? :) > > -- Actually converting ng_tcpmss to pfil(9) should be easy. Ermal From martin.fuchs at trendchiller.com Tue May 27 18:23:00 2008 From: martin.fuchs at trendchiller.com (Fuchs, Martin) Date: Tue May 27 18:23:06 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 Message-ID: Hi ! I am in contact with Chris Buechler because of pfSense and we he told me to contact Jack Vogel because of some Intel NIC driver problem. FreeBSD detects them as fxp cards which is correct, but they do not work at all, i tried in ACPI and non-ACPI mode and with enabled ROM and disabled ROM and everything, but I cannot get them working... I always get "fxp0 timeout" or fxpX fort he corresponding card... I read it might have something to do with dynamic powersaving mode or else but have no clue how to deactivate, there's no option in the ROM for this. It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x ICH4 integrated LAN Int on board. Is there anything I can tot o make it work for now or is it a known problem or else ? Regards, looking forward to hear from you, Martin From mav at mavhome.dp.ua Tue May 27 18:34:52 2008 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue May 27 18:34:57 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <1211901827.00075710.1211890802@10.7.7.3> References: <1211891010.00075594.1211880013@10.7.7.3> <1211894613.00075634.1211884201@10.7.7.3> <1211901827.00075710.1211890802@10.7.7.3> Message-ID: <483C4636.7080608@mavhome.dp.ua> Stefan Lambrev wrote: >> Yes, You can with ng_tcpmss > Isn't it doable only with ipfw/divert when using ng_tcpmss? > I have and some concerns about performance too .. There are several ways to inject packet to ng_tcpmss: - ipfw + divert + ng_ksocket. It should be faster then usual user-level implementation - ipfw + netgraph as described in ng_tcpmss(4) - use ng_tcpmss directly in some complicated netgraph setup. For example, mpd is able to use it. This is probably the fastest and easiest way, but only for some setups. -- Alexander Motin From tom at tomjudge.com Tue May 27 18:40:21 2008 From: tom at tomjudge.com (Tom Judge) Date: Tue May 27 18:40:28 2008 Subject: ICMP Error transmission/response over IPSec tunnels Message-ID: <483C51EE.7040700@tomjudge.com> Hi, Today I looked into why I can not get a traceroute across a IPSec IPIP tunnel an came across an interesting piece of code. Here is a diagram of the setup: [Node A] <-> [Router A] <-{IPSec}-> [Router B] <-> [Node B] If I traceroute from node A to node B I never see the ICMP packet for the TTL exceeded generated by router b. So I did a little digging and found and interesting revision of sys/netinet/ip_icmp.c. In revision 1.93 it seems ume@ added a check for the flag M_DECRYPTED in icmp_error() and if it was set do not generate the icmp error message. So my questions are: 1) Is this check really required? 2) If it is required what makes it required? Is it a problem in the icmp transmit path, or is there some other reason? 3) It seems the check originated from the KAME project, as FreeBSD no longer uses the KAME IPSec implementation is check still required? I found the same check in the netbsd code, but could not find a similar check in openbsd (although the openbsd ipsec implementation is some what different from netbsd and freebsd). Any information about this would be appreciated as I would like to be able to do traceroutes across my wan. Thanks Tom From Jinmei_Tatuya at isc.org Tue May 27 18:53:27 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Tue May 27 18:53:29 2008 Subject: IPv6/IPv4 DNS resolver source In-Reply-To: <483B3E7F.8000907@ibctech.ca> References: <483B3E7F.8000907@ibctech.ca> Message-ID: At Mon, 26 May 2008 18:49:35 -0400, Steve Bertrand wrote: > Is there anyone here who can advise me where in the source tree I would > find the DNS resolver code that performs AAAA/A record lookups, and more > specifically, the fallback to A lookup if AAAA fails? Assuming you're considering getaddrinfo(), see res_queryN() in lib/libc/net/getaddrinfo.c. BTW: "fallback" does not really accurately describe the behavior. When AF_UNPSEC is specified, both AAAA and A queries are issued, whether or not the AAAA query fails. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From jfvogel at gmail.com Tue May 27 19:21:14 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue May 27 19:21:18 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 In-Reply-To: References: Message-ID: <2a41acea0805271221q5015d362w6e07425ee494121b@mail.gmail.com> On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. The FreeBSD fxp driver was not written by Intel and I have had nothing to do with it in my tenure in this position. The real maintainer of that driver should help you.... :) If no one speaks up then we will see again... Jack > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > > > > Regards, > > > > looking forward to hear from you, > > > > Martin > > _______________________________________________ > 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 fox at verio.net Tue May 27 19:46:28 2008 From: fox at verio.net (David DeSimone) Date: Tue May 27 19:46:32 2008 Subject: Dual stack with multiple addresses in rc.conf In-Reply-To: <483C169D.7030304@ibctech.ca> References: <483C169D.7030304@ibctech.ca> Message-ID: <20080527192509.GB8554@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve Bertrand wrote: > > ifconfig_fxp0="inet6 2607:f118::b6 prefixlen 64" > ifconfig_fxp0_alias0="inet6 2607:f118::b7 prefixlen 64" > ifconfig_fxp0="inet 208.70.104.210 255.255.255.248" > ifconfig_fxp0_alias1="inet 208.70.104.211 netmask 255.255.255.255" Your config entry for ifconfig_fxp0 is specified twice, so the latter setting overrides the former. When you have multiple settings to apply, you can put them all in one ifconfig entry, although as Max points out, it is more correct to put IPV6 settings in a separate entry. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIPGAVFSrKRjX5eCoRArqwAJ9G8HZbAgAkElHYDmiSphtDO625VACfSQSs IyyVlcyPju6Xsb+YJEhmpW0= =WMCC -----END PGP SIGNATURE----- From andre at freebsd.org Tue May 27 20:24:25 2008 From: andre at freebsd.org (Andre Oppermann) Date: Tue May 27 20:24:29 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 In-Reply-To: <2a41acea0805271221q5015d362w6e07425ee494121b@mail.gmail.com> References: <2a41acea0805271221q5015d362w6e07425ee494121b@mail.gmail.com> Message-ID: <483C6DF8.8030606@freebsd.org> Jack Vogel wrote: > On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin > wrote: >> Hi ! >> >> >> >> I am in contact with Chris Buechler because of pfSense and we he told me >> to contact Jack Vogel because of some Intel NIC driver problem. > > The FreeBSD fxp driver was not written by Intel and I have had nothing > to do with it in my tenure in this position. > > The real maintainer of that driver should help you.... :) fxp(4) doesn't have a real maintainer anymore. I've sent a nice collection of fxp cards and revisions thereof to Pyun YongHyeon in hope of tricking him to become the future maintainer. He's pretty busy with more recent gigabit cards though and I'm not sure when/if he can assume that role. -- Andre > If no one speaks up then we will see again... > > Jack > >> FreeBSD detects them as fxp cards which is correct, but they do not work >> at all, i tried in ACPI and non-ACPI mode and with enabled ROM and >> disabled ROM and everything, but I cannot get them working... >> >> I always get "fxp0 timeout" or fxpX fort he corresponding card... I read >> it might have something to do with dynamic powersaving mode or else but >> have no clue how to deactivate, there's no option in the ROM for this. >> >> >> >> It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB >> (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x >> ICH4 integrated LAN Int on board. >> >> >> >> Is there anything I can tot o make it work for now or is it a known >> problem or else ? >> >> >> >> Regards, >> >> >> >> looking forward to hear from you, >> >> >> >> Martin >> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 tom at tomjudge.com Tue May 27 20:35:56 2008 From: tom at tomjudge.com (Tom Judge) Date: Tue May 27 20:36:00 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <20080527201331.L65662@maildrop.int.zabbadoz.net> References: <483C51EE.7040700@tomjudge.com> <20080527201331.L65662@maildrop.int.zabbadoz.net> Message-ID: <483C70A9.2060500@tomjudge.com> Bjoern A. Zeeb wrote: > On Tue, 27 May 2008, Tom Judge wrote: > > Hi, > >> Today I looked into why I can not get a traceroute across a IPSec IPIP >> tunnel > > I guess not an IPIP tunnel but just IPsec tunnel mode? > > ... >> Any information about this would be appreciated as I would like to be >> able to do traceroutes across my wan. > > The problem has been well known and is on my todo list. I haven't > checked the relevant code lately but if I remember the problem is not > to be fixed trivially in first place. > > You should get a reply back from your Node B though, just not from > Router B. > > > /bz > Hi Bjoern, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. Do you have any more information on the underlying source of the problem? If so it would help me find the problem. I may setup a small test network to find this problem this evening time permitting. Thanks Tom PS. Could you pm me a link to your RELENG_7 multi ip jail patchs? From bzeeb-lists at lists.zabbadoz.net Tue May 27 20:40:06 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 27 20:40:13 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <483C51EE.7040700@tomjudge.com> References: <483C51EE.7040700@tomjudge.com> Message-ID: <20080527201331.L65662@maildrop.int.zabbadoz.net> On Tue, 27 May 2008, Tom Judge wrote: Hi, > Today I looked into why I can not get a traceroute across a IPSec IPIP tunnel I guess not an IPIP tunnel but just IPsec tunnel mode? ... > Any information about this would be appreciated as I would like to be able to > do traceroutes across my wan. The problem has been well known and is on my todo list. I haven't checked the relevant code lately but if I remember the problem is not to be fixed trivially in first place. You should get a reply back from your Node B though, just not from Router B. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From jfvogel at gmail.com Tue May 27 20:41:34 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue May 27 20:41:40 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 In-Reply-To: References: Message-ID: <2a41acea0805271341w24f42cf4t8c8acdad0c34a20e@mail.gmail.com> Martin, Can you give me a pciconf -l listing please. Jack On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. > > > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > > > > Regards, > > > > looking forward to hear from you, > > > > Martin > > _______________________________________________ > 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 bzeeb-lists at lists.zabbadoz.net Tue May 27 20:45:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 27 20:45:15 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <483C70A9.2060500@tomjudge.com> References: <483C51EE.7040700@tomjudge.com> <20080527201331.L65662@maildrop.int.zabbadoz.net> <483C70A9.2060500@tomjudge.com> Message-ID: <20080527204111.F65662@maildrop.int.zabbadoz.net> On Tue, 27 May 2008, Tom Judge wrote: Hi, > Yes we do indeed see a reply from node b. It is good to here that this is a > known issue. > > The IPSec configuration is a gif ipip tunnel that is then encrypted with > IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. 1) if you do not need the ipip tunnel because you need an interface and "link state changes" only go with the IPsec tunnel mode. 2) If you need the gi tunnel on top and routing, use IPsec transport mode. (ignore the handbook, try to understand it;) > Do you have any more information on the underlying source of the problem? If > so it would help me find the problem. I may setup a small test network to > find this problem this evening time permitting. a test network is not a problem. time is. > PS. Could you pm me a link to your RELENG_7 multi ip jail patchs? check the latest status report at... for the link: http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Tue May 27 20:49:14 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 20:49:22 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <260F636A-8F72-411B-AED9-B029E1964003@mac.com> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> <260F636A-8F72-411B-AED9-B029E1964003@mac.com> Message-ID: <483C73D0.8060709@elischer.org> Marcel Moolenaar wrote: > > On May 27, 2008, at 10:50 AM, Julian Elischer wrote: > >> Marcel Moolenaar wrote: >>> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>>> judging by the bug reports when things get broken there are still a >>>> lot of people connected to the internet via dial up lines in places >>>> off the beaten track, and still a lot of people who when travelling >>>> do use dialup still. Some of these also use mpd. I can not say how >>>> many plan to keep using this in the future but it may be that the >>>> simplest answer is a completely separate sio driver that >>>> just has netgraph hooks. I haven't talked with Ed yet but there >>>> may be may ways to solve this problem. >>> Take a look at uart(4). It has been designed to allow different >>> kernel interfaces. It currently supports TTYs and keyboards. It >>> should not be too hard to have it hook into netgraph. >>> FYI, >> >> >> While this is a good idea on it's own, the difference between >> what that achieves and what a line discipline achieves is that >> a line disciplin is hardware independent and can even be used >> on a virtual device. > > True, but you said: > "... the simplest answer is a completely separate sio driver...". > > This, besides not being true, is just as hardware dependent as > uart(4) is. It seems to me that you've conveniently changed the > subject to match your point of view :-) yep :-) we need to decide if the aim is to support just serial ports or any 'tty'. From xcllnt at mac.com Tue May 27 21:04:28 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 21:04:39 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C73D0.8060709@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> <260F636A-8F72-411B-AED9-B029E1964003@mac.com> <483C73D0.8060709@elischer.org> Message-ID: <32DC950C-7FE6-41D5-8935-60E7A1356EFA@mac.com> On May 27, 2008, at 1:49 PM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> On May 27, 2008, at 10:50 AM, Julian Elischer wrote: >>> Marcel Moolenaar wrote: >>>> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>>>> judging by the bug reports when things get broken there are >>>>> still a >>>>> lot of people connected to the internet via dial up lines in >>>>> places >>>>> off the beaten track, and still a lot of people who when >>>>> travelling >>>>> do use dialup still. Some of these also use mpd. I can not say >>>>> how many plan to keep using this in the future but it may be >>>>> that the simplest answer is a completely separate sio driver that >>>>> just has netgraph hooks. I haven't talked with Ed yet but there >>>>> may be may ways to solve this problem. >>>> Take a look at uart(4). It has been designed to allow different >>>> kernel interfaces. It currently supports TTYs and keyboards. It >>>> should not be too hard to have it hook into netgraph. >>>> FYI, >>> >>> >>> While this is a good idea on it's own, the difference between >>> what that achieves and what a line discipline achieves is that >>> a line disciplin is hardware independent and can even be used >>> on a virtual device. >> True, but you said: >> "... the simplest answer is a completely separate sio driver...". >> This, besides not being true, is just as hardware dependent as >> uart(4) is. It seems to me that you've conveniently changed the >> subject to match your point of view :-) > > > yep :-) > > we need to decide if the aim is to support just serial > ports or any 'tty'. Agreed. ucom(4) is in scope... -- Marcel Moolenaar xcllnt@mac.com From tom at tomjudge.com Tue May 27 21:08:43 2008 From: tom at tomjudge.com (Tom Judge) Date: Tue May 27 21:08:47 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <20080527204111.F65662@maildrop.int.zabbadoz.net> References: <483C51EE.7040700@tomjudge.com> <20080527201331.L65662@maildrop.int.zabbadoz.net> <483C70A9.2060500@tomjudge.com> <20080527204111.F65662@maildrop.int.zabbadoz.net> Message-ID: <483C7858.5000302@tomjudge.com> Bjoern A. Zeeb wrote: > On Tue, 27 May 2008, Tom Judge wrote: > > Hi, > >> Yes we do indeed see a reply from node b. It is good to here that >> this is a known issue. >> >> The IPSec configuration is a gif ipip tunnel that is then encrypted >> with IPSec using esp in tunnel mode as per the ipsec vpn section in >> the handbook. > > 1) if you do not need the ipip tunnel because you need an interface > and "link state changes" only go with the IPsec tunnel mode. > > 2) If you need the gi tunnel on top and routing, use IPsec transport > mode. > > (ignore the handbook, try to understand it;) I have 13 nodes in a parital mesh running ospf for routing. It would not be trivial for me to switch from tunnel to transport mode. Also I have not tested quagga in when the ipsec is in transport mode, and I guess I do need interfaces to use with quagga. I may test fixing this additional overhead, but as they say if it's not broken don't fix it. > >> Do you have any more information on the underlying source of the >> problem? If so it would help me find the problem. I may setup a >> small test network to find this problem this evening time permitting. > > a test network is not a problem. time is. > > Please understand that I was not asking for you to fix this problem just for some pointers into where to start looking. The reason I ask is that you seem to know in what region that the error exists and it would be helpful to me if you could tell me so that I could try to find a solution to the problem myself. At a guess the code that I need to look as it in icmp_error() or further down the icmp transmit path (maybe icmp_reflect or further?). Thanks again. Tom From bzeeb-lists at lists.zabbadoz.net Tue May 27 21:20:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue May 27 21:20:10 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <483C7858.5000302@tomjudge.com> References: <483C51EE.7040700@tomjudge.com> <20080527201331.L65662@maildrop.int.zabbadoz.net> <483C70A9.2060500@tomjudge.com> <20080527204111.F65662@maildrop.int.zabbadoz.net> <483C7858.5000302@tomjudge.com> Message-ID: <20080527211250.M65662@maildrop.int.zabbadoz.net> On Tue, 27 May 2008, Tom Judge wrote: > Bjoern A. Zeeb wrote: >> On Tue, 27 May 2008, Tom Judge wrote: >> >> Hi, >> >>> Yes we do indeed see a reply from node b. It is good to here that this is >>> a known issue. >>> >>> The IPSec configuration is a gif ipip tunnel that is then encrypted with >>> IPSec using esp in tunnel mode as per the ipsec vpn section in the >>> handbook. >> >> 1) if you do not need the ipip tunnel because you need an interface >> and "link state changes" only go with the IPsec tunnel mode. >> >> 2) If you need the gi tunnel on top and routing, use IPsec transport >> mode. >> >> (ignore the handbook, try to understand it;) > > I have 13 nodes in a parital mesh running ospf for routing. It would not be > trivial for me to switch from tunnel to transport mode. Also I have not > tested quagga in when the ipsec is in transport mode, and I guess I do need > interfaces to use with quagga. I may test fixing this additional overhead, > but as they say if it's not broken don't fix it. Ok. So basically you have 12 gif tunnels on each node, if it would be a full mesh. So it's less. So a) you have two endpoints for the gif tunnel which are your Router A, Router B endpoint. So the only thing you would need to secure is your IPIP (gif) tunnel between two nodes (Router A, B). This is what transport mode is for. Running a traceroute, the IP stack would need to send the icmp ttl exceeded packet back via the gif tunnel which then would have to be encrypted. To my memory the problem is that this does not work. You could try to find out at which layer by running tcpdump on the (external) interface and the gif interfaces and if you have enc0 to see if/where the icmp possibly shows up. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From peter at wemm.org Tue May 27 22:30:29 2008 From: peter at wemm.org (Peter Wemm) Date: Tue May 27 22:30:33 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: On Tue, May 27, 2008 at 8:19 AM, Bruce M. Simpson wrote: > Ed Schouten wrote: >>>> >>>> With the word `should' I meant that it would still be possible to >>>> implement multiple line disciplines with the mpsafetty code. But I >>>> really think line disciplines should go. >>>> >>> >>> No, don't bother. Remove the entire "abstraction" of linedisciplines. >>> >> >> Your wish is my command. >> > > Like Julian and Robert said, please don't break Netgraph. > > It still needs to hook into tty at a very low level; and the components such > as Bluetooth which can use ttys for low level stream processing, are built > on Netgraph. > > Both SLIP and PPP can be built using Netgraph. > > Other than that, line disciplines can go away. I think line disciplines should go away as such. It would be nice to have a place to hook into (even linux has this), but the line discipline concept is 30 years stale. IMHO, priority #1 is give ttys the first class treatment they need, then priority #2 is to put in some low level hooks for ng_tty or whatever. It would be hard to come up with a more inconvenient interface than we have now. As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way to pass a block of characters upstream instead of a single character at a time, then we could build this magic into the input routines instead of the device drivers. The bypass is still useful because it saves considerable cycles for raw tty modes, eg: userland ppp, zmodem upload/downloads etc etc. But the logic for it shouldn't have to be scattered all over the tree due to poor line discipline APIs. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From mutex at unixtech.info Wed May 28 00:11:40 2008 From: mutex at unixtech.info (mutex@unixtech.info) Date: Wed May 28 00:11:42 2008 Subject: Atheros 5212 network issues. In-Reply-To: <48383F25.2020309@freebsd.org> References: <52090.74.56.88.177.1211525413.squirrel@webmail.unixtech.info> <48383F25.2020309@freebsd.org> Message-ID: <10739.216.46.1.82.1211933511.squirrel@webmail.unixtech.info> > mutex@unixtech.info wrote: >> Hello! >> I am running FreeBSD 7.0 stable. I am having speed issues that I >> was >> not experiencing before when I was running 6.3 stable. >> >> My wireless connection is now unstable and not as much consistent as it >> was before. The wired connection is as usual ~7000kb/up and 800kb/down. >> >> Each test (~20 per day during 5 days) I did was on a 10 second interval, >> speed is fluctuating from ~80kb to ~4000kb down and ~80kb to ~300kb up >> and >> some tests return both download and upload to be very low. >> >> Also, one test can return 300kb down and 80kb up when next one 10 >> seconds >> later returns 80kb down and 300kb up. >> >> Latency is fluctuating as well. >> >> I tried to use another channel, swap disk and wireless card to another >> machine, cvsup and upgrade again. >> >> I didn't changed network settings, firewall rules, and my hostapd >> config. >> >> Here are some more informations on my hardware: >> >> FreeBSD 7.0-STABLE #0: Mon May 19 23:10:53 EDT 2008 >> mutex@xxxxxxx:/usr/obj/usr/src/sys/MUTEX >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.91-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 >> Features=0x3febfbff >> real memory = 805240832 (767 MB) >> avail memory = 774049792 (738 MB) >> ACPI APIC Table: >> ioapic0 irqs 0-23 on motherboard >> wlan: mac acl policy registered >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> 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 0x4008-0x400b on acpi0 >> cpu0: on acpi0 >> p4tcc0: on cpu0 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> pcib0: port 0xcf8-0xcff,0x4000-0x40bf on acpi0 >> pci0: on pcib0 >> agp0: on hostb0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem >> 0xe0000000-0xe0ffffff,0xd8000000-0xdfffffff irq 16 at device 0.0 on pci1 >> uhci0: port 0xd800-0xd81f >> irq >> 16 at device 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> uhci0: [ITHREAD] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port 0xd000-0xd01f >> irq >> 19 at device 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> uhci1: [ITHREAD] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port 0xd400-0xd41f >> irq >> 18 at device 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> uhci2: [ITHREAD] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> ehci0: mem >> 0xe4000000-0xe40003ff irq 23 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb3: EHCI version 1.0 >> usb3: companion controllers, 2 ports each: usb0 usb1 usb2 >> usb3: on ehci0 >> usb3: USB revision 2.0 >> uhub3: on usb3 >> uhub3: 6 ports with 6 removable, self powered >> pcib2: at device 30.0 on pci0 >> pci2: on pcib2 >> fxp0: port 0xc000-0xc03f mem >> 0xe3050000-0xe3050fff,0xe3020000-0xe303ffff irq 18 at device 0.0 on pci2 >> miibus0: on fxp0 >> inphy0: PHY 1 on miibus0 >> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp0: Ethernet address: 00:02:b3:b6:af:59 >> fxp0: [ITHREAD] >> ath0: mem 0xe3040000-0xe304ffff irq 21 at device 1.0 on >> pci2 >> ath0: [ITHREAD] >> ath0: using obsoleted if_watchdog interface >> ath0: Ethernet address: 00:14:a5:0d:c0:91 >> ath0: mac 10.5 phy 6.1 radio 6.3 >> fxp1: port 0xc400-0xc43f mem >> 0xe3052000-0xe3052fff,0xe3000000-0xe301ffff irq 22 at device 2.0 on pci2 >> miibus1: on fxp1 >> inphy1: PHY 1 on miibus1 >> inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp1: Ethernet address: 00:02:b3:b6:af:09 >> fxp1: [ITHREAD] >> vr0: port 0xc800-0xc8ff mem >> 0xe3051000-0xe30510ff irq 16 at device 3.0 on pci2 >> vr0: Quirks: 0x0 >> vr0: Revision: 0x43 >> miibus2: on vr0 >> ukphy0: PHY 8 on miibus2 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> vr0: Ethernet address: 00:50:ba:18:ff:5f >> vr0: [ITHREAD] >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> pci0: at device 31.5 (no driver attached) >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >> acpi0 >> fdc0: [FILTER] >> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on >> acpi0 >> sio0: type 16550A >> sio0: [FILTER] >> sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 >> sio1: type 16550A >> sio1: [FILTER] >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> pmtimer0 on isa0 >> orm0: at iomem 0xc0000-0xcc7ff pnpid ORM0000 on isa0 >> ppc0: at port 0x378-0x37f irq 7 on isa0 >> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> ppbus0: on ppc0 >> ppbus0: [ITHREAD] >> plip0: on ppbus0 >> lpt0: on ppbus0 >> lpt0: Interrupt-driven port >> ppi0: on ppbus0 >> ppc0: [GIANT-LOCKED] >> ppc0: [ITHREAD] >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >> isa0 >> Timecounter "TSC" frequency 1716911056 Hz quality 800 >> Timecounters tick every 1.000 msec >> ad1: 19073MB at ata0-slave UDMA100 >> acd0: CDROM at ata1-master PIO4 >> Trying to mount root from ufs:/dev/ad1s1a >> >> pciconf -lv | grep ath >> ath0@pci0:2:1:0: class=0x020000 card=0x000c17f9 chip=0x001b168c >> rev=0x01 hdr=0x00 >> >> athstats >> 36879 data frames received >> 50372 data frames transmit >> 135 tx frames with an alternate rate >> 3508 long on-chip tx retries >> 286 tx failed 'cuz too many retries >> 18M current transmit rate >> 1496 tx management frames >> 949 tx frames discarded prior to association >> 7427 tx frames with no ack marked >> 42411 tx frames with short preamble >> 76570 rx failed 'cuz of bad CRC >> 1980968 rx failed 'cuz of PHY err >> 1762216 OFDM timing >> 3 OFDM restart >> 218713 CCK timing >> 36 CCK restart >> 117021 beacons transmitted >> 420 periodic calibrations >> 55 rssi of last ack >> 29 avg recv rssi >> -96 rx noise floor >> 164 switched default/rx antenna >> Antenna profile: >> [1] tx 25569 rx 36157 >> [2] tx 24598 rx 36925 >> >> ifconfig: >> ath0: flags=8843 metric 0 mtu >> 2290 >> ether 00:14:a5:0d:c0:91 >> inet 10.0.3.1 netmask 0xffffff00 broadcast 10.0.3.255 >> media: IEEE 802.11 Wireless Ethernet autoselect >> (autoselect ) >> status: associated >> ssid mutex channel 1 (2412 Mhz 11g) bssid 00:14:a5:0d:c0:91 >> authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP >> 3:128-bit >> txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 >> roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 >> >> sysctl: >> net.wlan.0.%parent: ath0 >> debug.disablefullpath: 0 >> hw.ath.hal.swba_backoff: 0 >> hw.ath.hal.sw_brt: 10 >> hw.ath.hal.dma_brt: 2 >> hw.ath.hal.version: 0.9.20.3 >> hw.ath.txbuf: 200 >> hw.ath.rxbuf: 40 >> hw.ath.regdomain: 0 >> hw.ath.countrycode: 0 >> hw.ath.xchanmode: 1 >> hw.ath.outdoor: 1 >> hw.ath.calibrate: 30 >> user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: >> dev.npx.0.%desc: math processor >> dev.ath.0.%desc: Atheros 5212 >> dev.ath.0.%driver: ath >> dev.ath.0.%location: slot=1 function=0 >> dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x17f9 >> subdevice=0x000c cl >> ass=0x020000 >> dev.ath.0.%parent: pci2 >> dev.ath.0.smoothing_rate: 95 >> dev.ath.0.sample_rate: 10 >> dev.ath.0.countrycode: 0 >> dev.ath.0.regdomain: 16 >> dev.ath.0.slottime: 9 >> dev.ath.0.acktimeout: 48 >> dev.ath.0.ctstimeout: 48 >> dev.ath.0.softled: 0 >> dev.ath.0.ledpin: 0 >> dev.ath.0.ledon: 0 >> dev.ath.0.ledidle: 2700 >> dev.ath.0.txantenna: 0 >> dev.ath.0.rxantenna: 2 >> dev.ath.0.diversity: 0 >> dev.ath.0.txintrperiod: 5 >> dev.ath.0.diag: 0 >> dev.ath.0.tpscale: 0 >> dev.ath.0.tpc: 0 >> dev.ath.0.tpack: 63 >> dev.ath.0.tpcts: 63 >> dev.ath.0.fftxqmin: 2 >> dev.ath.0.fftxqmax: 50 >> dev.ath.0.monpass: 24 >> >> /etc/sysctl.conf *I didn't changed any other sysctl option* >> net.inet.ip.forwarding=1 >> >> Lines added to Generic kernel: >> >> # PF >> device pf >> device pflog >> device pfsync >> >> # ALTQ >> options ALTQ >> options ALTQ_CBQ # Class Bases Queuing (CBQ) >> options ALTQ_RED # Random Early Detection (RED) >> options ALTQ_RIO # RED In/Out >> options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) >> options ALTQ_PRIQ # Priority Queuing (PRIQ) >> options ALTQ_NOPCC # Required for SMP build >> >> >> Please help me troubleshoot and resolve this issue. >> >> > Simplify your configuration. First remove ALTQ and any packet > processing in the tx/rx paths (e.g. pf). If that doesn't resolve the > issues you are seeing try to isolate the problem to rx or tx by running > unidirectional tests. Finally, if this is related to tx rate control > then fix the tx rate to eliminate that variable. > > If you cannot resolve the issue please file a PR. Be sure to provide > sufficient information for someone to exactly duplicate your setup. > > Sam > Hi again, I just would like to say that I forgot to mention that removing altq rules in pf.conf was my very first test I did as well as allowing all wireless traffic on each side. I did some unidirectional tests and it looks like my issue is to upload rather than download. I will continue on my own and file a PR as well if I don't find a solution to it. Thanks, Mutex pub 4096R/C4CE4832 2007-02-01 Key fingerprint = 8DAE C29D 44B7 CA85 28A3 AF0A BE37 B1E2 C4CE 4832 From julian at elischer.org Wed May 28 00:21:43 2008 From: julian at elischer.org (Julian Elischer) Date: Wed May 28 00:21:47 2008 Subject: ICMP Error transmission/response over IPSec tunnels In-Reply-To: <20080527211250.M65662@maildrop.int.zabbadoz.net> References: <483C51EE.7040700@tomjudge.com> <20080527201331.L65662@maildrop.int.zabbadoz.net> <483C70A9.2060500@tomjudge.com> <20080527204111.F65662@maildrop.int.zabbadoz.net> <483C7858.5000302@tomjudge.com> <20080527211250.M65662@maildrop.int.zabbadoz.net> Message-ID: <483CA59C.9020608@elischer.org> Bjoern A. Zeeb wrote: > On Tue, 27 May 2008, Tom Judge wrote: > >> Bjoern A. Zeeb wrote: >>> On Tue, 27 May 2008, Tom Judge wrote: >>> >>> Hi, >>> >>>> Yes we do indeed see a reply from node b. It is good to here that >>>> this is a known issue. >>>> >>>> The IPSec configuration is a gif ipip tunnel that is then encrypted >>>> with IPSec using esp in tunnel mode as per the ipsec vpn section in >>>> the handbook. >>> >>> 1) if you do not need the ipip tunnel because you need an interface >>> and "link state changes" only go with the IPsec tunnel mode. >>> >>> 2) If you need the gi tunnel on top and routing, use IPsec transport >>> mode. >>> >>> (ignore the handbook, try to understand it;) >> >> I have 13 nodes in a parital mesh running ospf for routing. It would >> not be trivial for me to switch from tunnel to transport mode. Also I >> have not tested quagga in when the ipsec is in transport mode, and I >> guess I do need interfaces to use with quagga. I may test fixing this >> additional overhead, but as they say if it's not broken don't fix it. > > Ok. So basically you have 12 gif tunnels on each node, if it would be > a full mesh. So it's less. > > So a) you have two endpoints for the gif tunnel which are your Router > A, Router B endpoint. So the only thing you would need to secure is > your IPIP (gif) tunnel between two nodes (Router A, B). This is what > transport mode is for. > > Running a traceroute, the IP stack would need to send the icmp ttl > exceeded packet back via the gif tunnel which then would have to be > encrypted. > > To my memory the problem is that this does not work. > > You could try to find out at which layer by running tcpdump on the > (external) interface and the gif interfaces and if you have enc0 to > see if/where the icmp possibly shows up. I did this by running ng_iface into ng_ksocket(UDP) and using transport mode for all the UDP packets I had scripts to do it all, but unfortunately it was at a previous company. I allocated a number to each site from 1 to 8 and the endpoints inside the tunnels were 10.42.ME.YOU 10.42.YOU.ME. The scripts were identical on each machine, and to add a new machine I just added it to the list in the script, distributed the new script, and ran it again on each machine.. > > /bz > From pyunyh at gmail.com Wed May 28 00:35:35 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed May 28 00:35:42 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 In-Reply-To: References: Message-ID: <20080528003526.GB63696@cdnetworks.co.kr> On Tue, May 27, 2008 at 08:22:56PM +0200, Fuchs, Martin wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. > > > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > Since there are too many variants of fxp hardwares it would be even better to post the output of the following. o pciconf -lcv o dmesg output related with fxp(4) o devinfo -rv | grep oui o vmstat -i > > > Regards, > > > > looking forward to hear from you, > > > > Martin -- Regards, Pyun YongHyeon From linimon at FreeBSD.org Wed May 28 03:50:28 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed May 28 03:50:30 2008 Subject: kern/124021: [ip6] [panic] page fault in nd6_output() Message-ID: <200805280350.m4S3oRPD091416@freefall.freebsd.org> Old Synopsis: page fault in nd6_output() New Synopsis: [ip6] [panic] page fault in nd6_output() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 28 03:49:54 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124021 From ed at 80386.nl Wed May 28 06:27:13 2008 From: ed at 80386.nl (Ed Schouten) Date: Wed May 28 06:27:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: <20080528062542.GR64397@hoeg.nl> Hello Peter, * Peter Wemm wrote: > As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way > to pass a block of characters upstream instead of a single character > at a time, then we could build this magic into the input routines > instead of the device drivers. I still haven't had time to add the CAN_BYPASS_L_RINT functionality back. I was thinking about adding the actual copying to the buffers inside the TTY layer, which means we can finally remove all that redundant code from the drivers. But this is still on my TODO list. ;-) -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080528/3d894b47/attachment.pgp From stefan.lambrev at moneybookers.com Wed May 28 10:19:12 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed May 28 10:19:16 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <9a542da30805271114w6ad82569m43d89c4cd03a76fc@mail.gmail.com> References: <1211891010.00075594.1211880013@10.7.7.3> <1211894613.00075634.1211884201@10.7.7.3> <1211901827.00075710.1211890802@10.7.7.3> <483C4636.7080608@mavhome.dp.ua> <483C4D48.6020106@moneybookers.com> <9a542da30805271114w6ad82569m43d89c4cd03a76fc@mail.gmail.com> Message-ID: <483D319B.7030303@moneybookers.com> Ermal Lu?i wrote: > On Tue, May 27, 2008 at 8:04 PM, Stefan Lambrev > wrote: > >> Greetings, >> >> Alexander Motin wrote: >> >>> Stefan Lambrev wrote: >>> >>>>> Yes, You can with ng_tcpmss >>>>> >>>> Isn't it doable only with ipfw/divert when using ng_tcpmss? >>>> I have and some concerns about performance too .. >>>> >>> There are several ways to inject packet to ng_tcpmss: >>> - ipfw + divert + ng_ksocket. It should be faster then usual user-level >>> implementation >>> - ipfw + netgraph as described in ng_tcpmss(4) >>> - use ng_tcpmss directly in some complicated netgraph setup. For example, >>> mpd is able to use it. This is probably the fastest and easiest way, but >>> only for some setups. >>> >> Thanks for all ideas. >> I think I'll try the route -mtu feature. >> Looks like easier for implementation and testing. :) >> Anyway it will be good if we have such feature in the base system. >> It shouldn't be very difficult? :) >> >> -- >> > > Actually converting ng_tcpmss to pfil(9) should be easy. > I'm thinking about adding additional checks in tcp_mss() and tcp_mssopt() - both in sys/netinet/tcp_input.c plus two sysctl entries for max mss and max mss IPv6. Does it sound like a reasonable solution or I'm missing something? P.S. One of the things that bothers me is that pf uses it's own pf_get_mss() and pf_calc_mss() and they should be fixed accordingly? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From andre at freebsd.org Wed May 28 11:10:06 2008 From: andre at freebsd.org (Andre Oppermann) Date: Wed May 28 11:10:09 2008 Subject: Adjust Maximum Segment Size? In-Reply-To: <483D319B.7030303@moneybookers.com> References: <1211891010.00075594.1211880013@10.7.7.3> <1211894613.00075634.1211884201@10.7.7.3> <1211901827.00075710.1211890802@10.7.7.3> <483C4636.7080608@mavhome.dp.ua> <483C4D48.6020106@moneybookers.com> <9a542da30805271114w6ad82569m43d89c4cd03a76fc@mail.gmail.com> <483D319B.7030303@moneybookers.com> Message-ID: <483D3D8D.2030907@freebsd.org> Stefan Lambrev wrote: > Ermal Lu?i wrote: >> On Tue, May 27, 2008 at 8:04 PM, Stefan Lambrev >> wrote: >> >>> Greetings, >>> >>> Alexander Motin wrote: >>> >>>> Stefan Lambrev wrote: >>>> >>>>>> Yes, You can with ng_tcpmss >>>>>> >>>>> Isn't it doable only with ipfw/divert when using ng_tcpmss? >>>>> I have and some concerns about performance too .. >>>>> >>>> There are several ways to inject packet to ng_tcpmss: >>>> - ipfw + divert + ng_ksocket. It should be faster then usual >>>> user-level >>>> implementation >>>> - ipfw + netgraph as described in ng_tcpmss(4) >>>> - use ng_tcpmss directly in some complicated netgraph setup. For >>>> example, >>>> mpd is able to use it. This is probably the fastest and easiest way, >>>> but >>>> only for some setups. >>>> >>> Thanks for all ideas. >>> I think I'll try the route -mtu feature. >>> Looks like easier for implementation and testing. :) >>> Anyway it will be good if we have such feature in the base system. >>> It shouldn't be very difficult? :) >>> >>> -- >>> >> >> Actually converting ng_tcpmss to pfil(9) should be easy. >> > I'm thinking about adding additional checks in tcp_mss() and > tcp_mssopt() - both in sys/netinet/tcp_input.c > plus two sysctl entries for max mss and max mss IPv6. > Does it sound like a reasonable solution or I'm missing something? Doesn't make sense. You have to differentiate between selecting the MSS for a connection the terminates/originates locally vs. one that just passed through the machine. Local connections observe the MTU setting on the interface and the routing table entries (tcp_maxmtu()). So you can either reduce the interface MTU or adjust the MTU on your default route and everything will work as expected. There is no need for yet another sysctl or other extensions to tcp_mssopt(). For connections passing through the machine we don't have a direct equivalent to Cisco IOS ip tcp mss-fixup. Only work-arounds via some other methods, daemon or kernel module exist. It would make sense to implement that as a option into ipfw (and pf via OpenBSD). > P.S. One of the things that bothers me is that pf uses it's own > pf_get_mss() and pf_calc_mss() > and they should be fixed accordingly? -- Andre From iaccounts at ibctech.ca Wed May 28 12:34:17 2008 From: iaccounts at ibctech.ca (Steve Bertrand) Date: Wed May 28 12:34:20 2008 Subject: IPv6/IPv4 DNS resolver source In-Reply-To: References: <483B3E7F.8000907@ibctech.ca> Message-ID: <483D50D1.8000707@ibctech.ca> >> Is there anyone here who can advise me where in the source tree I would >> find the DNS resolver code that performs AAAA/A record lookups, and more >> specifically, the fallback to A lookup if AAAA fails? > > Assuming you're considering getaddrinfo(), see res_queryN() in > lib/libc/net/getaddrinfo.c. > > BTW: "fallback" does not really accurately describe the behavior. > When AF_UNPSEC is specified, both AAAA and A queries are issued, > whether or not the AAAA query fails. Thank you for the info. I did not know that little tidbit. I've got my first IPv6 DNS, mail, web etc server up and running now, and before I think about migrating the actual production network, I want to perform some extensive testing, all the while being familiar with the framework of the resolver itself, and how to overcome particular DNS/connectivity issues (if possible). ie: I want to learn more about how DNS and IP react in the event I lose my IPv6 BGP peers (or IPv4 peers), and also write in some debug log writing into the resolver if certain events trigger. Steve From iaccounts at ibctech.ca Wed May 28 12:39:46 2008 From: iaccounts at ibctech.ca (Steve Bertrand) Date: Wed May 28 12:39:48 2008 Subject: Dual stack with multiple addresses in rc.conf In-Reply-To: <20080527192509.GB8554@verio.net> References: <483C169D.7030304@ibctech.ca> <20080527192509.GB8554@verio.net> Message-ID: <483D5219.1020802@ibctech.ca> David DeSimone wrote: > Steve Bertrand wrote: >> ifconfig_fxp0="inet6 2607:f118::b6 prefixlen 64" >> ifconfig_fxp0_alias0="inet6 2607:f118::b7 prefixlen 64" >> ifconfig_fxp0="inet 208.70.104.210 255.255.255.248" >> ifconfig_fxp0_alias1="inet 208.70.104.211 netmask 255.255.255.255" > > Your config entry for ifconfig_fxp0 is specified twice, so the latter > setting overrides the former. When you have multiple settings to apply, > you can put them all in one ifconfig entry, although as Max points out, > it is more correct to put IPV6 settings in a separate entry. The example above was just that...I had tried numerous possibilities, however what I neglected to do was RTFM, which is unlike myself. Anyway, thanks for the responses. I haven't put the config into place yet, but will today. Regards, Steve From ml at netfence.it Wed May 28 15:28:46 2008 From: ml at netfence.it (Andrea Venturoli) Date: Wed May 28 15:28:51 2008 Subject: Testing lagg Message-ID: <483D7A22.9000206@netfence.it> Hello. I've got a new box which features two gigabit ports and I though I'd try lagg with LACP. On the box I put the following in /etc/rc.conf: ifconfig_em0="up" ifconfig_em1="up" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.101 netmask 255.255.255.0" Then I aggregated the ports on the switch (3com). This seems to work fine, although I see a 30 seconds delay from the moment a network cable is unplugged and the moment the network works again. Is this normal? Can this time be reduced? Any other hint or gotcha? bye & Thanks av. From gpalmer at freebsd.org Wed May 28 15:48:02 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Wed May 28 15:48:04 2008 Subject: Testing lagg In-Reply-To: <483D7A22.9000206@netfence.it> References: <483D7A22.9000206@netfence.it> Message-ID: <20080528154800.GF1142@in-addr.com> On Wed, May 28, 2008 at 05:28:34PM +0200, Andrea Venturoli wrote: > Hello. > > I've got a new box which features two gigabit ports and I though I'd try > lagg with LACP. > > On the box I put the following in /etc/rc.conf: > > ifconfig_em0="up" > ifconfig_em1="up" > ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.101 > netmask 255.255.255.0" > > > Then I aggregated the ports on the switch (3com). > > > This seems to work fine, although I see a 30 seconds delay from the > moment a network cable is unplugged and the moment the network works again. > Is this normal? Can this time be reduced? > Any other hint or gotcha? Does the switch have spanning tree enabled? Regards, Gary From dougb at FreeBSD.org Wed May 28 17:48:45 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed May 28 17:48:49 2008 Subject: IPv6/IPv4 DNS resolver source In-Reply-To: <483D50D1.8000707@ibctech.ca> References: <483B3E7F.8000907@ibctech.ca> <483D50D1.8000707@ibctech.ca> Message-ID: <483D947C.6020906@FreeBSD.org> Steve Bertrand wrote: >>> Is there anyone here who can advise me where in the source tree I >>> would find the DNS resolver code that performs AAAA/A record lookups, >>> and more specifically, the fallback to A lookup if AAAA fails? >> >> Assuming you're considering getaddrinfo(), see res_queryN() in >> lib/libc/net/getaddrinfo.c. >> >> BTW: "fallback" does not really accurately describe the behavior. >> When AF_UNPSEC is specified, both AAAA and A queries are issued, >> whether or not the AAAA query fails. > > Thank you for the info. I did not know that little tidbit. > > I've got my first IPv6 DNS, mail, web etc server up and running now, and > before I think about migrating the actual production network, I want to > perform some extensive testing, all the while being familiar with the > framework of the resolver itself, and how to overcome particular > DNS/connectivity issues (if possible). > > ie: I want to learn more about how DNS and IP react in the event I lose > my IPv6 BGP peers (or IPv4 peers), and also write in some debug log > writing into the resolver if certain events trigger. If you lose your IPv6 connectivity (or worse, if it's up but not performing well) you will run into problems with your end users that have IPv6 enabled because when it's on it is generally tried first. Since more and more operating systems come with IPv6 enabled by default, and more and more networks worldwide are enabling it for their users, this can be a problem. In an ideal world you'll want to be able to monitor your IPv6 connectivity from key points outside your network, and alert $SOMEONE if it isn't working properly. If it's a prolonged outage you will probably want to update DNS to withdraw your AAAA records, and at least to start with you'll want them to have a fairly short TTL when they are in the zone. Although it is not popular with the "IPv6 do or die!" crowd, one procedure I recommend in the early stages of IPv6 deployment is to set up nameservers that only listen on IPv6 addresses, and only add the AAAA records to the zone files on those nameservers. (The AAAA records for the nameservers will have to be in all zone files of course.) At least that way you will be sure that the people you serve AAAA records to have _some_ kind of IPv6 connectivity, and that your end is at least up before sending your end users there. This is not a foolproof system because there is not necessarily a 1-to-1 relationship between the network that the resolver is on and the network the user is on, but for the vast majority it will be, and it's a lot better when rolling out to take baby steps till you have found all/most of the land mines. Caveats aside, google has taken a big step into the IPv6 arena giving access to their search engine through http://ipv6.google.com/, and they have said that once they get the bugs shaken out there they plan to go a lot bigger with IPv6 access to their network. This is widely recognized as a tipping point in the "must have v6 content to justify wider v6 rollout on the consumer side" debate, so anyone not making plans for IPv6 on their own network now is already one step behind the curve. There is an excellent list that covers IPv6 operational issues, http://lists.cluenet.de/mailman/listinfo/ipv6-ops You will probably want to search the archives there as well. hth, Doug -- This .signature sanitized for your protection From dfr at rabson.org Wed May 28 20:14:38 2008 From: dfr at rabson.org (Doug Rabson) Date: Wed May 28 20:14:41 2008 Subject: nfs buildworld blocked by rpc.lockd ? In-Reply-To: References: Message-ID: <5E032C03-6857-4E7F-9C3D-B5C06A79934C@rabson.org> On 28 May 2008, at 20:57, Arno J. Klaassen wrote: > > Hello, > > my buildworld on a 7-stable-amd64 blocks on the following line : > > TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/ > termcap.src < /files/bsd/src7/share/termcap/reorder > > ex(1) stays in lockd state, and is unkillable, either by Ctl-C or > kill -9 > > /files/bsd is nfs-mounted as follows : > > push:/raid1/bsd /files/bsd nfs > rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 > > I can provide tcpdumps on server and client if helpful. I would very much like to see tcpdumps (from either client or server). This problem is often caused by the fact that unless you use the '-p' flag, rpc.lockd isn't wired down to any particular port number. Since it is started at boot time, it will usually end up with the same one each time but the new kernel implementation in 7-stable typically ends up with a different port number to the old userland implementation. Quirks of the locking protocol make it difficult for the server to notice this without a lengthy timeout. Workarounds include using '-p' to wire it down to a consistent port (port 4045 is reserved for this) or restarting rpc.lockd on the server. From thompsa at FreeBSD.org Wed May 28 20:16:03 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed May 28 20:16:08 2008 Subject: Testing lagg In-Reply-To: <483D7A22.9000206@netfence.it> References: <483D7A22.9000206@netfence.it> Message-ID: <20080528201723.GD51548@citylink.fud.org.nz> On Wed, May 28, 2008 at 05:28:34PM +0200, Andrea Venturoli wrote: > Hello. > > I've got a new box which features two gigabit ports and I though I'd try > lagg with LACP. > > On the box I put the following in /etc/rc.conf: > > ifconfig_em0="up" > ifconfig_em1="up" > ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.101 > netmask 255.255.255.0" > > > Then I aggregated the ports on the switch (3com). > > > This seems to work fine, although I see a 30 seconds delay from the moment > a network cable is unplugged and the moment the network works again. > Is this normal? Can this time be reduced? > Any other hint or gotcha? Can you post a verbose ifconfig (-v) for hte before and after. It will show the lag identifiers which may help diagnose this. Andrew From arno at heho.snv.jussieu.fr Wed May 28 20:25:57 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Wed May 28 20:26:03 2008 Subject: nfs buildworld blocked by rpc.lockd ? Message-ID: Hello, my buildworld on a 7-stable-amd64 blocks on the following line : TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/termcap.src < /files/bsd/src7/share/termcap/reorder ex(1) stays in lockd state, and is unkillable, either by Ctl-C or kill -9 /files/bsd is nfs-mounted as follows : push:/raid1/bsd /files/bsd nfs rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 I can provide tcpdumps on server and client if helpful. Thanx, Arno From oberman at es.net Wed May 28 22:35:35 2008 From: oberman at es.net (Kevin Oberman) Date: Wed May 28 22:35:42 2008 Subject: IPv6/IPv4 DNS resolver source In-Reply-To: Your message of "Wed, 28 May 2008 10:21:00 PDT." <483D947C.6020906@FreeBSD.org> Message-ID: <20080528223530.1216C4501D@ptavv.es.net> > Date: Wed, 28 May 2008 10:21:00 -0700 > From: Doug Barton > Sender: owner-freebsd-net@freebsd.org > > Steve Bertrand wrote: > >>> Is there anyone here who can advise me where in the source tree I > >>> would find the DNS resolver code that performs AAAA/A record lookups, > >>> and more specifically, the fallback to A lookup if AAAA fails? > >> > >> Assuming you're considering getaddrinfo(), see res_queryN() in > >> lib/libc/net/getaddrinfo.c. > >> > >> BTW: "fallback" does not really accurately describe the behavior. > >> When AF_UNPSEC is specified, both AAAA and A queries are issued, > >> whether or not the AAAA query fails. > > > > Thank you for the info. I did not know that little tidbit. > > > > I've got my first IPv6 DNS, mail, web etc server up and running now, and > > before I think about migrating the actual production network, I want to > > perform some extensive testing, all the while being familiar with the > > framework of the resolver itself, and how to overcome particular > > DNS/connectivity issues (if possible). > > > > ie: I want to learn more about how DNS and IP react in the event I lose > > my IPv6 BGP peers (or IPv4 peers), and also write in some debug log > > writing into the resolver if certain events trigger. > > If you lose your IPv6 connectivity (or worse, if it's up but not > performing well) you will run into problems with your end users that > have IPv6 enabled because when it's on it is generally tried first. > Since more and more operating systems come with IPv6 enabled by > default, and more and more networks worldwide are enabling it for > their users, this can be a problem. > > In an ideal world you'll want to be able to monitor your IPv6 > connectivity from key points outside your network, and alert $SOMEONE > if it isn't working properly. If it's a prolonged outage you will > probably want to update DNS to withdraw your AAAA records, and at > least to start with you'll want them to have a fairly short TTL when > they are in the zone. > > Although it is not popular with the "IPv6 do or die!" crowd, one > procedure I recommend in the early stages of IPv6 deployment is to set > up nameservers that only listen on IPv6 addresses, and only add the > AAAA records to the zone files on those nameservers. (The AAAA records > for the nameservers will have to be in all zone files of course.) At > least that way you will be sure that the people you serve AAAA records > to have _some_ kind of IPv6 connectivity, and that your end is at > least up before sending your end users there. This is not a foolproof > system because there is not necessarily a 1-to-1 relationship between > the network that the resolver is on and the network the user is on, > but for the vast majority it will be, and it's a lot better when > rolling out to take baby steps till you have found all/most of the > land mines. While this idea makes a bit of sense, the single most popular OS for the desktop is Windows XP and will not issue IPv6 DNS queries. While XP runs IPv6 just fine, all name resolution is over V4, so if people do what you suggest, they will always use IPv4. You will see traffic from MacOS, Unix and Vista, but that is a fairly small part of the end-user wor