2.0.33 ethernet collision problems

Solitude (solitude@solitude.flinthills.com)
Thu, 12 Feb 1998 00:16:39 -0600 (CST)


Hello!

I wrote to this list with this problem about a month back and I've gotten
some good suggestions. Well, I'm sorry to report that the problems are
persisting...

I have several linux servers on a network comprised of several 10-mbit
switches (not hubs, but switches) and a couple 100-mbit switches. The
great majority of the client machines on this network are regular PC's
running Win95. The problem is this - any moderate ammount of data
transfer *always* triggers collisions on the main linux server. For
example, I created a 20mbyte file and grabbed it via samba from a win95
machine. While transferring the file the collision light was just solid.
Each port has a seperate collision light, and the only port that ever has
collisions is the linux box.

I preformed this test many times and with many different pieces of
hardware, different protocols, etc. I am confident that the probem is not
hardware, it is not the win95 boxes, it is not the cabling, and it is not
the switches. The only odd result that I observed was that a flood-ping
from the linux box to a win95 client would NOT trigger these constant
collisions. Anything else though, such as the aforementioned smb
transfer, or a ftp, http, or smtp transfer all suffer from this collision
problem.

I tried EVERY suggestion that I recieved the last time I posted about this
problem, and most of the responses were suggestions to check the duplex
settings on the linux box and on the switches. I have determined that
this is not the problem. I forced the hubs and the server to half-duplex
and the collisions persisted. I forced everything to full-duplex and
collisions persisted. I set everything back to the default settings of
'automatic duplex' and the hub chose half-duplex, and the problems
persisted.

This was with kernel 2.0.33 and a wide variety of ethernet cards, most of
which have been 3com cards. If any technical details are required then I
will certinatley provide them. Any help will be greatly appriceated!

I did forget to mention one point - this problem has been periodically
causing what I will refer to as an ethernet transciever lockup. After a
certain ammount of collisions the linux server's network card will simply
fail. Numerous ethernet-driver level errors are written to syslog with
certain ethernet cards and the linux machine is no longer able to
communicate on the network with all cards except for a 3c509. Rebooting
the machine fixes the problem, while 'ifconfig eth0 down ; ifconfig eth0
up ; /etc/rc.d/rc.inet1' does not fix the problem.

Again, your assistance is appriceated!

- John
<solitude@solitude.flinthills.com>
<jsf8471@ksu.edu>

"Microsoft doesn't innovate, it copies and re-markets ideas. As the
competition is squelched by Microsoft's monopoly, so goes the
innovation...." --Jonathan Farmer

NO SOLICITING!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQCNAzQGhkEAAAEEAM3QKHqclaVqT3DYHXopHFbfTtx3MeDOXJgNAfxRulKwTZan
BL1+Ld6/x/wAHZT6pr2YifQFn/pKt+K3GODM4wfAtE4Us/Os9SE8pI9pcAUfFnUU
o28/LyIbM0rpBSdWuatBNXezD5rMbpdoGgRzExXx+ThoLkTt6wGB7TRORpJNAAUT
tBxKb2huIEZyZWFyIDxqc2Y4NDcxQGtzdS5lZHU+iQCVAwUQNAaGQQGB7TRORpJN
AQHLGAP/YK5XkVD0F0E81KHlcUhu/0zJrEUWlpmjfw/D0DkJTvI1oxjGHeeyKuF1
CKmZu0kQIeoT8Z/Fh9Lel5YNAt2IPf5FarLFyxfSytd/e0BSMZdisOPHS8JT3nqi
CIyZKhrusb77vUXOKoOs83QoQYaPTUjT3t2H88dKfSdSN8+PusA=
=yXiZ
-----END PGP PUBLIC KEY BLOCK-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu