Tx-timeout patch

[Eric Kasten]

> The timeout accured because the Tx-PDMA engine was restarted even if it 
> was still running (the Docuementation does not say what happens if you
> do so). So I changed the following line in hamachi_start_xmit to take care
> of the actual state of the TxPDMA engine and the timeout errors are gone.
> I also put the Tx-Intrrupt-patch from Peter Monta in this patch.

This is fine.  I'll stick it in my driver code if it has been 
verified that it works properly.  Adding the DescIntr to the
tx ring probably isn't worth much in my version of the driver, since
there's no processing done in the interrupt routine regarding txs.
Checking the status may be a good idea, depending on what the card
does when it receives a start command.

> I had a look at the new driver from Eric Kasten and I think there is a
> problem with the tx_full flag.
> In Eric's driver, the tx_full flag is only cleared when hamachi_start_xmit
> is called. But hamachi_start_xmit should not be called by the kernel when 
> tx_full is set. So the Driver stalls as soon as the Tx-queue is full.
> Tx_full must be cleared from within the interrupt driver,
> or am I overlooking something ?

The tx_full flag is in the hamachi_private struct.  From the
way it looks, nothing but the hamachi driver pays any attention
to it. The dev->tbusy flag may be a problem,
however, it may be a good idea to test/reset the dev->tbusy flag
from the interrupt handler.  At this point you'll want the
DescIntr on the tx ring.  I'd run this up myself, but I'm without
hardware at the moment.

...Eric

Eric Kasten
kasten@nscl.msu.edu
National Superconducting Cyclotron Lab
(517) 333-6412
 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.