netdev
[Top] [All Lists]

Re: Ethernet lockup (Linksys, Tulip)

To: netdev@xxxxxxxxxxx
To: Bogdan.Costescu@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Ethernet lockup (Linksys, Tulip)
From: "Anders K. Pedersen" <akp@xxxxxx>
Date: Fri, 02 Jun 2000 16:39:37 +0200
Newsgroups: akp.lists.linux.netdev
Organization: AKP Consult I/S
References: <39379DFB.78686F0B@akp.dk> <Pine.LNX.4.10.10006021539470.6206-100000@kenzo.iwr.uni-heidelberg.de>
Sender: owner-netdev@xxxxxxxxxxx
Bogdan Costescu wrote:
> 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).

One of the last things done in the tx_timeout() is to reset the card - I
guess that this might cause the card not to generate the interrupt, that
will clear dev->tbusy.

> 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.

Well, in our case, the driver never resumed sending any packets after
the first timeout - at least not until it was restarted with ifconfig.
It was discussed a few weeks ago on linux-net, and Donald Becker said,
that it should not happen (the timeouts as I understand it), but the fix
was to clear dev->tbusy. Andrew Morton implemented it in his version of
the driver, and it is now part of the 3c59x.c driver in the newest
kernels (both 2.2.x and 2.3.x).

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

As I mentioned above, it was discussed on the linux-net list a few weeks
ago. You can find my initial mail at
http://kernelnotes.org/lnxlists/linux-net/ln_0005_04/msg00033.html along
with the followups.

Regards,
Anders K. Pedersen

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