pcnet32.c - tx underflow error
Subsystems (2)
PATCH 1/1 pcnet32.c - tx underflow error
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Jun
drivers/net/pcnet32.c renamed from drivers/net/pcnet32.c.orig +2 -2
@@ -569,7 +569,7 @@break ;case 0x2625 : chipname ="PCnet/FAST III 79C973" ;/* PCI */ - fdx =1 ; mii =1 ; + fdx =1 ; mii =1 ; fset =1 ;break ;case 0x2626 : chipname ="PCnet/Home 79C978" ;/* PCI */
@@ -613,7 +613,7 @@if (fset) { a->write_bcr (ioaddr,18 , (a->read_bcr (ioaddr,18 ) |0x0800 )); - a->write_csr (ioaddr,80 , (a->read_csr (ioaddr,80 ) &0x0C00 ) |0x0c00 ); + a->write_csr (ioaddr,80 , (a->read_csr (ioaddr,80 ) & ~0x0C00 ) |0x0c00 ); dxsuflo =1 ; ltint =1 ; }
Quoted 4 lines
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Which slows the stuff down for people with real computers. Please apply some kind of heuristic to this - eg switch to delaying if you exceed 50 failures in a 60 second period.
Alan
Quoted 6 lines · Alan Cox
Quoted 4 lines
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Which slows the stuff down for people with real computers.
Contrary to what it might appear at first glance, it does not really.
While it delays the start of a transmission of the first packet, the delay does not aggregate in a steam of data. The bottle neck is either in upper layer (how fact upper layer generates packets) or in the link layer (when we exceed the maximum bandwitch of the wire, in which case we always have plenty of full packets to send).
The delay itself is small (should be < 100us typically). So there is no impact on interactive packets. Note if the delay is not small (e.g., on system where PCI bus arbitration may be broken), then you *will* have the tx underflow problem.
So on a good system the delay should be really small (especially if you compare to what it takes to transmit the whole packet to the other end). On a bad system where the delay can be long, then you will need the fix anyway.
Jun
Quoted 6 lines
Please apply
some kind of heuristic to this - eg switch to delaying if you exceed 50 failures in a 60 second period.Alan
Quoted 3 lines
Quoted 1 line
Which slows the stuff down for people with real computers.
Contrary to what it might appear at first glance, it does not really.
Throughput and latency are quite different things. Try that on a latency sensitive setup like a beowulf.
Quoted 3 lines · Jun Sun
Quoted 1 line
Which slows the stuff down for people with real computers.
Contrary to what it might appear at first glance, it does not really.
I studied this sort of a problem to some extent on my system using a 8139 card..
Eventually it turned out to be poor arbitrartion between the PCI interface and the CPU within the system controller. What happens is that the memcpy from the skbuf to the packet ring in the driver ends up generating a steady stream of very small writes that starve out PCI access. This is a particular quirk of our system controller but I wouldn't be surprised if other controllers had a simlar problem.
A good fix is to use a cached+flushed tx buffer which will lower the observed DMA latency considerably.
There are some situations where a badly implemented PCI controller can cause high enough latency if other devices are trying to use the bus, it depends on how much the interface can burst and where the low watermark is on the ethernet card. Most scenarios are unlikely though IMHO.
If you have access to a PCI bus tracer you can determine where the problem lies pretty quickly.
Quoted 1 line
The delay itself is small (should be < 100us typically). So there is no
Actually it should be << 30us on an unloaded system. Measurements I've done on my box are about 13us for a 8139 to read a 1.5K pkt over PCI.
Jason
Quoted 6 lines · Alan Cox
Quoted 4 lines
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Which slows the stuff down for people with real computers.
BTW, I have seen this problem on four boards (including Malta, two NEC boards and a Hitachi board). Not surprisingly the problem mostly happens when you connect to 100Mb/s network.
I even suspect this is the default setting on PCI cards on PC. Can someone verify? If that is the case, that will explain why driver never sets this bit. Maybe we don't have any "real computers" after all. :-)
Jun
Quoted 3 lines
I even suspect this is the default setting on PCI cards on PC. Can someone verify? If that is the case, that will explain why driver never sets this bit. Maybe we don't have any "real computers" after all. :-)
Most PC hardware can deliver that kind of DMA guarantee. UDMA100 doesn't work very well otherwise.
Quoted 6 lines · Alan Cox
Quoted 3 lines
I even suspect this is the default setting on PCI cards on PC. Can someone verify? If that is the case, that will explain why driver never sets this bit. Maybe we don't have any "real computers" after all. :-)
Most PC hardware can deliver that kind of DMA guarantee. UDMA100 doesn't work very well otherwise.
I've seen this problem on a lot of PC hardware, too. The best fix would be to enable full packet mode, when the driver sees too much TX underruns.
Thomas.
Quoted 8 lines · Alan Cox
Quoted 4 lines
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Which slows the stuff down for people with real computers. Please apply some kind of heuristic to this - eg switch to delaying if you exceed 50 failures in a 60 second period.
I haven't applied it yet.
I'll let it come to me throught Jeff Garzik after the issues are resolved.
Quoted 9 lines · Marcelo Tosatti
Quoted 5 lines · Alan Cox
Quoted 5 lines
This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.
The patch is already accepted by Marcelo for the 2.4 tree, I think.
Quoted 9 lines
Quoted 4 lines
Which slows the stuff down for people with real computers. Please apply some kind of heuristic to this - eg switch to delaying if you exceed 50 failures in a 60 second period.
I haven't applied it yet.
I'll let it come to me throught Jeff Garzik after the issues are resolved.
Like I said earlier, I don't believe the benefit of run-time approach is worth the effort. BTW, the heuristic method is not simple, mainly because there are mixed bags of chips in this family which requires different handling in this regard.
Since Alan seems to oppose this patch, I will fix this problem for now in the board code/firmware, which is not a totally unreasonable solution anyway. After all the firmware knows this board bus cannot handle 100Mb/s net. If more people report the same problem later, that might be a better time to how to solve this problem.
Jun