Fast Ethernet Stalls with NetGear FA310TX Rev.D1
Wed Apr 7 13:49:08 1999
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.
From: Tom Crockett [mailto:firstname.lastname@example.org]
Sent: Wednesday, April 07, 1999 10:21 AM
Cc: email@example.com; firstname.lastname@example.org;
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
> /* 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: email@example.com
NASA Langley Research Center phone: (757) 864-2182
Hampton, VA 23681-2199 fax: (757) 864-6134
Home Page: http://www.icase.edu/~tom/