Date: Wed, 8 Nov 2006 10:28:52 +0000 From: MQ <antinvidia@gmail.com> To: "Marat N.Afanasyev" <amarat@ksu.ru> Cc: freebsd-net@freebsd.org Subject: Re: a very strange netstat output and problem when using transparent proxy Message-ID: <be0088ce0611080228l4a9ba091gde28aef330975ff7@mail.gmail.com> In-Reply-To: <4550F348.8040509@ksu.ru> References: <200611072019.kA7KJsAm073276@lurza.secnetix.de> <4550F348.8040509@ksu.ru>
index | next in thread | previous in thread | raw e-mail
2006/11/7, Marat N.Afanasyev <amarat@ksu.ru>: > > Oliver Fromme wrote: > > Marat N.Afanasyev wrote: > > > bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > > > > Ok, I also have a machine with bge(4) NIC within reach. > > I've had a look at it for similar symptoms (see below). > > > > > bge0 1500 <Link#1> 00:50:45:5f:4f:78 2341018 799 3062828 > > > 0 0 > > > > 799 is not good, but I wouldn't call it "huge amount of > > ierrs". Is that a typical number, or was that output > > taken before the problem (network freeze) appears? > > more typical is the following: > > % netstat -I bge0 -w 60 > input (bge0) output > packets errs bytes packets errs bytes colls > 151993 241 111011660 172436 0 120848541 0 > 169867 388 118858096 192997 0 135783627 0 > 130524 407 91213775 145884 0 110857756 0 > 327168 1637 214730921 397193 0 275486626 0 > 385627 1027 254274520 471177 0 333456526 0 > 300184 720 198432049 367100 0 271325679 0 > 261095 5525 166910652 324112 0 251708900 0 > 278257 11998 176453071 349975 0 268865328 0 > 314383 8617 203347024 393589 0 301819857 0 > 195408 11647 129989509 246718 0 195720356 0 > 7163 23787 6087244 13165 0 7694485 0 > 2485 24786 1743165 6571 0 4015170 0 > 2202 26175 1117627 6225 0 3992217 0 > > and oops. none of two interfaces can any more process any incoming > packet. ping drops increase to 99% > > > > > > % uptime > > > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 > > > > Ok, 799 ierrs after 40 minuted uptime is definitely not > > good. :-) > > > > > Real IP address. I've already switched forward off and make squid > listen > > > on 80 instead. Problem persists. > > > > OK, so it's a NIC problem, not IPFW-related. > > > > Here's output from my machine with bge(4) NIC: > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > > bge0 1500 <Link#1> 00:16:35:... 7808595 35 3451475 0 0 > > > > Uptime is 8 days, the machine is only moderately loaded, > > but gets quite some amount of NFS traffic (as a client). > > OS is FreeBSD 6.2-PRELELEASE as of October 19th. > > as I said before, this problem persists on all my machines with 5704. > > > Whie 35 ierrs in 8 days isn't much, I think it still > > indicates a problem somewhere. It should really be 0. > > (I haven't experienced any freezes or other problems, > > though.) > > > > Maybe you should ask on the -stable mailing list for > > others with bge(4) NICs to check. It looks like a bug > > in the driver. > > > > Oh by the way, do you have polling enabled? Try to > > switch in on (if disabled) or off (if enabled) and check > > whether it improves the situation for you. > > > > Best regards > > Oliver > > > polling cannot be "safely" turned on smp, without eating a lot of cpu to > interrupt processing. So, I run away from polling. > > -- > SY, Marat > _______________________________________________ > 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" > Maybe bge(4) has some problems with it. At least I have found that on my laptop and servers, the bge_tick() is time-consuming sometimes, and may result lost_polls increasing abnormally. So I won't enable device polling before the problem is addressed and fixed. To your problem, I'm not sure whether fwd rule was used properly. Perhaps divert may help?home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be0088ce0611080228l4a9ba091gde28aef330975ff7>