Messages in this thread | | | Date | Thu, 12 Feb 1998 00:16:39 -0600 (CST) | From | Solitude <> | Subject | 2.0.33 ethernet collision problems |
| |
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
| |