[vortex-bug] 3c59x 0.99H and 3c905B (Cyclone) problems

[Bogdan Costescu]

On Thu, 3 Aug 2000, Bob Ramstad wrote:

> the system in question was running just fine when it was connected to
> a 10 mbps hub.  we recently replaced this hub with an autosensing
> 10/100 mbps switch and as a result, this particular system cannot see
> the LAN at all.  (this is our only Linux box.)  

Please report results from vortex-diag (also available from ftp.scyld.com)
and mii-diag with -mm flag in both cases of connection.
I'm a bit puzzled by the second mii-diag report of MII not found... This
should happen only if you set (using the DOS utility) the card in a forced
mode - the MII will not be searched for and not initialized, so it's not
reported. But you should see this in the init message (100base-Tx instead
of MII/autonegotiate).

Does the Windows driver report link state and speed ?

What kind of Netgear switch are you using ? (if you specified it, I missed
it, sorry!).

To answer the Cisco related questions/suggestions:

I have 905B and 905C cards connected to a Cisco 5000 series switch which
has the spanning tree protocol enabled (along with a lot of other things)
and I need to wait up to a minute to get an ARP reply (during this time
the workstation receives packets - only broadcast, as this is a switch -
but it waits for an ARP reply from the gateway device; I also tried to not
define a gateway device and access only the local hosts - the same
behaviour...)

However, the same behaviour is observed with tulip cards, SMC cards
(driven by epic100), RTL8139 cadrs, Intel cards and some NICs in SGI MIPS
machines (I don't know the type...) . Another user had the same problem
some time ago and I sent the same description of the problem; after some
days he replied that it's possible to set some kind of "Fast start" in the
switch which reduces this time about 20 seconds (but I haven't tried as
this switch is not managed by me - but I rarely reboot my workstations).

However, the card comes up in the right state (I never had
autonegotiation problems with this switch and all the cards listed above)
and if you wait for this time, you can work just fine (this is true for
all the above cards). This pause is not caused by the card/driver, but by
the upper levels of communication (IP) who needs the ARP information... As
soon as the ARP reply is received, the IP level knows where to send
packets and starts functioning (or a least that's my understading).

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De