From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 14 Aug 2001 05:15:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 14 Aug 2001 05:14:52 -0400 Received: from vitelus.com ([64.81.36.147]:19211 "EHLO vitelus.com") by vger.kernel.org with ESMTP id ; Tue, 14 Aug 2001 05:14:36 -0400 Date: Tue, 14 Aug 2001 02:14:45 -0700 From: Aaron Lehmann To: linux-kernel@vger.kernel.org Subject: 3c905b works with 10bt hub - not with 10/100 switch Message-ID: <20010814021445.A7454@vitelus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I've been having major problems on my network as of today. For the purpose of this explaination, there are two machines: the Server and the Client. The Server has the following network card setup: 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c590 Vortex 10Mbps at 0xd800, <6>eth0: Overriding PCI latency timer (CFLT) setting of 32, new value is 248. 00:20:af:f8:2d:c4, IRQ 11 product code 4244 rev 00.0 date 11-06-95 32K byte-wide RAM 1:1 Rx:Tx split, autoselect/10baseT interface. eth0: scatter/gather disabled. h/w checksums disabled PCI: Found IRQ 11 for device 00:0a.0 IRQ routing conflict in pirq table for device 00:0a.0 eth1: 3Com PCI 3c905 Boomerang 100baseTx at 0xdc00, 00:60:97:31:d9:bd, IRQ 10 product code 4848 rev 00.0 date 11-04-96 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. eth1: scatter/gather enabled. h/w checksums disabled PCI: Found IRQ 10 for device 00:0b.0 IRQ routing conflict in pirq table for device 00:0b.0 eth2: 3Com PCI 3c905B Cyclone 100baseTx at 0xe000, 00:10:4b:79:46:76, IRQ 12 product code 4e4b rev 00.9 date 04-17-98 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. eth2: scatter/gather enabled. h/w checksums enabled The card we are interested in is eth2. It is what connects the server to the segment of the network which I will describe. The server is running 2.4.4. On the client, we have this simpler ethernet configuration: PCI: Found IRQ 9 for device 00:0f.0 PCI: Sharing IRQ 9 with 00:03.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 00:0f.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xcc00. Vers LK1.1.16 The Client is running 2.4.8-ac2. This morning, the connection between these two machines (and a few others which were idle or powered down) was a very simple 5 port 10 base T hub. This makes NFS pretty miserable, which is why I installed a CentreCOM FS704 Fast Ethernet switch in place of the hub today. At first, it worked great. The machines negotiated full duplex and were on the network. I was able to get expected speeds out of the network. In the late afternoon, I was not at home, but ssh'd into Server. I was rather shocked that I could not ping Client. When I got home, the first thing I did was investigate this further. When either machine tried to ping the other, the correct lights on the hub blinked, but no packages were recieved. Shortly after this experimentation, Client started complaining about invalid arguments whenever I tried to su and proceeded to lock up pretty hard. "Oh well," I thought, "It's was in a bad state, but after a reboot it should work." Wrong. After a reboot, the pings were still not able to reach each other. Substituting back the old slow hub caused things to work perfectly again. I decided to try forcing a particular mode of duplex. After compiling the driver as a module, I tried insmoding it with full_duplex=0 and full_duplex=1. This caused even more problems, yielding Tx timeout errors on one of them and not working with the other, even with the hub. Just then, my scsi0 card tried to reset the scsi bus for no apparent reason and locked up the system. I thought to myself "Ah hah, Client's 3c905 is sharing an IRQ with scsi1 (NOT scsi0, i had two different cards)." To make things simple, I removed scsi1 from the system. However, even this didn't help! Now my 3c905 is sharing an IRQ with my emu10k1, and it still works fine with the hub but not with the switch (BTW: I went back to a compiled-in driver at this point). This is really, really weird. I'm pretty sure the switch is okay because I have two units, and each does the same thing. The odd thing is the switch was working fine this morning, when I just installed it. I would like to have tried a crossover cable between Client and Server, but they're over 100 feet apart and I don't have a crossover cable that long, nor do I have a double female adaptor that would allow me to tack on a crossover cable handy (!@#$ it must be around her somewhere!). Anyway, I'm hoping somebody can shed light on what's going on from the perspective of the driver. P.S. I JUST realized that I nearly trashed a 100base T hub for displaying essensially the exact behavior as I saw in the switches! And similarly, it worked at first and then never worked again, although the hub worked for a few months instead of the partial day of the switch. And this must have been 6 months to a year ago! Perhaps the card in Server or Client is having trouble running correctly at 100mbits. I'd be happy to perform more tests. I'd even give out network access as necessary. I just don't want to be stuck at 10mbits! Uh oh, I'm finding data as I write this post. Well, I hope that's alright. At least, I hope nobody minds this weird style. Anyway, I just brought another machine onto the network. For the sake of neutrality, it was an old mac 68k with MacTCP. It only does 10megabits, but I don't think that matters -- I'm just trying to figure out whether Server or Client's ethernet is dying once on a 100mbit network. And the answer is... Server's! Client can ping Mac on the switch, Server can't. So, looks like there are some problems with eth2 in Server. That's odd. I'm not getting any interesting messages. At most, I'm getting eth2: Setting full-duplex based on MII #24 link partner capability of 41e1. when plugging into the switch and eth2: Setting half-duplex based on MII #24 link partner capability of 4021. when connecting to the hub. So, I suppose this boils down to: is this a driver bug for the 905B (eth2 is the only Cyclone I have), or is the card defective? I'll do what I can to debug, and try to cooperate with the driver developers, but I think I have some eepro cards that are kind of tempting to pop in and try. Good luck, Aaron Lehmann