[Top] [All Lists]

Re: Ethernet lockup (Linksys, Tulip)

To: "Anders K. Pedersen" <akp@xxxxxx>
Subject: Re: Ethernet lockup (Linksys, Tulip)
From: Bogdan Costescu <Bogdan.Costescu@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 2 Jun 2000 16:16:34 +0200 (CEST)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <39379DFB.78686F0B@xxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Fri, 2 Jun 2000, Anders K. Pedersen wrote:

> This looks like a problem I had with a 3c590 card recently. When
> tulip_tx_timeout() is called from tulip_start_xmit(), dev->tbusy is
> never cleared, and whenever tulip_start_xmit() is called after this, it
> will call tulip_tx_timeout() as dev->tbusy remains set. You could try
> adding the line "clear_bit(0, (void*)&dev->tbusy);" to the bottom of
> tulip_tx_timeout().

By doing this you break the whole logic of setting and clearing
dev->tbusy. It should be set whenever start_xmit cannot be called to
handle another packet which is your case - the Tx ring is still full.
When you reconnect the cable, the card could start sending packets, thus
generating interrupts which will clear dev->tbusy. (I'm talking now for
the 3c59x driver, but I think that all of Donald Becker's drivers use the
same logic).

I said above: the card _could_ start sending. There are some situations
when the card cannot start sending immediately after the link is
established: collisions (you connect to a heavily loaded hub), failed or
inexistent media speed (auto-)negotiation and maybe some others that don't
come to my mind right now.
The collisions are also handled by tx_timeout which will be called again
(having dev->tbusy _not_ cleared).
If, when you re-establish the link, the speed (auto-negotiated or not)
used by the switch differ from the previous one, you have to wait until
the timer routine is called (once every 60 seconds in most cases) that
will (hopefully) rewrite the media settings to the card which will then be
able to talk to the switch; if this does not happen, the card will not be
able to send any more packets.

So, after you re-establish a link, the transmission might not start
immediately and there may be some other tx_timeout calls until the
transmission is really resumed.

In the 3c590 case, can you give some more details (exact type of the
board, conditions, logs), preferably on the linux-vortex-bug list ?

Best regards,

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@xxxxxxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>