[2.4 PATCH] pcnet32.c - tx underflow error

[2.4 PATCH] pcnet32.c - tx underflow error

[Jun Sun]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

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

[-- Attachment #2: pcnet32.patch --]
[-- Type: text/plain, Size: 693 bytes --]

diff -Nru linux/drivers/net/pcnet32.c.orig linux/drivers/net/pcnet32.c
--- linux/drivers/net/pcnet32.c.orig	Tue Jul  9 15:05:55 2002
+++ linux/drivers/net/pcnet32.c	Tue Jul  9 18:28:19 2002
@@ -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;
     }

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> 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

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> 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

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Jun Sun]

Alan Cox wrote:

>>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

> Please apply
> some kind of heuristic to this - eg switch to delaying if you exceed
> 50 failures in a 60 second period.
> 
> Alan
> 

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Jun Sun]

Alan Cox wrote:

>>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

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> > 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Alan Cox]

> > 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Jason Gunthorpe]

On Wed, 10 Jul 2002, Jun Sun wrote:

> > 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. 

> 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

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Thomas Bogendoerfer]

On Thu, Jul 11, 2002 at 03:16:03AM +0100, Alan Cox wrote:
> > 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Marcelo Tosatti]

On Thu, 11 Jul 2002, Alan Cox wrote:

> > 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Marcelo Tosatti]

On Thu, 11 Jul 2002, Alan Cox wrote:

> > 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.

Re: [2.4 PATCH] pcnet32.c - tx underflow error

[Jun Sun]

Marcelo Tosatti wrote:

> 
> On Thu, 11 Jul 2002, Alan Cox wrote:
> 
> 
>>>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.
> 


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