Fast Ethernet Stalls with NetGear FA310TX Rev.D1
Wed Apr 7 13:21:11 1999
> 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. */
> /* 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.
Institute for Computer Applications in Science and Engineering
M.S. 132C email: firstname.lastname@example.org
NASA Langley Research Center phone: (757) 864-2182
Hampton, VA 23681-2199 fax: (757) 864-6134
Home Page: http://www.icase.edu/~tom/