Fast Ethernet Stalls with NetGear FA310TX Rev.D1

Bill Moshier
Wed Apr 7 13:49:08 1999

Tom -
I don't know if this applies, but I was just examining a site
that talks about delays, especially in smaller messages.  See
if it helps.


-----Original Message-----
From: Tom Crockett []
Sent: Wednesday, April 07, 1999 10:21 AM
Subject: Re: Fast Ethernet Stalls with NetGear FA310TX Rev.D1

> This problem seems very similar to the one we were getting with SMC
> || 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.


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 Crockett

Institute for Computer Applications in Science and Engineering

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

Home Page: