On Fri, 25 Jan 2002, Fabien Ribes wrote: > Is it possible to avoid Tx errors appearing below ?? It's quite > important since it corrupts frames holding UDP packets for a real-time > application. Even if 4 out of 153299 may seem acceptable, It wrecks the > whole thing ! Hmmm, it's curious that see both FIFO and carrier errors -- these should be independent error sources. > Corrupted frames are partially transmitted ( for example 1367 out of > 1374 bytes are sent before truncation) This also doesn't look like a regular Tx FIFO underrun. It's should be rare that only the very end of the packet is missing. I would expect that the packet would be truncated at a PCI burst boundary, with an invalid CRC. > eth2 driver is > #define DRV_NAME "natsemi" > #define DRV_VERSION "1.07+LK1.0.13" > #define DRV_RELDATE "Oct 19, 2001" > in a 2.4.16 ppc kernel If this is really a Tx FIFO underrun, here are your options: You can adjust the PCI parameters so that no devices hogs the bus. The natsemi-815 chip can effectively use the PCI bus with long bursts, so there must be some other device in the system that is causing the problem. Normally the driver starts with a conservative Tx threshold value, and increases it with every underrun. You can modify the initial value to store-and-forward by setting the initial threshold value to be a full packet. You can write your protocol to accept that Ethernet will occasionally drop packets. In this case you know that the 4 packets were dropped during transmit, but what about when a switch randomly drops packets (as some do). Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
