Re: Network timeouts???
On Sat, 2002-12-28 at 18:51, Gerard Samuel wrote:
> Well after almost 24 hours later, here is what happened...
> Shortly after your last post, the situation got worse. I tried banging
> the switch with a screwdriver, and that was it.
> No more switch. The link light kept flashing, so I knew it was pretty
> much dead.
> Just so happens, that its a Friday evening, and banks were closed,
> credit card is maxed out from Christmas, so
> I had to endure a dead network till today.
> Got me a brand new switch from Circuit City, and all seems to be well in
> the universe. No more errors...
> Thanks for all the help...
Sound like one for the "Tales of the Sysadmin" :-)
Happy to hear that thing have settled down there.
Grab some rest, Dude!
Regards,
Stacey
>
> Stacey Roberts wrote:
>
> >On Fri, 2002-12-27 at 19:31, Gerard Samuel wrote:
> >
> >
> >>Stacey Roberts wrote:
> >>
> >>
> >>
> >>>So both nic believe themselves to be running okay (as shown in their
> >>>respective Oerr counts being 0 each - translation: the nics are fine as
> >>>they are able to send all packets okay. Its only in receiving data that
> >>>they're returning errors on the link.
> >>>
> >>>I'd suggest that you have a look at the switch itself as well. I know
> >>>that this is a desktop switch (read non-enterprise) that is different to
> >>>most others in this class as its got *no* cooling fans (hence that bump
> >>>on the top). As such, depending on how you hammer this device, there is
> >>>the chance of it over-heating. This, of course, is also dependant on
> >>>where its actually located as well.
> >>>
> >>>It does have some link / speed / duplex indicator LED's on the front
> >>>that can be useful. As well as checking the cabling into the switch, see
> >>>if swapping the cables to available ports (except the uplink partner!)
> >>>and see if this makes any difference.
> >>>
> >>>I remember one of the guys on my team at work got the Linksys peer to
> >>>this switch and rubbished it within 3 weeks due to the switch locking up
> >>>under sustained (4+ hours) heavy load transfers at his section lan
> >>>point.
> >>>
> >>>Let us know how you get on, and what new information you might have for
> >>>us.
> >>>
> >>>Regards,
> >>>
> >>>Stacey
> >>>
> >>>
> >>>
> >>>
> >>I've had this switch running pretty much non-stop since last Feburary.
> >> Its been great for my needs thus far. One of the boxes is running
> >>Samba/CVS/www, and it sees quite a bit of traffic. Whether its on its
> >>last leg, that remains to be seen.
> >>Better get on the phone with tech support before they close for the weekend.
> >>But I still think its cables. Because Im writing this email from a
> >>laptop thats also connected to the switch, and here are its details ->
> >>{gsam@laptop}-{~} > ifconfig ed1[27 Dec
> >>2:22pm]
> >>ed1: flags=8843 mtu 1500
> >>inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255
> >>ether 00:50:ba:7a:f0:a3
> >>media: Ethernet autoselect (100baseTX )
> >>status: active
> >>
> >>{gsam@laptop}-{~} > netstat -in [27 Dec
> >>2:15pm]
> >>Name Mtu Network AddressIpkts IerrsOpkts Oerrs
> >>Coll
> >>lo0 16384 0 00
> >>0 0
> >>lo0 16384 127 127.0.0.1 0 -0
> >>- -
> >>ed1 1500 00:50:ba:7a:f0:a344116 635805
> >>0 0
> >>ed1 1500 192.168.0 192.168.0.544049 -35773
> >>- -
> >>
> >>No errors there. Maybe, Ill just make up some new cables, make sure, no
> >>"wall warts" are near them, and see how it goes over the weekend.
> >>If its still problematic, then Ill get the switch replaced.
> >>
> >>
> >
> >Actually, there *are* 6 occurrences under Ierrs here :-(
> >
> >Seeing that you're actually on that switch (using a different port to
> >the other FBSD boxes referenced earlier), then I'd also look hard that
> >the uplink cabling as well - seeing that would be the one length of wire
> >that's common to all hosts off the switch.
> >
> >Good luck with this anyways.., Oh the joys of making patch cable!
> >
> >Regards,
> >
> >Stacey
> >
> >
> >
> >>Thanks for the help you've provided, and Ill let you know how it goes...
> >>
> >>
--
Stacey Roberts
B.Sc (HONS) Computer Science
Web: www.vickiandstacey.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: Network timeouts???
Well after almost 24 hours later, here is what happened...
Shortly after your last post, the situation got worse. I tried banging
the switch with a screwdriver, and that was it.
No more switch. The link light kept flashing, so I knew it was pretty
much dead.
Just so happens, that its a Friday evening, and banks were closed,
credit card is maxed out from Christmas, so
I had to endure a dead network till today.
Got me a brand new switch from Circuit City, and all seems to be well in
the universe. No more errors...
Thanks for all the help...
Stacey Roberts wrote:
On Fri, 2002-12-27 at 19:31, Gerard Samuel wrote:
Stacey Roberts wrote:
So both nic believe themselves to be running okay (as shown in their
respective Oerr counts being 0 each - translation: the nics are fine as
they are able to send all packets okay. Its only in receiving data that
they're returning errors on the link.
I'd suggest that you have a look at the switch itself as well. I know
that this is a desktop switch (read non-enterprise) that is different to
most others in this class as its got *no* cooling fans (hence that bump
on the top). As such, depending on how you hammer this device, there is
the chance of it over-heating. This, of course, is also dependant on
where its actually located as well.
It does have some link / speed / duplex indicator LED's on the front
that can be useful. As well as checking the cabling into the switch, see
if swapping the cables to available ports (except the uplink partner!)
and see if this makes any difference.
I remember one of the guys on my team at work got the Linksys peer to
this switch and rubbished it within 3 weeks due to the switch locking up
under sustained (4+ hours) heavy load transfers at his section lan
point.
Let us know how you get on, and what new information you might have for
us.
Regards,
Stacey
I've had this switch running pretty much non-stop since last Feburary.
Its been great for my needs thus far. One of the boxes is running
Samba/CVS/www, and it sees quite a bit of traffic. Whether its on its
last leg, that remains to be seen.
Better get on the phone with tech support before they close for the weekend.
But I still think its cables. Because Im writing this email from a
laptop thats also connected to the switch, and here are its details ->
{gsam@laptop}-{~} > ifconfig ed1[27 Dec
2:22pm]
ed1: flags=8843 mtu 1500
inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255
ether 00:50:ba:7a:f0:a3
media: Ethernet autoselect (100baseTX )
status: active
{gsam@laptop}-{~} > netstat -in [27 Dec
2:15pm]
Name Mtu Network AddressIpkts IerrsOpkts Oerrs
Coll
lo0 16384 0 00
0 0
lo0 16384 127 127.0.0.1 0 -0
- -
ed1 1500 00:50:ba:7a:f0:a344116 635805
0 0
ed1 1500 192.168.0 192.168.0.544049 -35773
- -
No errors there. Maybe, Ill just make up some new cables, make sure, no
"wall warts" are near them, and see how it goes over the weekend.
If its still problematic, then Ill get the switch replaced.
Actually, there *are* 6 occurrences under Ierrs here :-(
Seeing that you're actually on that switch (using a different port to
the other FBSD boxes referenced earlier), then I'd also look hard that
the uplink cabling as well - seeing that would be the one length of wire
that's common to all hosts off the switch.
Good luck with this anyways.., Oh the joys of making patch cable!
Regards,
Stacey
Thanks for the help you've provided, and Ill let you know how it goes...
--
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
Re: Network timeouts???
On Fri, 2002-12-27 at 19:31, Gerard Samuel wrote:
> Stacey Roberts wrote:
>
> >So both nic believe themselves to be running okay (as shown in their
> >respective Oerr counts being 0 each - translation: the nics are fine as
> >they are able to send all packets okay. Its only in receiving data that
> >they're returning errors on the link.
> >
> >I'd suggest that you have a look at the switch itself as well. I know
> >that this is a desktop switch (read non-enterprise) that is different to
> >most others in this class as its got *no* cooling fans (hence that bump
> >on the top). As such, depending on how you hammer this device, there is
> >the chance of it over-heating. This, of course, is also dependant on
> >where its actually located as well.
> >
> >It does have some link / speed / duplex indicator LED's on the front
> >that can be useful. As well as checking the cabling into the switch, see
> >if swapping the cables to available ports (except the uplink partner!)
> >and see if this makes any difference.
> >
> >I remember one of the guys on my team at work got the Linksys peer to
> >this switch and rubbished it within 3 weeks due to the switch locking up
> >under sustained (4+ hours) heavy load transfers at his section lan
> >point.
> >
> >Let us know how you get on, and what new information you might have for
> >us.
> >
> >Regards,
> >
> >Stacey
> >
> >
> I've had this switch running pretty much non-stop since last Feburary.
> Its been great for my needs thus far. One of the boxes is running
> Samba/CVS/www, and it sees quite a bit of traffic. Whether its on its
> last leg, that remains to be seen.
> Better get on the phone with tech support before they close for the weekend.
> But I still think its cables. Because Im writing this email from a
> laptop thats also connected to the switch, and here are its details ->
> {gsam@laptop}-{~} > ifconfig ed1[27 Dec
> 2:22pm]
> ed1: flags=8843 mtu 1500
> inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255
> ether 00:50:ba:7a:f0:a3
> media: Ethernet autoselect (100baseTX )
> status: active
>
> {gsam@laptop}-{~} > netstat -in [27 Dec
> 2:15pm]
> Name Mtu Network AddressIpkts IerrsOpkts Oerrs
> Coll
> lo0 16384 0 00
> 0 0
> lo0 16384 127 127.0.0.1 0 -0
> - -
> ed1 1500 00:50:ba:7a:f0:a344116 635805
> 0 0
> ed1 1500 192.168.0 192.168.0.544049 -35773
> - -
>
> No errors there. Maybe, Ill just make up some new cables, make sure, no
> "wall warts" are near them, and see how it goes over the weekend.
> If its still problematic, then Ill get the switch replaced.
Actually, there *are* 6 occurrences under Ierrs here :-(
Seeing that you're actually on that switch (using a different port to
the other FBSD boxes referenced earlier), then I'd also look hard that
the uplink cabling as well - seeing that would be the one length of wire
that's common to all hosts off the switch.
Good luck with this anyways.., Oh the joys of making patch cable!
Regards,
Stacey
>
> Thanks for the help you've provided, and Ill let you know how it goes...
--
Stacey Roberts
B.Sc (HONS) Computer Science
Web: www.vickiandstacey.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: Network timeouts???
Stacey Roberts wrote:
So both nic believe themselves to be running okay (as shown in their
respective Oerr counts being 0 each - translation: the nics are fine as
they are able to send all packets okay. Its only in receiving data that
they're returning errors on the link.
I'd suggest that you have a look at the switch itself as well. I know
that this is a desktop switch (read non-enterprise) that is different to
most others in this class as its got *no* cooling fans (hence that bump
on the top). As such, depending on how you hammer this device, there is
the chance of it over-heating. This, of course, is also dependant on
where its actually located as well.
It does have some link / speed / duplex indicator LED's on the front
that can be useful. As well as checking the cabling into the switch, see
if swapping the cables to available ports (except the uplink partner!)
and see if this makes any difference.
I remember one of the guys on my team at work got the Linksys peer to
this switch and rubbished it within 3 weeks due to the switch locking up
under sustained (4+ hours) heavy load transfers at his section lan
point.
Let us know how you get on, and what new information you might have for
us.
Regards,
Stacey
I've had this switch running pretty much non-stop since last Feburary.
Its been great for my needs thus far. One of the boxes is running
Samba/CVS/www, and it sees quite a bit of traffic. Whether its on its
last leg, that remains to be seen.
Better get on the phone with tech support before they close for the weekend.
But I still think its cables. Because Im writing this email from a
laptop thats also connected to the switch, and here are its details ->
{gsam@laptop}-{~} > ifconfig ed1[27 Dec
2:22pm]
ed1: flags=8843 mtu 1500
inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255
ether 00:50:ba:7a:f0:a3
media: Ethernet autoselect (100baseTX )
status: active
{gsam@laptop}-{~} > netstat -in [27 Dec
2:15pm]
Name Mtu Network AddressIpkts IerrsOpkts Oerrs
Coll
lo0 16384 0 00
0 0
lo0 16384 127 127.0.0.1 0 -0
- -
ed1 1500 00:50:ba:7a:f0:a344116 635805
0 0
ed1 1500 192.168.0 192.168.0.544049 -35773
- -
No errors there. Maybe, Ill just make up some new cables, make sure, no
"wall warts" are near them, and see how it goes over the weekend.
If its still problematic, then Ill get the switch replaced.
Thanks for the help you've provided, and Ill let you know how it goes...
--
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
Re: Network timeouts???
On Fri, 2002-12-27 at 18:34, Gerard Samuel wrote:
> 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...
>
>
> >>>
> >>hivemind# netstat -in
> >>Name Mtu Network AddressIpkts IerrsOpkts Oerrs
> >>Coll
> >>fxp0 1500 00:80:29:12:90:b9 366170 27094 426767
> >>3110
> >>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 AddressIpkts IerrsOpkts Oerrs
> Coll
> fxp0 1500 00:80:29:12:9c:2074003 3112583139
> 117 3
> fxp0 1500 192.168.0 192.168.0.1 5910 - 1114
> - -
> ed0 1500 00:00:c0:29:52:48 401134 068811 0
> 3161
> ed0 1500 68.39.128/21 68.39.132.244 2759 - 403
> - -
> lo0 16384766 0 766
> 0 0
> lo0 16384 127 127.0.0.1 4 -4
> - -
>
Yes, this box as well has pretty much the same occurrence of Ierrs, and
also noteworthy, no Oerrs - just like the previous box.
> {gsam@gatekeeper}-{~} > ifconfig fxp0 [27 Dec
> 1:22pm]
> fxp0: flags=8843 mtu 1500
> inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
> ether 00:80:29:12:9c:20
> media: Ethernet autoselect (100baseTX )
> status: active
>
> hivemind# netstat -in
> Name Mtu Network AddressIpkts IerrsOpkts Oerrs
> Coll
> fxp0 1500 00:80:29:12:90:b9 370620 27557 430514
> 3210
> 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 0xff00 broadcast 192.168.0.255
> ether 00:80:29:12:90:b9
> media: Ethernet autoselect (100baseTX )
> status: active
>
So both nic believe themselves to be running okay (as shown in their
respective Oerr counts being 0 each - translation: the nics are fine as
they are able to send all packets okay. Its only in receiving data that
they're returning errors on the link.
I'd suggest that you have a look at the switch itself as well. I know
that th
Re: Network timeouts???
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 AddressIpkts IerrsOpkts Oerrs
Coll
fxp0 1500 00:80:29:12:90:b9 366170 27094 426767
3110
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 AddressIpkts IerrsOpkts Oerrs
Coll
fxp0 1500 00:80:29:12:9c:2074003 3112583139
117 3
fxp0 1500 192.168.0 192.168.0.1 5910 - 1114
- -
ed0 1500 00:00:c0:29:52:48 401134 068811 0
3161
ed0 1500 68.39.128/21 68.39.132.244 2759 - 403
- -
lo0 16384766 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 0xff00 broadcast 192.168.0.255
ether 00:80:29:12:9c:20
media: Ethernet autoselect (100baseTX )
status: active
hivemind# netstat -in
Name Mtu Network AddressIpkts IerrsOpkts Oerrs
Coll
fxp0 1500 00:80:29:12:90:b9 370620 27557 430514
3210
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 0xff00 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" (ifconf
Re: Network timeouts???
On Fri, Dec 27, 2002 at 12:46:24PM -0500, Gerard Samuel wrote: > hivemind# netstat -in > Name Mtu Network AddressIpkts IerrsOpkts Oerrs > Coll > fxp0 1500 00:80:29:12:90:b9 366170 27094 426767 > 3110 > 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 > - - > > >netstat -s > > > Its too long. Don't want to offend anyone with a long debug output > 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... > -- > Gerard Samuel > http://www.trini0.org:81/ > http://dev.trini0.org:81/ What are all those Ierrs? They are almost at a 10% rate. How is the cabling? Does is pass over/near any significant source of interference? Maybe the node on the other end is having troubles? Nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Network timeouts???
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 AddressIpkts IerrsOpkts Oerrs > Coll > fxp0 1500 00:80:29:12:90:b9 366170 27094 426767 > 3110 > 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 > >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 [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Network timeouts???
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 AddressIpkts IerrsOpkts Oerrs Coll fxp0 1500 00:80:29:12:90:b9 366170 27094 426767 3110 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 - - 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
Re: Network timeouts???
Hi, I would suggest using the media switch with ifconfig - more than likely you have a card thinking half duplex and a switch full duplex.. The command is ifconfig rl1 media 10baseT/UTP rl1 being the card and select either 10/100mb. This will force the card into a mode. Kind Regards Doron Shmaryahu - Original Message - From: "Stacey Roberts" <[EMAIL PROTECTED]> To: "Gerard Samuel" <[EMAIL PROTECTED]> Cc: "FreeBSD Questions" <[EMAIL PROTECTED]> Sent: Friday, December 27, 2002 5:50 PM Subject: Re: Network timeouts??? > 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 > netstat -s > netstat -m > > At the least, you could try "bouncing" (ifconfig down / ifconfig up) the > interfaces if the situation degrades dramatically. > > Hope this helps. > > Stacey > > -- > Stacey Roberts > B.Sc (HONS) Computer Science > > Web: www.vickiandstacey.com > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Network timeouts???
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 netstat -s netstat -m At the least, you could try "bouncing" (ifconfig down / ifconfig up) the interfaces if the situation degrades dramatically. Hope this helps. Stacey -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
