From jeremyp@gsmx07.alcatel.com.au Wed Mar 10 17:55:28 1999
Return-Path: <jeremyp@gsmx07.alcatel.com.au>
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id 618EC151B1
	for <FreeBSD-gnats-submit@FreeBSD.ORG>; Wed, 10 Mar 1999 17:55:20 -0800 (PST)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40394>; Thu, 11 Mar 1999 11:42:59 +1000
Message-Id: <99Mar11.114259est.40394@border.alcanet.com.au>
Date: Thu, 11 Mar 1999 11:54:49 +1000
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Reply-To: peter.jeremy@alcatel.com.au
To: FreeBSD-gnats-submit@FreeBSD.ORG
Cc: jeremyp@gsmx07.alcatel.com.au
Subject: Very poor ethernet performance with tx driver
X-Send-Pr-Version: 3.2

>Number:         10535
>Category:       kern
>Synopsis:       Very poor ethernet performance with tx driver
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 10 18:00:00 PST 1999
>Closed-Date:    Fri Mar 26 03:02:42 PST 1999
>Last-Modified:  Sat Jun 12 22:00:01 PDT 1999
>Originator:     Peter Jeremy
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
Alcatel Australia Limited
>Environment:

	PII-266 with SMB EtherPower II 10/100 (SMC9432TX) on 10baseT
	network, running -current from cvs-cur 5133.  Compiled with
	system gcc -O.

>Description:

	After upgrading from a very late 3.0-current, the ethernet
	performance dropped from ~line speed to ~38KBps, with >>90%
	system time, when doing large transfers.  Transfers via lo0
	were unaffected.

	Building a profiling kernel revealed that all the time was
	spent in if_tx.c:epic_read_phy_register().  This code has
	been recently changed (1.21 99/03/09) to increase the timeout
	loops from 0x1000 to 0x100000.  Disassembling the code showed
	that the actual physical register test had been pulled out of
	the for loop.

>How-To-Repeat:

	[sr]cp /kernel remote_host:/dev/null
	whilst running vmstat (or similar).

>Fix:
	
Index: pci/if_txvar.h
===================================================================
RCS file: /home/CVSROOT/./src/sys/pci/if_txvar.h,v
retrieving revision 1.1
diff -u -r1.1 if_txvar.h
--- if_txvar.h	1998/11/01 07:44:33	1.1
+++ if_txvar.h	1999/03/11 01:08:01
@@ -370,17 +370,17 @@
 	inb( (sc)->iobase + (u_int32_t)(reg) )
 #else
 #define CSR_WRITE_1(sc,reg,val) 					\
