From owner-freebsd-questions Fri Dec 27 10:34:36 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D03D37B401 for ; Fri, 27 Dec 2002 10:34:31 -0800 (PST) Received: from hivemind.trini0.org (bgp626680bgs.brick201.nj.comcast.net [68.39.132.244]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F8C643ED1 for ; Fri, 27 Dec 2002 10:34:29 -0800 (PST) (envelope-from gsam@trini0.org) Received: (qmail 33646 invoked by uid 0); 27 Dec 2002 18:34:27 -0000 Received: from unknown (HELO trini0.org) (192.168.0.5) by 192.168.0.2 with SMTP; 27 Dec 2002 18:34:27 -0000 Message-ID: <3E0C9D2E.3000704@trini0.org> Date: Fri, 27 Dec 2002 13:34:22 -0500 From: Gerard Samuel User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021213 X-Accept-Language: en, en-us, nl, th MIME-Version: 1.0 To: stacey@vickiandstacey.com Cc: FreeBSD Questions Subject: Re: Network timeouts??? References: <3E0C72A9.9000302@trini0.org> <1041004206.68500.116.camel@localhost> <3E0C91F0.3000102@trini0.org> <1041012776.68500.128.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stacey Roberts wrote: >On Fri, 2002-12-27 at 17:46, Gerard Samuel wrote: > > >>Stacey Roberts wrote: >> >> >> >>>On Fri, 2002-12-27 at 15:32, Gerard Samuel wrote: >>> >>> >>> >>> >>>>Im not really sure when the problem began, but I believe it was after >>>>upgrading to 4.7-RELEASE-p2. >>>>2 of the boxes running 4.7-RELEASE-p2 which are also running with Intel >>>>Pro 10/100B/100+ Ethernet cards, >>>>are getting numerous timeouts in the logs. >>>> >>>>fxp0: device timeout >>>> >>>>When connecting to these boxes, the connections are sluggish, to the >>>>point where I can type faster, that the command line can display. >>>>All boxes are connected on a 100Mb network via an SMC EZ-Switch SMC >>>>6308TX switch. >>>>The only thing that has changed in months, is software versions. >>>>The problem seems sporadic. Can't seem to find out how or what is >>>>causing the problem. >>>> >>>>Is/was there a problem with the fxp drivers, or can someone direct me as >>>>to how one goes about to debug this problem. >>>> >>>>Thanks for any info you may provide... >>>> >>>> >>>> >>>> >>>Hi Gerard, >>> If you connect to the box via ssh, then you might want to try using >>>the "-v" switch to ssh so as to get a more verbose output when >>>connecting. >>> >>>It should display evidence as to where in the connection any delays are >>>occurring as far as your sluggish connectivity is concerned. >>> >>>Do the cards themselves produce any information for you? Post some stats >>> >>> >>>from the nics as returned from:- >> >> >>>netstat -in >>> >>> >>> >>hivemind# netstat -in >>Name Mtu Network Address Ipkts Ierrs Opkts Oerrs >>Coll >>fxp0 1500 00:80:29:12:90:b9 366170 27094 426767 >>31 10 >>fxp0 1500 192.168.0 192.168.0.2 372504 - 432856 >>- - >>lo0 16384 9454 0 9454 >>0 0 >>lo0 16384 127 127.0.0.1 3179 - 3179 >>- - >> >> >> > >Hi Gerard, > See here that the only transmission errors are for the Ierrs (27094 >occurences. > >This is an indication that fxp0 is collecting stats on late / undetected >collisions. > >Please look at the stats for fxp0 with the command "ifconfig fxp0" and >place the output here. It would appears that fxp0 is *not* in full >duplex mode. > >There is also something else to note - interfaces, operating at full >duplex don't actually perform collision detection for their own >respective operation (I am open to suggestions otherwise on this), but >they may well be capable of collecting collision stats for other hosts >on the subnet. As such, you might want to check the interfaces of other >hosts with which this box is networked. > >Get back to the list with what data you are able to extract from fxp0 >and other hosts as they case may be. > >Regards, > >Stacey > Ok, I see the amount of errors. Maybe, cables went bad. Come to think of it, the room that the computers are in, recently got repainted, and I had disconnected everything. Maybe something happened then??? Ill make some new cables tonight, and see how it goes.... Here are the stats off the two boxes -> {gsam@gatekeeper}-{~} > netstat -in [27 Dec 1:22pm] Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:80:29:12:9c:20 74003 31125 83139 117 3 fxp0 1500 192.168.0 192.168.0.1 5910 - 1114 - - ed0 1500 00:00:c0:29:52:48 401134 0 68811 0 3161 ed0 1500 68.39.128/21 68.39.132.244 2759 - 403 - - lo0 16384 766 0 766 0 0 lo0 16384 127 127.0.0.1 4 - 4 - - {gsam@gatekeeper}-{~} > ifconfig fxp0 [27 Dec 1:22pm] fxp0: flags=8843 mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:80:29:12:9c:20 media: Ethernet autoselect (100baseTX ) status: active hivemind# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:80:29:12:90:b9 370620 27557 430514 32 10 fxp0 1500 192.168.0 192.168.0.2 377045 - 436691 - - lo0 16384 9594 0 9594 0 0 lo0 16384 127 127.0.0.1 3229 - 3229 - - hivemind# ifconfig fxp0 fxp0: flags=8843 mtu 1500 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:80:29:12:90:b9 media: Ethernet autoselect (100baseTX ) status: active > > > >>>netstat -s >>> >>> >>> >>Its too long. Don't want to offend anyone with a long debug output.... >> >> >> >>>netstat -m >>> >>> >>> >>hivemind# netstat -m >>67/896/6144 mbufs in use (current/peak/max): >> 66 mbufs allocated to data >> 1 mbufs allocated to packet headers >>64/600/1536 mbuf clusters in use (current/peak/max) >>1424 Kbytes allocated to network (30% of mb_map in use) >>0 requests for memory denied >>0 requests for memory delayed >>0 calls to protocol drain routines >> >> >> >>>At the least, you could try "bouncing" (ifconfig down / ifconfig up) the >>>interfaces if the situation degrades dramatically. >>> >>> >>> >>True, but the thing is these boxes, don't have keyboards hooked up to >>them, so when they go down, >>I have to wait to see if they come up, or I kill the power if Im impatient. >>I just moved the switch away from the box its next, hoping it need more >>ventilation, so Ill see how it goes now... >> >> >> >>>Hope this helps. >>> >>>Stacey >>> >>> >>> >>> >>> -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message