Fast Ethernet Stalls with NetGear FA310TX Rev.D1

[Tom Crockett]

> This problem seems very similar to the one we were getting with SMC Etherpower
> || cards. We solved this by putting in a usleep(1) in the *_start_xmit()
> function just before the transmitt demand is triggered.
> 
>         tp->tx_ring[entry].length = skb->len | flag;
>         tp->tx_ring[entry].status = 0x80000000; /* Pass ownership to the chip. */
>         tp->cur_tx++;
> 
>         usleep(1);
> 
>         /* Trigger an immediate transmit demand. */
>         outl(0, dev->base_addr + CSR1);
> 
>         dev->trans_start = jiffies;
> 
> Although this is a different chipset, it may be worth a try.

Terry,

Thanks for the suggestion.  We had to go with a 2 microsecond delay to
eliminate stalls on our system, but that did the trick.  We're using the
Pentium's time-stamp counter for fine-grained timing, and found that
anything less than 2 microseconds still produced occasional stalls.

We're not entirely happy about introducing that much idle time into the
already-expensive communication stack, so now we're trying to figure out
why the delay is necessary and whether some less expensive approach
might be equally effective.  If anyone can shed light on this, we'd love
to hear from you.  Our current thinking is that it somehow relates to
memory-management and cacheing, but other scenarios might be possible.

-Tom

-- 
Tom Crockett

ICASE
Institute for Computer Applications in Science and Engineering

M.S. 132C                                 email:  tom@icase.edu
NASA Langley Research Center              phone:  (757) 864-2182
Hampton, VA  23681-2199                   fax:    (757) 864-6134

Home Page:  http://www.icase.edu/~tom/