Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/144000 net[tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net[ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net[wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net[ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net[gif] bringing gif3 tunnel down causes gif0 tunnel to o kern/143788 net[iwi] wpa_supplicant(8) can't set privacy on iwi inter s kern/143673 net[stf] [request] there should be a way to support multi s kern/143666 net[ip6] [request] PMTU black hole detection not implemen o kern/143627 net[ieee80211] [panic] A bug in ht_send_action_ba_addba c o kern/143622 net[pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net[wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net[ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net[ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net[em] em(4) NIC crashes intermittently o kern/143285 net[em] [regression] jumbo frames broken in 8.0 o kern/143208 net[ipsec] [gif] IPSec over gif interface not working o conf/143079 nethostapd(8) startup missing multi wlan functionality o kern/143074 net[wi]: wi driver triggers panic o kern/143046 net[mxge] [panic] panics since mxge(4) update o kern/143034 net[panic] system reboots itself in tcp code [regression] o kern/142907 net[wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net[hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 netProblem with outgoing connections on interface with mu o kern/142772 net[libc] lla_lookup: new lle malloc failed o kern/142766 net[ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o bin/142547 netwpa_supplicant(8) drops connection on key renegotiatio o kern/142518 net[em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net[em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net[iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net[wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net[em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net[rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 netEtherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net[sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net[sctp] [panic] Own lock on stcb at return from input o kern/141697 net[sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net[rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net[sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 netNetwork Performance has decreased by 30% [regression] o kern/141285 net[em] hangs down/up intel nic during creating vlan o kern/141023 net[carp] CARP arp replays with wrong src mac o kern/140970 net[bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net[ath] [panic] privileged instruction fault o kern/140778 net[em] randomly panic in vlan/em o kern/140742 netrum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net[em] [patch] Fast irq registration in em driver o kern/140684 net[bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net[em] [patch] e1000 driver does not correctly handle mu o kern/140634 net[vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net[ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net[request] implement Lost Retransmission Detection o kern/140567 net[ath] [patch] ath is not worked on my notebook PC o kern/140564 net[wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net[wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net[em] em0: watchdog timeout when communicating to windo o kern/140245 net[ath] [panic] Kernel panic during network activity on o kern/140142 net[ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net[bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net[bce] [arp] ARP not sent through Bridge Firewall with o kern/13
Re: mpd has hung
On Sat, Feb 20, 2010 at 12:04:35PM +, Bjoern A. Zeeb wrote: > On Sat, 20 Feb 2010, Bjoern A. Zeeb wrote: > > > On Fri, 19 Feb 2010, Mikolaj Golub wrote: > > > >> On Thu, 18 Feb 2010 17:32:37 +0200 Nikos Vassiliadis wrote: > >> > >>> On 2/17/2010 3:26 PM, Alexander Shikoff wrote: > Hello All, > > I have mpd 5.3 running on 8.0-RC1 as PPPoE server (now only 5 clients). > Today mpd process hung and I cannot kill it with -9 signal, and I cannot > access it's console via telnet. > > State of process in `top` output is STOP: > 73551 root 2 440 29588K 5692K STOP6 0:32 0.00% mpd5 > > # procstat -kk 73551 > PIDTID COMM TDNAME KSTACK > 73551 100233 mpd5 -mi_switch+0x16f > sleepq_wait+0x42 _cv_wait+0x111 flowtable_flush+0x51 if_detach+0x2f2 > ng_iface_shutdown+0x1e ng_rmnode+0x167 ng_apply_item+0xef7 > ng_snd_item+0x2ce ngc_send+0x1d2 sosend_generic+0x3f6 kern_sendit+0x13d > sendit+0xdc sendto+0x4d syscall+0x1da Xfast_syscall+0xe1 > 73551 100502 mpd5 -mi_switch+0x16f > thread_suspend_switch+0xc6 thread_single+0x1b6 exit1+0x72 sigexit+0x7c > postsig+0x306 ast+0x279 doreti_ast+0x1f > > Is there a way to stop a process without rebooting a whole system? > Thanks in advance! > > P.S. I'm ready for experiments with it before tonight, but I cannot > force system to crash in order to get crash dump right now. > > >>> > >>> It's probably too late now, but are you sure that nobody pressed > >>> CTLR-Z while in the mpd console??? > >>> > >>> CTLR-Z will send SIGSTOP to the process and the process will > >>> stop. While stopped, all processing stops(including receiving > >>> SIGKILL, you cannot kill it, and the signals are queued). You > >>> have to send SIGCONT for the process to continue. > >> > >> We were discussing this problem with Alexander in another > >> (Russian/Ukrainian > >> speaking) maillist. And it looks like the problem is the following. > >> > >> mpd5 thread was detaching ng interface and when doing flowtable_flush() it > >> slept in cv_wait waiting for flowclean_cycles variable to be updated. It > >> should have been awaken by flowcleaner thread but this thread got stuck in > >> endless loop, supposedly in flowtable_clean_vnet()/flowtable_free_stale(), > >> I > >> think because of inconsistent state of some lists (iface?) due to if_detach > >> being in progress. > > > > I have patches that are out for review. > > I am not sure if they apply cleanly as they are broken out of the tail > side of a larger patchset. > > If you are not using VIMAGEs you could ignore the ones I marked with (*). > > http://people.freebsd.org/~bz/20100216-10-ft-cv.diff > http://people.freebsd.org/~bz/20100216-11-ft-debugging.diff > http://people.freebsd.org/~bz/20100216-12-ft-cleanup.diff (*) > http://people.freebsd.org/~bz/20100216-13-ft-ll-cleanup.diff > http://people.freebsd.org/~bz/20100216-18-ft-free.diff(*) > > If you are still seeing the hang and have DDB support in your kernel, > then break into the debugger and save the complete output of > ddb> ps > before rebooting. I cannot make tests right now because of that box in production. I need some time to remove all traffic from it. -- MINO-RIPE ___ 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: misc/144206: Marvell Yukon NIC not working under FreeBSD
Synopsis: Marvell Yukon NIC not working under FreeBSD Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Feb 22 16:05:20 UTC 2010 Responsible-Changed-Why: Reassign to network http://www.freebsd.org/cgi/query-pr.cgi?pr=144206 ___ 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/142547: wpa_supplicant(8) drops connection on key renegotiation
Synopsis: wpa_supplicant(8) drops connection on key renegotiation State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Mon Feb 22 17:13:53 UTC 2010 State-Changed-Why: A fix has been commited and MFCed as r204215. http://www.freebsd.org/cgi/query-pr.cgi?pr=142547 ___ 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/142547: commit references a PR
The following reply was made to PR bin/142547; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: bin/142547: commit references a PR Date: Mon, 22 Feb 2010 17:11:02 + (UTC) Author: bschmidt Date: Mon Feb 22 17:10:47 2010 New Revision: 204215 URL: http://svn.freebsd.org/changeset/base/204215 Log: MFC r203673: Ensure that tkip_mixing_phase1() is called after a rekeying event when using plain s/w crypto. PR: bin/142547 Approved by: rpaulo (mentor) Modified: stable/8/sys/net80211/ieee80211_crypto_tkip.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) stable/8/sys/netinet/ (props changed) Modified: stable/8/sys/net80211/ieee80211_crypto_tkip.c == --- stable/8/sys/net80211/ieee80211_crypto_tkip.c Mon Feb 22 17:03:45 2010(r204214) +++ stable/8/sys/net80211/ieee80211_crypto_tkip.c Mon Feb 22 17:10:47 2010(r204215) @@ -144,6 +144,7 @@ tkip_setkey(struct ieee80211_key *k) return 0; } k->wk_keytsc = 1; /* TSC starts at 1 */ + ctx->rx_phase1_done = 0; return 1; } ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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: Attansic L1 Gigabit discovered on install but no link
On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote: > On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote: >> Good morning! > > After you see the failure DHCP, unplug the UTP cable and wait 2-3 > seconds and replug the UTP cable again. And execute "dhclient ale0", > does it make any difference? Hi, Yes that works. Even better, I think it is fixed for me, I can't explain how though. During the installation and after the installation, a 'dhclient ale0' would throw 'no link' errors, when I yank the cable and put it back in and run 'dhclient ale0' as you suggested, it works. Now for the fun: I changed 'if_ale0="inet 192.168.1.2 "..etc etc. to "if_ale0="dhcp" in /etc/rc.conf, the link comes up normally after a reboot, without yanking cables etc. > It seems you've removed PHY driver related message here. > Show me the output of "devinfo -rv | grep phy". Also show me the > output of "pciconf -lcv". I am sending this email from Solaris now as I am still fighting to find a decent console email client (trying mutt and struggling). If you are still interested in the output, knowing my problem is solved, let me know and I will gladly provide you with the information. > > Last time I tried ale(4) it worked as expected. I have no longer > access to ale(4) hardware so it would be hard to fix that but I'll > see what I can do. It is working as expected for me now too, as I said, I am a bit puzzled but happy. I see my Intel Wireless is supported too so if you still want to have a look I could give you a login on my laptop over wireless so you can bring the interface up and down, I don't have any secret data here anyway and I doubt you're interested in Dutch music ;-) > I have to say, I am really impressed by the support you people give and gave me so far, thank you very much and I hope my knowledge about FreeBSD and it's internals soon will be sufficient to return the favor to the community. Patrick ___ 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/142547: wpa_supplicant(8) drops connection on key renegotiation
On 02/22/10 18:15, bschm...@freebsd.org wrote: Synopsis: wpa_supplicant(8) drops connection on key renegotiation State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Mon Feb 22 17:13:53 UTC 2010 State-Changed-Why: A fix has been commited and MFCed as r204215. http://www.freebsd.org/cgi/query-pr.cgi?pr=142547 ___ 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" Silly question here. But will this patch be applied with portsnap fetch && update? Or will i have to path the kernel manually? -- In a world without walls and fences, who needs windows and gates. ___ 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: Attansic L1 Gigabit discovered on install but no link
On Mon, Feb 22, 2010 at 06:51:19PM +0100, Patrick Ale wrote: > On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote: > > On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote: > >> Good morning! > > > > After you see the failure DHCP, unplug the UTP cable and wait 2-3 > > seconds and replug the UTP cable again. And execute "dhclient ale0", > > does it make any difference? > > Hi, > > Yes that works. Even better, I think it is fixed for me, I can't > explain how though. > During the installation and after the installation, a 'dhclient ale0' > would throw 'no link' errors, when I yank the cable and put it back in > and run 'dhclient ale0' as you suggested, it works. > This indicates there is a problem for link state change detection. > Now for the fun: I changed 'if_ale0="inet 192.168.1.2 "..etc etc. to > "if_ale0="dhcp" in /etc/rc.conf, the link comes up normally after a > reboot, without yanking cables etc. > > > It seems you've removed PHY driver related message here. > > Show me the output of "devinfo -rv | grep phy". Also show me the > > output of "pciconf -lcv". > > I am sending this email from Solaris now as I am still fighting to > find a decent console email client (trying mutt and struggling). > If you are still interested in the output, knowing my problem is > solved, let me know and I will gladly provide you with the > information. > I'm still interested in seeing the output of "devinfo -rv | grep phy". > > > > Last time I tried ale(4) it worked as expected. I have no longer > > access to ale(4) hardware so it would be hard to fix that but I'll > > see what I can do. > > It is working as expected for me now too, as I said, I am a bit > puzzled but happy. > I see my Intel Wireless is supported too so if you still want to have > a look I could give you a login on my laptop over wireless so you can > bring the interface up and down, I don't have any secret data here > anyway and I doubt you're interested in Dutch music ;-) > > > > I have to say, I am really impressed by the support you people give > and gave me so far, thank you very much and I hope my knowledge about > FreeBSD and it's internals soon will be sufficient to return the favor > to the community. > > > Patrick ___ 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"
Intel em0: watchdog timeout
Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s. This is a Intel Pro/1000 PT dual interface PCI-E card. There is two of them in the server. The server is a Dell 2950 Searching the mailing list and checking on google has not turned up much. Since this is our main router it is difficult to test with. I have seen one message that suggests trying to set hw.em.rxd=1024 and hw.em.txd=1024 in loader.conf and another that suggested turning off but none this has not made any difference. The odd thing is that this just started. This box has been up and running fine for a while. The only thing different on our network had been an increase in the bandwidth. Any idea where I go from here to trouble shoot this? # uname -a FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 16:08:53 MDT 2009 r...@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 # tail /var/log/messages Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP # from /var/run/dmesg.boot em0: port 0xdce0-0xdcff mem 0xd5ee-0xd5ef,0xd5ec-0xd5ed irq 17 at device 0.0 on pci8 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:a6:ae:94 em2: port 0xcce0-0xccff mem 0xde3e-0xde3f,0xde3c-0xde3d irq 16 at device 0.0 on pci10 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:a6:af:d6 # pciconf -lv e...@pci0:8:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet e...@pci0:10:0:0:class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet # netstat -bdhI em2 2 input (em2) output packets errs bytespackets errs bytes colls drops 65K 072M51K 0 9.4M 0 0 69K 078M52K 0 8.5M 0 0 76K 088M55K 011M 0 0 74K 085M54K 010M 0 0 78K 091M56K 0 9.0M 0 0 75K 086M54K 0 8.7M 0 0 74K 085M54K 0 9.2M 0 0 75K 086M56K 010M 0 0 78K 088M55K 012M 0 0 78K 090M58K 012M 0 0 76K 087M54K 010M 0 0 79K 091M56K 010M 0 0 Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 ___ 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: Intel em0: watchdog timeout
With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. This is an old old driver now, you might consider going to something a bit more recent. Jack On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: > Hi, >I have a FreeBSD server running Quagga as a BGP router. It has > a number of interfaces in it both bce and em. The most heavily used > interfaces are starting to give me watchdog timeout errors just in the > last week. We normally sustain about 300Mb/s on both of these > interfaces but in the last week this now up to 380Mb/s. > >This is a Intel Pro/1000 PT dual interface PCI-E card. There is > two of them in the server. The server is a Dell 2950 > >Searching the mailing list and checking on google has not turned > up much. Since this is our main router it is difficult to test with. I > have seen one message that suggests trying to set hw.em.rxd=1024 and > hw.em.txd=1024 in loader.conf and another that suggested turning off > but none this has not made any difference. > >The odd thing is that this just started. This box has been up > and running fine for a while. The only thing different on our network > had been an increase in the bandwidth. > >Any idea where I go from here to trouble shoot this? > > # uname -a > FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 > 16:08:53 MDT 2009 > r...@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 > > # tail /var/log/messages > Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting > Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN > Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP > Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN > Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP > Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting > Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN > Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP > Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting > Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN > Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP > Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting > Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN > Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP > > # from /var/run/dmesg.boot > em0: port 0xdce0-0xdcff mem > 0xd5ee-0xd5ef,0xd5ec-0xd5ed irq 17 at device 0.0 on pci8 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:a6:ae:94 > em2: port 0xcce0-0xccff mem > 0xde3e-0xde3f,0xde3c-0xde3d irq 16 at device 0.0 on > pci10 > em2: Using MSI interrupt > em2: [FILTER] > em2: Ethernet address: 00:15:17:a6:af:d6 > > # pciconf -lv > e...@pci0:8:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 > hdr=0x00 >vendor = 'Intel Corporation' >device = 'PRO/1000 PT' >class = network >subclass = ethernet > e...@pci0:10:0:0:class=0x02 card=0x135e8086 chip=0x105e8086 > rev=0x06 hdr=0x00 >vendor = 'Intel Corporation' >device = 'PRO/1000 PT' >class = network >subclass = ethernet > > # netstat -bdhI em2 2 >input (em2) output > packets errs bytespackets errs bytes colls drops > 65K 072M51K 0 9.4M 0 0 > 69K 078M52K 0 8.5M 0 0 > 76K 088M55K 011M 0 0 > 74K 085M54K 010M 0 0 > 78K 091M56K 0 9.0M 0 0 > 75K 086M54K 0 8.7M 0 0 > 74K 085M54K 0 9.2M 0 0 > 75K 086M56K 010M 0 0 > 78K 088M55K 012M 0 0 > 78K 090M58K 012M 0 0 > 76K 087M54K 010M 0 0 > 79K 091M56K 010M 0 0 > > > Kirk > > > Kirk Davis > Senior Network Analyst, ITS > Edmonton Public Schools > One Kingsway Ave. > Edmonton, Alberta, Canada > T5H 4G9 > > ___ > 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/142547: wpa_supplicant(8) drops connection on key renegotiation
On Monday 22 February 2010 17:35:24 Backup wrote: > Silly question here. But will this patch be applied with portsnap fetch > && update? Or will i have to path the kernel manually? portsnap? you mean freebsd-update? No, it won't. You have to fetch/build your kernel manually for now. -- 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: Intel em0: watchdog timeout
I have a backup server sitting here that I am going to load 7.3-RC1 onto and test with it. It is the exact duplicate hardware so that should help with the upgraded driver. Does it make sence to go to 8.0? Here is the mbuf usage on this server. I'm nore sure exactly how to read this but it seem to looks OK. # netstat -m 8181/5904/14085 mbufs in use (current/cache/total) 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 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) 16363K/8834K/25197K 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/0/0 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 Kirk From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Monday, February 22, 2010 11:43 AM To: Kirk Davis Cc: freebsd-net@freebsd.org Subject: [SPAM:#] Re: Intel em0: watchdog timeout With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. This is an old old driver now, you might consider going to something a bit more recent. Jack On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s. This is a Intel Pro/1000 PT dual interface PCI-E card. There is two of them in the server. The server is a Dell 2950 Searching the mailing list and checking on google has not turned up much. Since this is our main router it is difficult to test with. I have seen one message that suggests trying to set hw.em.rxd=1024 and hw.em.txd=1024 in loader.conf and another that suggested turning off but none this has not made any difference. The odd thing is that this just started. This box has been up and running fine for a while. The only thing different on our network had been an increase in the bandwidth. Any idea where I go from here to trouble shoot this? # uname -a FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 16:08:53 MDT 2009 r...@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 # tail /var/log/messages Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP # from /var/run/dmesg.boot em0: port 0xdce0-0xdcff mem 0xd5ee-0xd5ef,0xd5ec-0xd5ed irq 17 at device 0.0 on pci8 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:a6:ae:94 em2: port 0xcce0-0xccff mem 0xde3e-0xde3f,0xde3c-0xde3d irq 16 at device 0.0 on pci10 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:a6:af:d6 # pciconf -lv e...@pci0:8:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet e...@pci0:10:0:0:class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT'
Re: Intel em0: watchdog timeout
Try `sysctl dev.em.0.stats=1` and em.2, you're right though, doesn't look like any system mbuf failures. 7.2 seems to be a stable base OS and driver, 8 is better in some respects, but has not been without its reported problems. I leave the choice to you. Without more data I am not sure what is causing the watchdog. Jack On Mon, Feb 22, 2010 at 10:55 AM, Kirk Davis wrote: > I have a backup server sitting here that I am going to load 7.3-RC1 onto > and test with it. It is the exact duplicate hardware so that should help > with the upgraded driver. Does it make sence to go to 8.0? > > Here is the mbuf usage on this server. I'm nore sure exactly how to read > this but it seem to looks OK. > # netstat -m > 8181/5904/14085 mbufs in use (current/cache/total) > 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) > 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/12800 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) > 16363K/8834K/25197K 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/0/0 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 > > Kirk > > > -- > *From:* Jack Vogel [mailto:jfvo...@gmail.com] > *Sent:* Monday, February 22, 2010 11:43 AM > *To:* Kirk Davis > *Cc:* freebsd-net@freebsd.org > *Subject:* [SPAM:#] Re: Intel em0: watchdog timeout > > With the increased load you might be running out of mbufs more easily, > would suggest you increase the mbuf pool. > > This is an old old driver now, you might consider going to something a > bit more recent. > > Jack > > > On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: > >> Hi, >>I have a FreeBSD server running Quagga as a BGP router. It has >> a number of interfaces in it both bce and em. The most heavily used >> interfaces are starting to give me watchdog timeout errors just in the >> last week. We normally sustain about 300Mb/s on both of these >> interfaces but in the last week this now up to 380Mb/s. >> >>This is a Intel Pro/1000 PT dual interface PCI-E card. There is >> two of them in the server. The server is a Dell 2950 >> >>Searching the mailing list and checking on google has not turned >> up much. Since this is our main router it is difficult to test with. I >> have seen one message that suggests trying to set hw.em.rxd=1024 and >> hw.em.txd=1024 in loader.conf and another that suggested turning off >> but none this has not made any difference. >> >>The odd thing is that this just started. This box has been up >> and running fine for a while. The only thing different on our network >> had been an increase in the bandwidth. >> >>Any idea where I go from here to trouble shoot this? >> >> # uname -a >> FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 >> 16:08:53 MDT 2009 >> r...@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 >> >> # tail /var/log/messages >> Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting >> Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP >> Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP >> Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting >> Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP >> Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting >> Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN >> Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP >> Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting >> Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN >> Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP >> >> # from /var/run/dmesg.boot >> em0: port 0xdce0-0xdcff mem >> 0xd5ee-0xd5ef,0xd5ec-0xd5ed irq 17 at device 0.0 on pci8 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:a6:ae:94 >> em2: port 0xcce0-0xccff mem >> 0xde3e-0xde3f,0xde3c-0xde3d irq 16 at device 0.0 on >> pci10 >> em2: Using MSI interrupt >> em2: [FILTER] >> em2: Ethernet address: 00:15:17:a6:af:d6 >> >> # pciconf -lv >> e...@pci0:8:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 >> hdr=0x00 >>vendor = 'Intel Corporation' >>device = 'PRO/1000 PT' >>class = network >>subclass = ethernet >> e...@pci0:10:0:0:class=0x02 card=0x135e808
Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation
On 02/22/10 19:49, Bernhard Schmidt wrote: On Monday 22 February 2010 17:35:24 Backup wrote: Silly question here. But will this patch be applied with portsnap fetch && update? Or will i have to path the kernel manually? portsnap? you mean freebsd-update? No, it won't. You have to fetch/build your kernel manually for now. Alright, thanks for the reply :) -- In a world without walls and fences, who needs windows and gates. ___ 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: Intel em0: watchdog timeout
From: Jack Vogel [mailto:jfvo...@gmail.com] Try `sysctl dev.em.0.stats=1` and em.2, you're right though, doesn't look like any system mbuf failures. Does this need to be done in loader.conf? It doesn't seem to take from the command line. # sysctl dev.em.2.stats=1 dev.em.2.stats: -1 -> -1 # sysctl dev.em.2.stats dev.em.2.stats: -1 7.2 seems to be a stable base OS and driver, 8 is better in some respects, but has not been without its reported problems. I leave the choice to you. Without more data I am not sure what is causing the watchdog. Yes, I am having trouble tracking it down. I up'ed the mbufs to 65536 just to see if it made any difference but it is still happening. SET NMBCLUSTERS TO 65536 ## Feb 22 12:45:21 inet-gw kernel: em0: watchdog timeout -- resetting Feb 22 12:45:21 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:25 inet-gw kernel: em0: link state changed to UP Feb 22 12:45:25 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:28 inet-gw kernel: em0: link state changed to UP Feb 22 12:45:29 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:31 inet-gw kernel: em0: link state changed to UP # netstat -m 8183/6037/14220 mbufs in use (current/cache/total) 7160/3598/10758/65536 mbuf clusters in use (current/cache/total/max) 7160/3592 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 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) 16365K/9121K/25487K 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/0/0 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 I guess I will have to build up the new server with 7.3 on it and see if the newer driver makes any difference. Kirk On Mon, Feb 22, 2010 at 10:55 AM, Kirk Davis wrote: I have a backup server sitting here that I am going to load 7.3-RC1 onto and test with it. It is the exact duplicate hardware so that should help with the upgraded driver. Does it make sence to go to 8.0? Here is the mbuf usage on this server. I'm nore sure exactly how to read this but it seem to looks OK. # netstat -m 8181/5904/14085 mbufs in use (current/cache/total) 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 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) 16363K/8834K/25197K 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/0/0 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 Kirk From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Monday, February 22, 2010 11:43 AM To: Kirk Davis Cc: freebsd-net@freebsd.org Subject: [SPAM:#] Re: Intel em0: watchdog timeout With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. This is an old old driver now, you might consider going to something a bit more recent. Jack On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s.
Re: Intel em0: watchdog timeout
At 03:46 PM 2/22/2010, Kirk Davis wrote: Does this need to be done in loader.conf? It doesn't seem to take from the command line. # sysctl dev.em.2.stats=1 dev.em.2.stats: -1 -> -1 # sysctl dev.em.2.stats dev.em.2.stats: -1 Hi, After you issue those commands, the driver will spit out a lot of useful stats to syslog. It will report something like the following in /var/log/messages Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier extension errors = 0 Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: Intel em0: watchdog timeout
On Mon, Feb 22, 2010 at 12:46 PM, Kirk Davis wrote: > >From: Jack Vogel [mailto:jfvo...@gmail.com] > > Try `sysctl dev.em.0.stats=1` and em.2, you're right though, > doesn't look like any >system mbuf failures. > > > Does this need to be done in loader.conf? It doesn't seem to take from > the command line. > # sysctl dev.em.2.stats=1 > dev.em.2.stats: -1 -> -1 > > # sysctl dev.em.2.stats > dev.em.2.stats: -1 > > > you will only see the data on the system console, if you're in a graphics environment use `tail /var/log/messages' and you will see it :) >7.2 seems to be a stable base OS and driver, 8 is better in some > respects, but >has not been without its reported problems. I leave the choice > to you. > >Without more data I am not sure what is causing the watchdog. > > Yes, I am having trouble tracking it down. I up'ed the mbufs to 65536 > just to see if it made any difference but it is still happening. > I have the testers here set: nmbclusters 262144 Jack ___ 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: Intel em0: watchdog timeout
> -Original Message- > From: Mike Tancsa [mailto:m...@sentex.net] > Subject: Re: Intel em0: watchdog timeout > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem > to take from > >the command line. > ># sysctl dev.em.2.stats=1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 > > Hi, > After you issue those commands, the driver will spit out a > lot of useful stats to syslog. It will report something like the > following in /var/log/messages > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > extension errors = 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 Thanks Mike and Jack. I don't know why I didn'ty notice the output in /var/log/messages Here is the output for the two interfaces that are causing this issue. Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions = 0 Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: Defer count = 0 Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets = 24296 Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers = 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: Crc errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors = 0 Feb 22 13:33:52 inet-gw kernel: em0: RX overruns = 0 Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts = 6 Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd = 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd = 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd = 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd = 0 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd = 424303810 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd = 576529136 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd = 0 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed = 0 Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions = 0 Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: Defer count = 20 Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets = 68059 Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers = 275612 Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: Receive errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: Crc errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors = 0 Feb 22 13:34:12 inet-gw kernel: em2: RX overruns = 17 Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts = 38 Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd = 21 Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd = 8344 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd = 30 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd = 9159 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd = 713607509 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd = 569694020 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd = 0 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed = 0 Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions = 0 Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors = 0 Feb 22 13:35:10 inet-gw kernel: em2: Defer count = 20 Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets = 68059 Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers = 275612 Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors = 0 Feb 22 13:35:10 inet-gw kernel: em2: Receive errors = 0 Feb 22 13:35:10 inet-gw kernel: em2: Crc
Re: Intel em0: watchdog timeout
OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? If you havent already done so, change that to 1024. I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. Jack On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: > > > > -Original Message- > > From: Mike Tancsa [mailto:m...@sentex.net] > > Subject: Re: Intel em0: watchdog timeout > > > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > > >Does this need to be done in loader.conf? It doesn't seem > > to take from > > >the command line. > > ># sysctl dev.em.2.stats=1 > > >dev.em.2.stats: -1 -> -1 > > > > > ># sysctl dev.em.2.stats > > >dev.em.2.stats: -1 > > > > Hi, > > After you issue those commands, the driver will spit out a > > lot of useful stats to syslog. It will report something like the > > following in /var/log/messages > > > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 > > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 > > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > > extension errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 > > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 > > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > > LINK MSIX IRQ = 0 > > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 > > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 > > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 > > Thanks Mike and Jack. I don't know why I didn'ty notice the output in > /var/log/messages > > Here is the output for the two interfaces that are causing this issue. > > Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Defer count = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets = 24296 > Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Receive errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Crc errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors > = 0 > Feb 22 13:33:52 inet-gw kernel: em0: RX overruns = 0 > Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts = 6 > Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd = 424303810 > Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd = 576529136 > Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Defer count = 20 > Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets = 68059 > Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers = 275612 > Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Receive errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Crc errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors > = 0 > Feb 22 13:34:12 inet-gw kernel: em2: RX overruns = 17 > Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts = 38 > Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd = 21 > Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd = 8344 > Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd = 30 > Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd = 9159 > Feb 22 13:34:12 inet-gw kernel: em2: Good Packets
RE: Intel em0: watchdog timeout
OK. I have the following in /boot/loader.conf (and rebooted) hw.em.rxd=1024 hw.em.txd=1024 Should this be hw.em2.rxd? Is it set per interface or across all interfaces? nmbcluster=262144 # sysctl dev.em.2.stats=1 Feb 22 16:29:57 inet-gw kernel: em2: Defer count = 20 Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets = 119947 Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers = 276762 Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors = 0 Feb 22 16:29:57 inet-gw kernel: em2: Receive errors = 0 Feb 22 16:29:57 inet-gw kernel: em2: Crc errors = 0 Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors = 0 Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors = 0 Feb 22 16:29:57 inet-gw kernel: em2: RX overruns = 21 Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts = 47 Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd = 22 Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd = 8349 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd = 31 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd = 15779 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd = 966101852 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd = 755993237 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd = 0 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed = 0 still seeing the watchdog timer and link up/down messages. Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the next time I can schedule another reboot on this production server. Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 phone: 1-780-429-8308 From: Jack Vogel [mailto:jfvo...@gmail.com] Sent: Monday, February 22, 2010 3:45 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? If you havent already done so, change that to 1024. I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. Jack On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: > -Original Message- > From: Mike Tancsa [mailto:m...@sentex.net] > Subject: Re: Intel em0: watchdog timeout > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem > to take from > >the command line. > ># sysctl dev.em.2.stats=1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 > > Hi, > After you issue those commands, the driver will spit out a > lot of useful stats to syslog. It will report something like the > following in /var/log/messages > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > extension errors = 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141
Re: Intel em0: watchdog timeout
Is your driver static, ie builtin, to the kernel, or do you load/unload it as a module? I ask because perhaps we could try a later driver, and being a module makes that easier. Jack On Mon, Feb 22, 2010 at 3:37 PM, Kirk Davis wrote: > OK. I have the following in /boot/loader.conf (and rebooted) > hw.em.rxd=1024 > hw.em.txd=1024 > > Should this be hw.em2.rxd? Is it set per interface or across all > interfaces? > > nmbcluster=262144 > > # sysctl dev.em.2.stats=1 > Feb 22 16:29:57 inet-gw kernel: em2: Defer count = 20 > Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets = 119947 > Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers = 276762 > Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Receive errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Crc errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: RX overruns = 21 > Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts = 47 > Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK > MSIX IRQ = 0 > Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd = 22 > Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd = 8349 > Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd = 31 > Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd = 15779 > Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd = 966101852 > Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd = 755993237 > Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd = 0 > Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed = 0 > > still seeing the watchdog timer and link up/down messages. > > Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the > next time I can schedule another reboot on this production server. > > Kirk > > > *Kirk Davis*** > *Senior Network Analyst, ITS* > *Edmonton Public Schools* > *One Kingsway Ave. * > *Edmonton, Alberta, Canada* > *T5H 4G9* > *phone: 1-780-429-8308* > > > -- > *From:* Jack Vogel [mailto:jfvo...@gmail.com] > *Sent:* Monday, February 22, 2010 3:45 PM > *To:* Kirk Davis > *Cc:* Mike Tancsa; freebsd-net@freebsd.org > > *Subject:* Re: Intel em0: watchdog timeout > > OK, so you are still failing to get mbufs in the RX side, increase the > nmbcluster > value, and then what size is your RX ring (number of rx descriptors)? > > If you havent already done so, change that to 1024. > > I am developing a change in the RX code right now that will help > this situation, but am doing so in the 10G driver, once its solid there > I will be backporting it into the 1G drivers, it will make discards > almost unnecessary. > > Jack > > On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: > >> >> >> > -Original Message- >> > From: Mike Tancsa [mailto:m...@sentex.net] >> > Subject: Re: Intel em0: watchdog timeout >> > >> > At 03:46 PM 2/22/2010, Kirk Davis wrote: >> > >Does this need to be done in loader.conf? It doesn't seem >> > to take from >> > >the command line. >> > ># sysctl dev.em.2.stats=1 >> > >dev.em.2.stats: -1 -> -1 >> > > >> > ># sysctl dev.em.2.stats >> > >dev.em.2.stats: -1 >> > >> > Hi, >> > After you issue those commands, the driver will spit out a >> > lot of useful stats to syslog. It will report something like the >> > following in /var/log/messages >> > >> > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier >> > extension errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 >> > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 >> > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> > LINK MSIX IRQ = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 >> > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 >> > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 >> >> Thanks Mike and Jack. I don't know why I didn'ty notice the output in >> /var/log/messages >> >> Here is the output for the two interfaces that are causing this issue. >> >> Feb 22 13:33:52 inet-gw
Re: Routing into overlapping subnets
On 2010.02.18 00:31, Christian Ullrich wrote: > * Steve Bertrand wrote: > >> On 2010.02.17 16:42, Christian Ullrich wrote: > >>> send the packet. Why doesn't the kernel look up an ARP table entry by >>> both IP address and interface? >> >> That's not how the protocols were designed, and thankfully so. Imagine >> the potential for spoofing if this were allowed by default ;) > > You're right, of course. I had not considered that. > >> I have a couple of ideas, but need to understand better of your setup. >> Advise if this seems semi-accurate: >> >> - you house global resources for a bunch of clients at a central location >> - you have limited public IP addresses to do this with, or your central >> location is located within the same 'building' as all of the clients > > The latter. > >> - you have several clients with overlapping 1918 space >> - you need a method to have two instances of eg 192.168.1.110 accessing >> a single central resource, but which will be coming in on two separate >> interfaces (physical or virtual) >> - the central services (ie printer) doesn't have the capability to house >> more than a single IPv4 address >> - you do not want to be open to the potential for one client accessing >> the others networks >> - you have absolute control over the pf box >> >> is this right? > > Exactly right. Contact me off-list, and I'll see if I can help with either cleaning this up, or with a dirty hack. We'll post any positive results to the list. Steve ___ 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: Slow speeds experienced with Dummynet
Luigi Rizzo wrote: On Fri, Feb 19, 2010 at 10:48:32PM +0400, rihad wrote: Hi, all, Recalling my old posting "dummynet dropping too many packets" dated October 4, 2009, the problem isn't over just yet. This time, there are no interface i/o drops (just a reminder: we have 2 bce(4) GigE cards connected to a Cisco router, one for input, and one for output. The box itself does some traffic accounting and enforces speed limits w/ ipfw/dummynet. There are normally around 5-6k users online). If i remember well, the previous discussion ended when you raised the intr_queue_maxlen (and perhaps increased HZ) to avoid that the bursts produced by periodic invocation of dummynet_io() could overflow that queue. From the rest of your post it is not completely clear if you have not found any working configuration, or there is some setting (e.g. with "queue 1000" or larger) which do produce a smooth experience for your customers. Nope, I haven't been able to find it :( From as low as 50 to 2000 slots. I've also tried 1 and 2s worth queue sizes (in Kbytes). After about 8 p.m., when most users are online, speed problems are the most apparent. It all boils down to big differences between some subsequent "systat -if" reads, both for input and output, when dummynet is in use. It isn't normal for two reads to differ in as much as 100-150 mbps (20-25%). I can only hope that Intel's expensive 10 GigE cards have much larger tolerance to traffic load spikes, and are better suited for ISP usage patterns. Another thing i'd like to understand is whether all of your pipes have a /32 mask, or there are some which cover multiple hosts. Typical TCP connections have around 50 packets in flight when the connection is fully open (which in turn is hard to happen on a 512k pipe) so a queue of 100-200 is unlikely to overflow. In fact, long queues are very detrimental for customers because they increase the delay of the congestion control loop -- as a rule of thumb, you should try to limit the queue size to at most 1-2s of data. cheers luigi Traffic shaping is accomplished by this ipfw rule: pipe tablearg ip from any to table(0) out where table(0) contains those 5-6k IP addresses. The pipes themselves are GRED (or taildrop, it doesn't matter): ipfw pipe 512 config bw 512kbit/s mask dst-ip 0x gred 0.002/900/1000/0.1 queue 1000 Taking this template the speeds range from 512 to tens of mbps. With the setup as above very many users complain about very slow downloads, slow browsing. systat -ifstat, refreshed every 5 seconds, does reveal large differences between subsequent displays: if around 800-850 mbps is what's to be expected, it doesn't stay within those limits, also jumping to as low as 620+, and to somewhere in the 700's, Now imagine this: once I turn dummynet off (by short-circuiting a "allow ip from any to any" before the "pipe tablearg" rule) all user complaints stop, with traffic load staying stably at around 930-950 mbps. Does this have anything to do with "dummynet bursts"? How can I beat that? If I keep the pipe queue size at 2000 slots, the net.inet.ip.dummynet.io_pkt_drops sysctl stops increasing, once I start tweaking the value to as low as 100 slots, the value starts raising constantly at about 300-500 pps. I had hoped that smaller queue sizes would battle the negative effects of dummynet burstiness, it did so, I guess, but not in a very decisive manner. FreeBSD 7.1-RELEASE-p10 kern.hz=4000 kern.ipc.nmbclusters=11 net.inet.ip.fastforwarding=1 net.inet.ip.dummynet.io_fast=1 net.isr.direct=0 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.dummynet.hash_size=512 net.inet.ip.dummynet.max_chain_len=16 net.inet.ip.intr_queue_drops: 0 systat -ip shows zero output drops at times of trouble. netstat -s's "output packets dropped due to no bufs, etc." is also fine. netstat -m shows nothing suspicious. p.s: Two "bloody expensive" Intel 10 GigE's are on their way to us to replace the Broadcom cards, meanwhile what should I try doing? Thanks for reading. ___ 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"
