3c905b works with 10bt hub - not with 10/100 switch

3c905b works with 10bt hub - not with 10/100 switch

[Aaron Lehmann]

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

Re: 3c905b works with 10bt hub - not with 10/100 switch

[Christian Widmer]

so if i understood correctly you did your test only with that 3Com's that
are your eth2@server (3Com PCI 3c905B) resp. eth0@client 
(3Com PCI 3c905B). do you have another 3Com PCI 3c905B? 
exchange one after the other and test again. i'had exactly the same 
with some tulip NIS's when switching from a 10Mb to a 100Mb hub. 
after exchanging one of the tulipNIS's it worked fine.

chris

On Tuesday 14 August 2001 11:14, Aaron Lehmann wrote:
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 3c905b works with 10bt hub - not with 10/100 switch

[Aaron Lehmann]

On Tue, Aug 14, 2001 at 11:42:23AM +0200, Christian Widmer wrote:
> so if i understood correctly you did your test only with that 3Com's that
> are your eth2@server (3Com PCI 3c905B) resp. eth0@client 
> (3Com PCI 3c905B). do you have another 3Com PCI 3c905B? 
> exchange one after the other and test again. i'had exactly the same 
> with some tulip NIS's when switching from a 10Mb to a 100Mb hub. 
> after exchanging one of the tulipNIS's it worked fine.

No, no spare 3com PCI cards whatsoever. I just tried a 3c595 but it
was stone dead. About to try an eepro100.

Thanks for the data point.

Re: 3c905b works with 10bt hub - not with 10/100 switch

[Aaron Lehmann]

On Tue, Aug 14, 2001 at 02:14:45AM -0700, Aaron Lehmann wrote:
> I've been having major problems on my network as of today.

I seem to have solved this problem.

I put in a 3c595 - same problem.

Luckily, I had the persistance to try another card. I chose to try
Client's eth0 as Server's eth2. Well, it worked.

I hope this network setup will work on a switch for longer than the
3c905b did.

Re: 3c905b works with 10bt hub - not with 10/100 switch

[Andrzej Krzysztofowicz]

Aaron Lehmann wrote:
> On Tue, Aug 14, 2001 at 02:14:45AM -0700, Aaron Lehmann wrote:
> > I've been having major problems on my network as of today.
> 
> I seem to have solved this problem.
> 
> I put in a 3c595 - same problem.
> 
> Luckily, I had the persistance to try another card. I chose to try
> Client's eth0 as Server's eth2. Well, it worked.
> 
> I hope this network setup will work on a switch for longer than the
> 3c905b did.

Did you check the board's NVRAM setting for media type ?
AFAIR changing Auto/Manual was related with this problem.

But I hit it about three years ago...

Andrzej
-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: 3c905b works with 10bt hub - not with 10/100 switch

[Russell King]

On Tue, Aug 14, 2001 at 02:14:45AM -0700, Aaron Lehmann wrote:
> 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
>
> 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.

Interesting point here - did you check whether the 3c905B was in 10bT
or 100bTx mode?

The reason I ask is that I have a FH705 hub at home, with a 3c905C Tornado
card.  It normally negociates 100bTx with the hub at power on, but
if for whatever reason it drops down to 10bT, the only way of getting
it back to 100bTx is with a power cycle of the 3c905C (and hence the
machine).

No amount of prodding with mii-diag (forcing media selections, resetting
the mii transceiver) will recover it - only a power cycle solves it.

Luckily, it doesn't do it spontaneously, and has been running at 100bTx
for the past months.  Since it is my main server, and works, I'm not too
eager to investigate futher.  You might be interested in this data point
however.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html