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 <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

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 <Link#1> 00:80:29:12:9c:20 74003 31125 83139 117 3
fxp0 1500 192.168.0 192.168.0.1 5910 - 1114 - -
ed0 1500 <Link#2> 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 <Link#3> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
status: active

hivemind# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
fxp0 1500 <Link#1> 00:80:29:12:90:b9 370620 27557 430514 32 10
fxp0 1500 192.168.0 192.168.0.2 377045 - 436691 - -
lo0 16384 <Link#2> 9594 0 9594 0 0
lo0 16384 127 127.0.0.1 3229 - 3229 - -

hivemind# ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to