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
with the followups.
Anders K. Pedersen