-	((*(u_int8_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int8_t)(val))
+	((*(volatile u_int8_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int8_t)(val))
 #define CSR_WRITE_2(sc,reg,val) 					\
-	((*(u_int16_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int16_t)(val))
+	((*(volatile u_int16_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int16_t)(val))
 #define CSR_WRITE_4(sc,reg,val) 					\
-	((*(u_int32_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int32_t)(val))
+	((*(volatile u_int32_t*)((sc)->csr + (u_int32_t)(reg))) = (u_int32_t)(val))
 #define CSR_READ_1(sc,reg) 						\
-	(*(u_int8_t*)((sc)->csr + (u_int32_t)(reg)))
+	(*(volatile u_int8_t*)((sc)->csr + (u_int32_t)(reg)))
 #define CSR_READ_2(sc,reg) 						\
-	(*(u_int16_t*)((sc)->csr + (u_int32_t)(reg)))
+	(*(volatile u_int16_t*)((sc)->csr + (u_int32_t)(reg)))
 #define CSR_READ_4(sc,reg) 						\
-	(*(u_int32_t*)((sc)->csr + (u_int32_t)(reg)))
+	(*(volatile u_int32_t*)((sc)->csr + (u_int32_t)(reg)))
 #endif
 #else /* __OpenBSD__ */
 #define EPIC_FORMAT	"%s"

>Release-Note:
>Audit-Trail:

From: Doug Rabson <dfr@nlsystems.com>
To: peter.jeremy@alcatel.com.au
Cc: FreeBSD-gnats-submit@freebsd.org, jeremyp@gsmx07.alcatel.com.au,
	andreas@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 11 Mar 1999 09:31:39 +0000 (GMT)

 [I've added andreas to the Cc since he committed the last change to the
 driver]
 
 The fix looks correct to me but as DG noted when the last change was made
 to this driver, it should be using DELAY to avoid future problems with
 processor speeds.  There are a couple of other places I noticed for loops
 which should also use DELAY - epic_read_phy_register and
 epic_write_phy_register.
 
 If these are changed to call DELAY(1) in the loop, I think the original
 patch to increase the loop in epic_init_phy wouldn't be needed either.
 
 --
 Doug Rabson				Mail:  dfr@nlsystems.com
 Nonlinear Systems Ltd.			Phone: +44 181 442 9037
 
 
 

From: Andreas Klemm <andreas@klemm.gtn.com>
To: Doug Rabson <dfr@nlsystems.com>
Cc: peter.jeremy@alcatel.com.au, FreeBSD-gnats-submit@freebsd.org,
	jeremyp@gsmx07.alcatel.com.au, andreas@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 11 Mar 1999 10:52:12 +0100

 On Thu, Mar 11, 1999 at 09:31:39AM +0000, Doug Rabson wrote:
 > [I've added andreas to the Cc since he committed the last change to the
 > driver]
 > 
 > The fix looks correct to me but as DG noted when the last change was made
 > to this driver, it should be using DELAY to avoid future problems with
 > processor speeds.  There are a couple of other places I noticed for loops
 > which should also use DELAY - epic_read_phy_register and
 > epic_write_phy_register.
 > 
 > If these are changed to call DELAY(1) in the loop, I think the original
 > patch to increase the loop in epic_init_phy wouldn't be needed either.
 
 I have no idea. what delays are actually needed, lack of experience
 in driver programming. Would it be save to simply use (copy) the DELAY 
 values from another, let's say the fxp, driver. Perhaps Semen you or
 Semen has an idea ?!
 
 	Andreas ///
 
 -- 
 Andreas Klemm                                http://www.FreeBSD.ORG/~andreas
      What gives you 90% more speed, for example, in kernel compilation ?
           http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
              "NT = Not Today" (Maggie Biggs)      ``powered by FreeBSD SMP''
 

From: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU>
To: dfr@nlsystems.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, andreas@FreeBSD.ORG
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 11 Mar 1999 20:01:22 +1000

 Doug Rabson <dfr@nlsystems.com> wrote:
 >The fix looks correct to me but as DG noted when the last change was made
 >to this driver, it should be using DELAY to avoid future problems with
 >processor speeds.
 
 I think that's a separate issue.  The current code is incorrect because
 references to H/W registers aren't marked volatile - and are therefore
 likely to be optimised away.  Andreas' change made the problem show
 up because of the extra delay.  I'm surprised that the only symptom
 was poor performance.
 
 >If these are changed to call DELAY(1) in the loop, I think the original
 >patch to increase the loop in epic_init_phy wouldn't be needed either.
 
 I agree that delays should be done using DELAY().  The problem is that
 DELAY() isn't really ideal for the situation in
 epic_{read,write}_phy_register: The code is polling a `ready' bit and
 the limit just makes sure that things don't lock up.  (I'm sure
 there's similar code in lots of device drivers).  It would be nice if
 the kernel supported something equivalent to setitimer(2)/SIGALRM for
 this purpose.
 
 Based on a quick look at DELAY() (and without knowing the range of
 expected delay's), I suspect that changing the code to do DELAY(1) on
 each loop would worsen the performance - particularly on slow
 processors where the overheads in DELAY() are significant (>1us).
 (Once the bit becomes ready in the PHY, it will typically be (1usec +
 DELAY() overhead)/2 before the state change is seen - compared with
 ~10 clocks for the current code).
 
 Peter
 

From: Doug Rabson <dfr@nlsystems.com>
To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, andreas@FreeBSD.ORG
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 11 Mar 1999 10:23:10 +0000 (GMT)

 On Thu, 11 Mar 1999, Peter Jeremy wrote:
 
 > Doug Rabson <dfr@nlsystems.com> wrote:
 > >The fix looks correct to me but as DG noted when the last change was made
 > >to this driver, it should be using DELAY to avoid future problems with
 > >processor speeds.
 > 
 > I think that's a separate issue.  The current code is incorrect because
 > references to H/W registers aren't marked volatile - and are therefore
 > likely to be optimised away.  Andreas' change made the problem show
 > up because of the extra delay.  I'm surprised that the only symptom
 > was poor performance.
 
 The register accesses should certainly be through volatile pointers.  Any
 number of problems could happen without that, especially if we change
 compilers.
 
 > 
 > >If these are changed to call DELAY(1) in the loop, I think the original
 > >patch to increase the loop in epic_init_phy wouldn't be needed either.
 > 
 > I agree that delays should be done using DELAY().  The problem is that
 > DELAY() isn't really ideal for the situation in
 > epic_{read,write}_phy_register: The code is polling a `ready' bit and
 > the limit just makes sure that things don't lock up.  (I'm sure
 > there's similar code in lots of device drivers).  It would be nice if
 > the kernel supported something equivalent to setitimer(2)/SIGALRM for
 > this purpose.
 > 
 > Based on a quick look at DELAY() (and without knowing the range of
 > expected delay's), I suspect that changing the code to do DELAY(1) on
 > each loop would worsen the performance - particularly on slow
 > processors where the overheads in DELAY() are significant (>1us).
 > (Once the bit becomes ready in the PHY, it will typically be (1usec +
 > DELAY() overhead)/2 before the state change is seen - compared with
 > ~10 clocks for the current code).
 
 You might be right.  On the other hand, other code in the same driver uses
 DELAY(1) when reading registers, for instance near the beginning of
 epic_stop_activity:
 
     for(i=0;i<0x1000;i++) {
 	if( (CSR_READ_4(sc,INTSTAT) & INTSTAT_RXIDLE) == INTSTAT_RXIDLE )
 	    break;
 	DELAY(1);
     }
 
 Changing the phy accesses to do the same would regularise the code and I'm
 convinced that it would be safer as processors get faster.
 
 --
 Doug Rabson				Mail:  dfr@nlsystems.com
 Nonlinear Systems Ltd.			Phone: +44 181 442 9037
 
 
 

From: Andreas Klemm <andreas@klemm.gtn.com>
To: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU>
Cc: dfr@nlsystems.com, FreeBSD-gnats-submit@FreeBSD.ORG,
	andreas@FreeBSD.ORG
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 11 Mar 1999 11:22:03 +0100

 On Thu, Mar 11, 1999 at 08:01:22PM +1000, Peter Jeremy wrote:
 > Doug Rabson <dfr@nlsystems.com> wrote:
 > >The fix looks correct to me but as DG noted when the last change was made
 > >to this driver, it should be using DELAY to avoid future problems with
 > >processor speeds.
 > 
 > I think that's a separate issue.  The current code is incorrect because
 > references to H/W registers aren't marked volatile - and are therefore
 > likely to be optimised away.  Andreas' change made the problem show
 > up because of the extra delay.  I'm surprised that the only symptom
 > was poor performance.
 
 And a huge amount of sys time (top: 90% sys, 0-10% idle)
 when 30 telnet sessions using nc (netcat) were running concurrently.
 
 When typing something on the console, then the characters were a bit
 delayed ..
 
 	Andreas ///
 
 -- 
 Andreas Klemm                                http://www.FreeBSD.ORG/~andreas
      What gives you 90% more speed, for example, in kernel compilation ?
           http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
              "NT = Not Today" (Maggie Biggs)      ``powered by FreeBSD SMP''
 

From: semen <semen@iclub.nsu.ru>
To: freebsd-gnats-submit@freebsd.org, peter.jeremy@alcatel.com.au
Cc:  
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Tue, 16 Mar 1999 02:35:20 +0000

 I have done all spoken in this thread, and some more,
 could you please try new version (1.22) ?
 Andreas Klemm has reported some progress of new
 driver.
 
 Bye.
 
 
State-Changed-From-To: open->closed 
State-Changed-By: semenu 
State-Changed-When: Fri Mar 26 03:02:42 PST 1999 
State-Changed-Why:  
Looks like fixed. 

From: David Gilbert <dgilbert@velocet.ca>
To: freebsd-gnats-submit@freebsd.org, peter.jeremy@alcatel.com.au,
	semen@iclub.nsu.ru, dfr@nlsystems.com, andreas@klemm.gtn.com
Cc:  
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Fri, 26 Mar 1999 19:24:00 -0500 (EST)

 I have applied the patch given in kern/10535 and it does not fix the
 problem I describe in kern/10575.  The systems seem to take somewhat
 longer to slow down accepting packets, but here is a typical ping
 between two machines on the same ethernet:
 
 [2:36:331]root@hadrian:/var/config> ping cutlass
 PING cutlass.velocet.net (198.96.118.68): 56 data bytes
 64 bytes from 198.96.118.68: icmp_seq=0 ttl=255 time=139.866 ms
 64 bytes from 198.96.118.68: icmp_seq=1 ttl=255 time=275.616 ms
 64 bytes from 198.96.118.68: icmp_seq=2 ttl=255 time=151.380 ms
 64 bytes from 198.96.118.68: icmp_seq=3 ttl=255 time=167.754 ms
 64 bytes from 198.96.118.68: icmp_seq=4 ttl=255 time=405.595 ms
 64 bytes from 198.96.118.68: icmp_seq=5 ttl=255 time=436.736 ms
 64 bytes from 198.96.118.68: icmp_seq=6 ttl=255 time=166.235 ms
 64 bytes from 198.96.118.68: icmp_seq=7 ttl=255 time=92.162 ms
 64 bytes from 198.96.118.68: icmp_seq=8 ttl=255 time=369.009 ms
 64 bytes from 198.96.118.68: icmp_seq=9 ttl=255 time=223.727 ms
 ^C
 --- cutlass.velocet.net ping statistics ---
 10 packets transmitted, 10 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 92.162/242.808/436.736/116.027 ms
 [2:37:332]root@hadrian:/var/config> ifconfig tx1 down; ifconfig tx1 up
 [2:38:333]root@hadrian:/var/config> ping cutlass
 PING cutlass.velocet.net (198.96.118.68): 56 data bytes
 64 bytes from 198.96.118.68: icmp_seq=0 ttl=255 time=0.558 ms
 64 bytes from 198.96.118.68: icmp_seq=1 ttl=255 time=0.770 ms
 64 bytes from 198.96.118.68: icmp_seq=2 ttl=255 time=0.507 ms
 64 bytes from 198.96.118.68: icmp_seq=3 ttl=255 time=0.520 ms
 64 bytes from 198.96.118.68: icmp_seq=4 ttl=255 time=0.512 ms
 64 bytes from 198.96.118.68: icmp_seq=5 ttl=255 time=0.520 ms
 64 bytes from 198.96.118.68: icmp_seq=6 ttl=255 time=0.525 ms
 ^C
 --- cutlass.velocet.net ping statistics ---
 7 packets transmitted, 7 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 0.507/0.559/0.770/0.088 ms
 
 This gets progressively worse until the ping times approach 16 s.
 
 Dave.
 
 -- 
 ============================================================================
 |David Gilbert, Velocet Communications.       | Two things can only be     |
 |Mail:       dgilbert@velocet.net             |  equal if and only if they |
 |http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
 =========================================================GLO================
 

From: Ustimenko Semen <semen@iclub.nsu.ru>
To: David Gilbert <dgilbert@velocet.ca>
Cc: freebsd-gnats-submit@freebsd.org, peter.jeremy@alcatel.com.au,
	dfr@nlsystems.com, andreas@klemm.gtn.com
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Sat, 27 Mar 1999 17:09:02 +0600 (NS)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 --0-319981922-922532942=:1125
 Content-Type: TEXT/PLAIN; charset=US-ASCII
 
 Hi!
 
 Try to apply patch attached.
 
 Bye.
 
 --0-319981922-922532942=:1125
 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=asd
 Content-Transfer-Encoding: BASE64
 Content-ID: <Pine.BSF.4.05.9903271709020.1125@iclub.nsu.ru>
 Content-Description: 
 Content-Disposition: attachment; filename=asd
 
 KioqIC9uZXQvaWNsdWIvaG9tZS9mdHAvcHViL0ZyZWVCU0QvRnJlZUJTRC1j
 dXJyZW50L3NyYy9zeXMvcGNpL2lmX3R4LmMJU3VuIE1hciAxNCAyMzowMjo0
 OCAxOTk5DQotLS0gL3N5cy9wY2kvaWZfdHguYwlTYXQgTWFyIDI3IDE3OjAx
 OjE2IDE5OTkNCioqKioqKioqKioqKioqKg0KKioqIDgzOCw4NDMgKioqKg0K
 LS0tIDgzOCw4NDcgLS0tLQ0KICAJCWRlc2MtPnR4bGVuZ3RoID0gDQogIAkJ
 ICAgIG1heChtMC0+bV9wa3RoZHIubGVuLEVUSEVSX01JTl9MRU4tRVRIRVJf
 Q1JDX0xFTik7DQogIAkJZGVzYy0+c3RhdHVzID0gMHg4MDAwOw0KKyANCisg
 CQkvKiBXb3JrYXJvdW5kIGZvciBBcHBsaWNhdGlvbiBOb3RlIDctMTUgKi8N
 CisgCQlmb3IgKGk9MDsgaTwxNjsgaSsrKSBDU1JfV1JJVEVfNChzYywgVEVT
 VDEsIFRFU1QxX0NMT0NLX1RFU1QpOw0KKyANCiAgCQlDU1JfV1JJVEVfNCgg
 c2MsIENPTU1BTkQsIENPTU1BTkRfVFhRVUVVRUQgKTsNCiAgDQogIAkJLyog
 U2V0IHdhdGNoZG9nIHRpbWVyICovDQoqKioqKioqKioqKioqKioNCioqKiAx
 MTExLDExMTcgKioqKg0KICAgICAgCQkgICAgZHByaW50ZigoRVBJQ19GT1JN
 QVQgIjogVFggdW5kZXJydW4gZXJyb3IsIHR4IHRocmVzaG9sZCBpbmNyZWFz
 ZWQgdG8gJWRcbiIsRVBJQ19BUkdTKHNjKSxzYy0+dHhfdGhyZXNob2xkKSk7
 DQogIAkJfQ0KICANCiEgCQlDU1JfV1JJVEVfNChzYywgQ09NTUFORCwgQ09N
 TUFORF9UWFVHTyB8IENPTU1BTkRfVFhRVUVVRUQpOw0KICAJCWVwaWNfc3Rv
 cF9hY3Rpdml0eShzYyk7DQogIAkJZXBpY19zZXRfdHhfbW9kZShzYyk7DQog
 IAkJZXBpY19zdGFydF9hY3Rpdml0eShzYyk7DQotLS0gMTExNSwxMTIxIC0t
 LS0NCiAgICAgIAkJICAgIGRwcmludGYoKEVQSUNfRk9STUFUICI6IFRYIHVu
 ZGVycnVuIGVycm9yLCB0eCB0aHJlc2hvbGQgaW5jcmVhc2VkIHRvICVkXG4i
 LEVQSUNfQVJHUyhzYyksc2MtPnR4X3RocmVzaG9sZCkpOw0KICAJCX0NCiAg
 DQohIAkJQ1NSX1dSSVRFXzQoc2MsIENPTU1BTkQsIENPTU1BTkRfVFhVR08p
 Ow0KICAJCWVwaWNfc3RvcF9hY3Rpdml0eShzYyk7DQogIAkJZXBpY19zZXRf
 dHhfbW9kZShzYyk7DQogIAkJZXBpY19zdGFydF9hY3Rpdml0eShzYyk7DQoq
 KioqKioqKioqKioqKioNCioqKiAxNjA2LDE2MTEgKioqKg0KLS0tIDE2MTAs
 MTYxOCAtLS0tDQogIGVwaWNfc3RhcnRfYWN0aXZpdHkgX19QKCgNCiAgICAg
 IGVwaWNfc29mdGNfdCAqIHNjKSkNCiAgew0KKyAgICAgLyogV29ya2Fyb3Vu
 ZCBmb3IgQXBwbGljYXRpb24gTm90ZSA3LTE1ICovDQorICAgICBmb3IgKGk9
 MDsgaTwxNjsgaSsrKSBDU1JfV1JJVEVfNChzYywgVEVTVDEsIFRFU1QxX0NM
 T0NLX1RFU1QpOw0KKyANCiAgICAgIC8qIFN0YXJ0IHJ4IHByb2Nlc3MgKi8N
 CiAgICAgIENTUl9XUklURV80KHNjLCBDT01NQU5ELA0KICAJQ09NTUFORF9S
 WFFVRVVFRCB8IENPTU1BTkRfU1RBUlRfUlggfA0KKioqKioqKioqKioqKioq
 DQoqKiogMTYyNiwxNjM0ICoqKioNCiAgICAgIC8qIFN0b3AgVHggYW5kIFJ4
 IERNQSAqLw0KICAgICAgQ1NSX1dSSVRFXzQoc2MsQ09NTUFORCxDT01NQU5E
 X1NUT1BfUlh8Q09NTUFORF9TVE9QX1JETUF8Q09NTUFORF9TVE9QX1RETUEp
 Ow0KICANCiEgICAgIC8qIFdhaXQgUnggYW5kIFR4IERNQSB0byBzdG9wICh3
 aHkgMSBtcyA/Pz8gWFhYKSAqLw0KICAgICAgZHByaW50ZigoRVBJQ19GT1JN
 QVQgIjogd2FpdGluZyBSeCBhbmQgVHggRE1BIHRvIHN0b3BcbiIsRVBJQ19B
 UkdTKHNjKSkpOw0KISAgICAgZm9yKGk9MDtpPDB4MTAwMDtpKyspIHsNCiAg
 CWlmKChDU1JfUkVBRF80KHNjLElOVFNUQVQpICYgKElOVFNUQVRfVFhJRExF
 IHwgSU5UU1RBVF9SWElETEUpKSA9PSANCiAgCSAgIChJTlRTVEFUX1RYSURM
 RSB8IElOVFNUQVRfUlhJRExFKSApDQogIAkgICAgYnJlYWs7DQotLS0gMTYz
 MywxNjQxIC0tLS0NCiAgICAgIC8qIFN0b3AgVHggYW5kIFJ4IERNQSAqLw0K
 ICAgICAgQ1NSX1dSSVRFXzQoc2MsQ09NTUFORCxDT01NQU5EX1NUT1BfUlh8
 Q09NTUFORF9TVE9QX1JETUF8Q09NTUFORF9TVE9QX1RETUEpOw0KICANCiEg
 ICAgIC8qIFdhaXQgUnggYW5kIFR4IERNQSB0byBzdG9wICh3aHkgNTAgbXMg
 Pz8/IFhYWCkgKi8NCiAgICAgIGRwcmludGYoKEVQSUNfRk9STUFUICI6IHdh
 aXRpbmcgUnggYW5kIFR4IERNQSB0byBzdG9wXG4iLEVQSUNfQVJHUyhzYykp
 KTsNCiEgICAgIGZvcihpPTA7aTwweDUwMDAwO2krKykgew0KICAJaWYoKENT
 Ul9SRUFEXzQoc2MsSU5UU1RBVCkgJiAoSU5UU1RBVF9UWElETEUgfCBJTlRT
 VEFUX1JYSURMRSkpID09IA0KICAJICAgKElOVFNUQVRfVFhJRExFIHwgSU5U
 U1RBVF9SWElETEUpICkNCiAgCSAgICBicmVhazsNCioqKioqKioqKioqKioq
 Kg0KKioqIDE2ODgsMTY5MyAqKioqDQotLS0gMTY5NSwxNzAzIC0tLS0NCiAg
 CWRlc2MtPmNvbnRyb2wgPSAweDAxOw0KICAJZGVzYy0+dHhsZW5ndGggPSBt
 YXgobTAtPm1fcGt0aGRyLmxlbixFVEhFUl9NSU5fTEVOLUVUSEVSX0NSQ19M
 RU4pOw0KICAJZGVzYy0+c3RhdHVzID0gMHg4MDAwOw0KKyANCisgCS8qIFdv
 cmthcm91bmQgZm9yIEFwcGxpY2F0aW9uIE5vdGUgNy0xNSAqLw0KKyAJZm9y
 IChpPTA7IGk8MTY7IGkrKykgQ1NSX1dSSVRFXzQoc2MsIFRFU1QxLCBURVNU
 MV9DTE9DS19URVNUKTsNCiAgDQogIAkvKiBMYXVuY2ggdHJhbnNtaXRpb24g
 Ki8NCiAgCUNTUl9XUklURV80KHNjLCBDT01NQU5ELCBDT01NQU5EX1NUT1Bf
 VERNQSB8IENPTU1BTkRfVFhRVUVVRUQpOw0K
 --0-319981922-922532942=:1125--
 

From: David Gilbert <dgilbert@velocet.ca>
To: Ustimenko Semen <semen@iclub.nsu.ru>
Cc: David Gilbert <dgilbert@velocet.ca>,
	freebsd-gnats-submit@freebsd.org, peter.jeremy@alcatel.com.au,
	dfr@nlsystems.com, andreas@klemm.gtn.com
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Sat, 27 Mar 1999 11:33:37 -0500 (EST)

 I didn't have time to look into it, but your patch doesn't seem to
 apply to my copy (3.1-RELEASE) of if_tx.c.  The previous patch in the
 PR was for if_txvar.h.
 
 [1:42:340]root@sabre:/sys/pci> patch -p <~dgilbert/patch 
 Hmm...  Looks like a new-style context diff to me...
 The text leading up to this was:
 --------------------------
 |*** /net/iclub/home/ftp/pub/FreeBSD/FreeBSD-current/src/sys/pci/if_tx.c       Sun Mar 14 23:02:48 1999
 |--- /sys/pci/if_tx.c   Sat Mar 27 17:01:16 1999
 --------------------------
 Patching file /sys/pci/if_tx.c using Plan A...
 Hunk #1 succeeded at 824 (offset -14 lines).
 Hunk #2 failed at 1101.
 Hunk #3 failed at 1596.
 Hunk #4 failed at 1619.
 Hunk #5 failed at 1681.
 4 out of 5 hunks failed--saving rejects to /sys/pci/if_tx.c.rej
 done
 

From: Ustimenko Semen <semen@iclub.nsu.ru>
To: David Gilbert <dgilbert@velocet.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Mon, 29 Mar 1999 14:03:09 +0700 (NSS)

 Hi!
 
 Changes for kern/10535 wasn't applyed to RELENG_3 yet,
 Try to use if_tx.c and if_txvar.h from CURRENT, diff was from
 CURRENT also.
 
 Bye.
 
 
 

From: David Gilbert <dgilbert@velocet.ca>
To: Ustimenko Semen <semen@iclub.nsu.ru>
Cc: David Gilbert <dgilbert@velocet.ca>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Tue, 30 Mar 1999 14:06:32 -0500 (EST)

 >>>>> "Ustimenko" == Ustimenko Semen <semen@iclub.nsu.ru> writes:
 
 Ustimenko> Hi!  Changes for kern/10535 wasn't applyed to RELENG_3 yet,
 Ustimenko> Try to use if_tx.c and if_txvar.h from CURRENT, diff was
 Ustimenko> from CURRENT also.
 
 OK... I fetched the newest versions of if_tx.c and if_txvar.h from the
 CVS tree and then I applied your patch.  This is what I get:
 
 cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit  -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes  -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused  -fformat-extensions -ansi  -nostdinc -I- -I. -I../.. -I../../../include  -DKERNEL -DVM_STACK -include opt_global.h -elf  ../../pci/if_tx.c
 ../../pci/if_tx.c:1338: warning: no previous prototype for `dump_phy_regs'
 ../../pci/if_tx.c: In function `epic_start_activity':
 ../../pci/if_tx.c:1614: `i' undeclared (first use this function)
 ../../pci/if_tx.c:1614: (Each undeclared identifier is reported only once
 ../../pci/if_tx.c:1614: for each function it appears in.)
 
 Dave.
 
 -- 
 ============================================================================
 |David Gilbert, Velocet Communications.       | Two things can only be     |
 |Mail:       dgilbert@velocet.net             |  equal if and only if they |
 |http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
 =========================================================GLO================
 

From: Ustimenko Semen <semen@iclub.nsu.ru>
To: David Gilbert <dgilbert@velocet.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Wed, 31 Mar 1999 17:21:29 +0700 (NSS)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 --0-1944453628-922875689=:60406
 Content-Type: TEXT/PLAIN; charset=US-ASCII
 
 Hi!
 
 Oops...I've forgotten to declare i...
 Here is patch, fixing compilation problems, attached.
 
 Bye.
 
 --0-1944453628-922875689=:60406
 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_tx.c.patch"
 Content-Transfer-Encoding: BASE64
 Content-ID: <Pine.BSF.4.05.9903311721290.60406@iclub.nsu.ru>
 Content-Description: if_tx.c.diff
 Content-Disposition: attachment; filename="if_tx.c.patch"
 
 KioqIGlmX3R4LmMub3JpZwlXZWQgTWFyIDMxIDE2OjA5OjQ1IDE5OTkNCi0t
 LSBpZl90eC5jCVdlZCBNYXIgMzEgMTY6MTE6MDkgMTk5OQ0KKioqKioqKioq
 KioqKioqDQoqKiogMTYxMCwxNjE1ICoqKioNCi0tLSAxNjEwLDE2MTcgLS0t
 LQ0KICBlcGljX3N0YXJ0X2FjdGl2aXR5IF9fUCgoDQogICAgICBlcGljX3Nv
 ZnRjX3QgKiBzYykpDQogIHsNCisgICAgIGludCBpOw0KKyANCiAgICAgIC8q
 IFdvcmthcm91bmQgZm9yIEFwcGxpY2F0aW9uIE5vdGUgNy0xNSAqLw0KICAg
 ICAgZm9yIChpPTA7IGk8MTY7IGkrKykgQ1NSX1dSSVRFXzQoc2MsIFRFU1Qx
 LCBURVNUMV9DTE9DS19URVNUKTsNCiAgDQo=
 --0-1944453628-922875689=:60406--
 

From: David Gilbert <dgilbert@velocet.ca>
To: Ustimenko Semen <semen@iclub.nsu.ru>
Cc: David Gilbert <dgilbert@velocet.ca>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Wed, 31 Mar 1999 15:26:33 -0500 (EST)

 >>>>> "Ustimenko" == Ustimenko Semen <semen@iclub.nsu.ru> writes:
 
 Ustimenko> Hi!  Oops...I've forgotten to declare i...  Here is patch,
 Ustimenko> fixing compilation problems, attached.
 
 I applied that patch and the symptoms still occur.  If it helps, the
 symptoms do not appear to occur on a 10Mb interface on the machine
 that has two of the cards.
 
 Dave.
 
 -- 
 ============================================================================
 |David Gilbert, Velocet Communications.       | Two things can only be     |
 |Mail:       dgilbert@velocet.net             |  equal if and only if they |
 |http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
 =========================================================GLO================
 

From: Ustimenko Semen <semen@iclub.nsu.ru>
To: David Gilbert <dgilbert@velocet.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Thu, 1 Apr 1999 11:32:28 +0700 (NSS)

 On Wed, 31 Mar 1999, David Gilbert wrote:
 > >>>>> "Ustimenko" == Ustimenko Semen <semen@iclub.nsu.ru> writes:
 > 
 > Ustimenko> Hi!  Oops...I've forgotten to declare i...  Here is patch,
 > Ustimenko> fixing compilation problems, attached.
 > 
 > I applied that patch and the symptoms still occur.  If it helps, the
 > symptoms do not appear to occur on a 10Mb interface on the machine
 > that has two of the cards.
 > 
 
 Hmm...
 Please try to compile driver with debug, by enabling EPIC_DEBUG
 define in if_tx.c. It will report some more errors on console.
 Then send messages to me.
 
 Good bye.
 
 

From: David Gilbert <dgilbert@velocet.ca>
To: Ustimenko Semen <semen@iclub.nsu.ru>
Cc: David Gilbert <dgilbert@velocet.ca>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10535: Very poor ethernet performance with tx driver
Date: Sun, 13 Jun 1999 00:57:30 -0400 (EDT)

 OK... I've cvsup'd, and commented out #define EARLY_RX 1 against
 3.2-STABLE.  This appears to make the problem dissappear, but I have
 found a new quirk.  I've been playing with skip, and all packets
 coming out of a host with a tx0 card look like the following to a
 tcpdump:
 
 00:49:19.010107 truncated-ip - 120 bytes missing!sabre.velocet.net > strike.velocet.ca: ip-proto-57 184
 
 ... and that means that the receiver is obviously not going to like
 them :).  Can you think of anything that would cause this --- or
 should I just go out and buy new ethernet cards :).
 
 Dave.
 
 -- 
 ============================================================================
 |David Gilbert, Velocet Communications.       | Two things can only be     |
 |Mail:       dgilbert@velocet.net             |  equal if and only if they |
 |http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
 =========================================================GLO================
 
>Unformatted:
