Re: kern/153255: 8.2-PRERELEASE repeatable kernel panic under heavy network load
Synopsis: 8.2-PRERELEASE repeatable kernel panic under heavy network load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Dec 18 09:43:17 UTC 2010 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=153255 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bsnmp/snmpmod.h: #include is missed
Hi, bsnmp/snmpmod.h uses SLIST but does not includes . This breaks net-mgmt/bsnmp-ucd port (ports/153153). Could somebody look at the attached patch? -- Mikolaj Golub Index: contrib/bsnmp/snmpd/snmpmod.h === --- contrib/bsnmp/snmpd/snmpmod.h (revision 216439) +++ contrib/bsnmp/snmpd/snmpmod.h (working copy) @@ -33,6 +33,7 @@ #ifndef snmpmod_h_ #define snmpmod_h_ +#include #include #include #include ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bsnmp/snmpmod.h: #include is missed
On Sat, Dec 18, 2010 at 12:48:38PM +0200, Mikolaj Golub wrote: > Hi, > > bsnmp/snmpmod.h uses SLIST but does not includes . This breaks > net-mgmt/bsnmp-ucd port (ports/153153). > > Could somebody look at the attached patch? , as well as should be included before other headers. pgpRbdfAfHJiQ.pgp Description: PGP signature
Re: bsnmp/snmpmod.h: #include is missed
On Sat, 18 Dec 2010 13:03:58 +0200 Kostik Belousov wrote: KB> On Sat, Dec 18, 2010 at 12:48:38PM +0200, Mikolaj Golub wrote: >> Hi, >> >> bsnmp/snmpmod.h uses SLIST but does not includes . This breaks >> net-mgmt/bsnmp-ucd port (ports/153153). >> >> Could somebody look at the attached patch? KB> , as well as should be included before KB> other headers. Thanks. Overlooked this :-). -- Mikolaj Golub Index: contrib/bsnmp/snmpd/snmpmod.h === --- contrib/bsnmp/snmpd/snmpmod.h (revision 216439) +++ contrib/bsnmp/snmpd/snmpmod.h (working copy) @@ -34,6 +34,7 @@ #define snmpmod_h_ #include +#include #include #include #include ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bsnmp/snmpmod.h: #include is missed
On Sat, Dec 18, 2010 at 1:03 PM, Kostik Belousov wrote: > On Sat, Dec 18, 2010 at 12:48:38PM +0200, Mikolaj Golub wrote: >> Hi, >> >> bsnmp/snmpmod.h uses SLIST but does not includes . This breaks >> net-mgmt/bsnmp-ucd port (ports/153153). >> >> Could somebody look at the attached patch? > > , as well as should be included before > other headers. > And the explicit includes of those files should be removed from the sources of the bsnmpd(1) modules, I think. I will put this in SVN along with a couple of other patches I have for bsnmp in my queue. Sorry for not being able to reply sooner after this problem was reported. Also, the bsnmptools port should be marked as obsolete as the tools are now in head. cheers, Shteryana ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bsnmp/snmpmod.h: #include is missed
On 18.12.2010 18:01, Shteryana Shopova wrote: >>> bsnmp/snmpmod.h uses SLIST but does not includes . This breaks >>> net-mgmt/bsnmp-ucd port (ports/153153). >>> >>> Could somebody look at the attached patch? >> >> , as well as should be included before >> other headers. >> > > And the explicit includes of those files should be removed from the > sources of the bsnmpd(1) modules, I think. I will put this in SVN > along with a couple of other patches I have for bsnmp in my queue. > Sorry for not being able to reply sooner after this problem was > reported. Also, the bsnmptools port should be marked as obsolete as > the tools are now in head. I don't think that a port should be marked obsoled due to changes in head. People tend to use releases or STABLE. For now, ports tree support RELENG_7 and RELENG_8, so we should keep POLA until bsnmptool backported to branches and releases with bsnmptool are out. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
lagg/lacp poor traffic distribution
Hi! I've loaded router using two lagg interfaces in LACP mode. lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. lagg1 has no IP address and has two ports (igb0 and igb1) and carry about 1000 dot-q vlans with lots of hosts in each vlan. For lagg1, lagg distributes outgoing traffic over two ports just fine. For lagg0 (untagged ethernet segment with only 2 MAC addresses) less than 0.07% (54Mbit/s max) of traffic goes to em0 and over 99.92% goes to em1, that's bad. That's general traffic of several thousands of customers surfing the web, using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ and found nothing suspicious, it should extract and use srcIP/dstIP for hash. How do I debug this problem? Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg/lacp poor traffic distribution
On 19.12.2010 00:35, Eugene Grosbein wrote: > Hi! > > I've loaded router using two lagg interfaces in LACP mode. > lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. > lagg1 has no IP address and has two ports (igb0 and igb1) and carry > about 1000 dot-q vlans with lots of hosts in each vlan. > > For lagg1, lagg distributes outgoing traffic over two ports just fine. > For lagg0 (untagged ethernet segment with only 2 MAC addresses) > less than 0.07% (54Mbit/s max) of traffic goes to em0 Here 7%, not 0.07%. And I forgot to note it's 8.2-PRERELEASE. > and over 99.92% goes to em1, that's bad. > > That's general traffic of several thousands of customers surfing the web, > using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ > and found nothing suspicious, it should extract and use srcIP/dstIP for hash. > > How do I debug this problem? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg/lacp poor traffic distribution
On Dec 18, 2010, at 12:35 PM, Eugene Grosbein wrote: > Hi! > > I've loaded router using two lagg interfaces in LACP mode. > lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. > lagg1 has no IP address and has two ports (igb0 and igb1) and carry > about 1000 dot-q vlans with lots of hosts in each vlan. > > For lagg1, lagg distributes outgoing traffic over two ports just fine. > For lagg0 (untagged ethernet segment with only 2 MAC addresses) > less than 0.07% (54Mbit/s max) of traffic goes to em0 > and over 99.92% goes to em1, that's bad. > > That's general traffic of several thousands of customers surfing the web, > using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ > and found nothing suspicious, it should extract and use srcIP/dstIP for hash. > > How do I debug this problem? > > Eugene Grosbein I'm not familiar with the freebsd implementation but Cisco load balances based on destination Mac address so If everything is headed towards the gateway, they will all go over one link. Check the load balancing algorithm on both sides. I usually balance on src+dst mac. -=Tom > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg/lacp poor traffic distribution
On 19.12.2010 01:31, Thomas Donnelly wrote: > Check the load balancing algorithm on both sides. I usually balance on > src+dst mac. I'm only talking on traffic outgoing from FreeBSD host. Here it needs to be balanced using layer-3 src/dst addresses because src and dst macs are constant here. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update
On Monday 06 December 2010 04:48:03 lini...@freebsd.org wrote: > Old Synopsis: hostapd fails ti authenticate after 2010-11-03 update > New Synopsis: hostapd(8) fails to authenticate after 2010-11-03 update > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Dec 6 03:43:30 UTC 2010 > Responsible-Changed-Why: > Although this was an rpaulo MFC, he is not currently working on this > code; so, assign it to -net. Can you try that with a recent version of head (post-216541) again? I've committed a bunch of changes which should address this issue. Thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg/lacp poor traffic distribution
On 12/18/10 10:35 AM, Eugene Grosbein wrote: Hi! I've loaded router using two lagg interfaces in LACP mode. lagg0 has IP address and two ports (em0 and em1) and carry untagged frames. lagg1 has no IP address and has two ports (igb0 and igb1) and carry about 1000 dot-q vlans with lots of hosts in each vlan. For lagg1, lagg distributes outgoing traffic over two ports just fine. For lagg0 (untagged ethernet segment with only 2 MAC addresses) less than 0.07% (54Mbit/s max) of traffic goes to em0 and over 99.92% goes to em1, that's bad. That's general traffic of several thousands of customers surfing the web, using torrents etc. I've glanced over lagg/lacp sources if src/sys/net/ and found nothing suspicious, it should extract and use srcIP/dstIP for hash. How do I debug this problem? make absolutely sure (by reading the code) tha tyou are correct about the decision code. ancapsulate the function used in a small c or perl or python program. take 100 packets at random run them through the function.. see if you get the same result state at packets to detirmine why. report back Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update
The following reply was made to PR bin/152716; it has been noted by GNATS. From: Bernhard Schmidt To: David Cornejo Cc: freebsd-net@freebsd.org, bug-follo...@freebsd.org Subject: Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update Date: Sat, 18 Dec 2010 21:34:34 +0100 On Monday 06 December 2010 04:48:03 lini...@freebsd.org wrote: > Old Synopsis: hostapd fails ti authenticate after 2010-11-03 update > New Synopsis: hostapd(8) fails to authenticate after 2010-11-03 update > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Dec 6 03:43:30 UTC 2010 > Responsible-Changed-Why: > Although this was an rpaulo MFC, he is not currently working on this > code; so, assign it to -net. Can you try that with a recent version of head (post-216541) again? I've committed a bunch of changes which should address this issue. Thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: nfe_defrag() routine in nividia ethernet driver
On Thu, Dec 16, 2010 at 07:53:16PM -0800, abcde abcde wrote: > Hi, we ported the nvidia ethernet driver to our product.? It's been OK until > recently we?ran into an error condition where packets would get dropped > quietly. > The root cause resides in the nfe_encap() routine, where we call nfe_defrag() > to > try to reduce the length of the mbuf chain to 32, if it's longer than 32. In > the > event the 32 mbufs need more than 32 segments, the subsequent call to > bus_dmamap_load_mbuf_sg() would cause it to return an error then the packet > is > subsequently dropped. > > > My questions are, > > 1. there appears to be a generic m_defrag() routine available, which doesn't > stop at 32 and is used by a couple of other drivers (Intel, Broadcom, to name > a > few). What was the need for a nvidia version of the defrag routine? > As John said, m_defrag(9) is expensive operation. Since all nfe(4) controllers supports multiple TX buffers use m_collapse(9) instead. > 2. The NFE_MAX_SCATTER constant, which limits how many segments can be used, > is > defined to be 32, while the corresponding constants for other drivers are 100 > or > 64 (again Intel or Broadcom). How was the value 32 picked? Anybody knows the > reasoning behind them? > I think all nfe(4) controllers have no limitation on number of segments can be used. However most ethernet controllers targeted to non-server systems are not good at supporting multiple outstanding DMA read operation on the PCIe bus. Even though controller supports multiple DMA read operation it would take more time to fetch a TX frame that is split into long list of mbuf chains than short/single contiguous TX frame. CPU is much faster than controller DMA engine. The magic number 32 was chosen to balance on performance and resource usage. 32 should be large enough to support TSO to send a full 64KB TCP segment. If controller has no TSO capability I would have used 16. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
