Date: 27 Dec 2002 18:12:57 +0000 From: Stacey Roberts <stacey@vickiandstacey.com> To: Gerard Samuel <gsam@trini0.org> Cc: FreeBSD Questions <questions@FreeBSD.ORG> Subject: Re: Network timeouts??? Message-ID: <1041012776.68500.128.camel@localhost> In-Reply-To: <3E0C91F0.3000102@trini0.org> References: <3E0C72A9.9000302@trini0.org> <1041004206.68500.116.camel@localhost> <3E0C91F0.3000102@trini0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Link#1> 00:80:29:12:90:b9 366170 27094 426767 > 31 10 > fxp0 1500 192.168.0 192.168.0.2 372504 - 432856 > - - > lo0 16384 <Link#2> 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 > >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 > > > > > > -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1041012776.68500.128.camel>