From dom@host213-123-132-59.in-addr.btopenworld.com  Sat Mar  9 15:31:34 2002
Return-Path: <dom@host213-123-132-59.in-addr.btopenworld.com>
Received: from host213-123-132-59.in-addr.btopenworld.com (host213-123-132-59.in-addr.btopenworld.com [213.123.132.59])
	by hub.freebsd.org (Postfix) with ESMTP id 0FA4937B41D
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  9 Mar 2002 15:31:30 -0800 (PST)
Received: by host213-123-132-59.in-addr.btopenworld.com (Postfix, from userid 1001)
	id CEB4120C; Sat,  9 Mar 2002 23:32:53 +0000 (GMT)
Message-Id: <20020309233253.CEB4120C@host213-123-132-59.in-addr.btopenworld.com>
Date: Sat,  9 Mar 2002 23:32:53 +0000 (GMT)
From: Dominic Marks <dominic_marks@btinternet.com>
Reply-To: Dominic Marks <dominic_marks@btinternet.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Patch to vr(4) to fix network load problems
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         35720
>Category:       kern
>Synopsis:       Patch to vr(4) to fix network load problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    silby
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 09 15:40:01 PST 2002
>Closed-Date:    Sun May 19 18:24:33 PDT 2002
>Last-Modified:  Sun May 19 18:24:33 PDT 2002
>Originator:     Dominic Marks
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
Student
>Environment:
System: FreeBSD gallium 4.5-STABLE FreeBSD 4.5-STABLE #3: Thu Feb 28
17:34:43 GMT 2002 dom@gallium:/usr/obj/usr/src/sys/GALLIUM i386

	
>Description:
	When in a period of consistent high transfer (FTP of a 130Mb file)
	at a constant speed of 960kB/s the vr(4) will run out of space on
	the TX free list. This situation can only be resolved by bring the
	interface down and up manually with ifconfig. The process of using
	ifconfig sets the ifp->if_flags flag IFF_OACTIVE to an off state,
	when its on the card will not transfer any data. It is turned on
	when the TX free list becomes empty.
	
	
>How-To-Repeat:
	Try doing consistent high-load transfer on a vr(4) card. I believe
	this problem may be only apparent in certain circumstances,
	specifically certain hardware configurations.

	
>Fix:
	This patch resolves the situation for me. I don't believe that its
	the best, or cleanest solution. But I have found it corrects the
	problem. I have provided the patch against -CURRENT, and tested it
	on -STABLE. Patches are identical with the exception of VR_[UN]LOCK
	calls. The expansion of the TX and RX queues is probably redundant
	but has not had any apparent negative effects.

	Thanks to Diane Bruce for her hints which led to me being able to
	provide this solution, albeit a rather ugly one.

? if_vr.patch
Index: if_vr.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_vr.c,v
retrieving revision 1.46
diff -u -r1.46 if_vr.c
--- if_vr.c	2001/12/14 05:56:35	1.46
+++ if_vr.c	2002/03/09 23:04:10
@@ -1307,14 +1307,23 @@
 static void vr_start(ifp)
 	struct ifnet		*ifp;
 {
+	register int	i;
 	struct vr_softc		*sc;
 	struct mbuf		*m_head = NULL;
-	struct vr_chain		*cur_tx = NULL, *start_tx;
-
+	struct vr_chain		*cur_tx = NULL, *start_tx, *tx_item;
+	
 	sc = ifp->if_softc;
 
 	VR_LOCK(sc);
 	if (ifp->if_flags & IFF_OACTIVE) {
+		for (i = 0; i < VR_TX_LIST_CNT; i++) {
+			tx_item = &sc->vr_cdata.vr_tx_chain[i];
+			if (tx_item->vr_mbuf != NULL) {
+				m_freem (tx_item->vr_mbuf);
+				tx_item->vr_mbuf = NULL;
+				ifp->if_flags &= ~IFF_OACTIVE;
+			}
+		}
 		VR_UNLOCK(sc);
 		return;
 	}
Index: if_vrreg.h
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_vrreg.h,v
retrieving revision 1.11
diff -u -r1.11 if_vrreg.h
--- if_vrreg.h	2001/05/14 19:13:02	1.11
+++ if_vrreg.h	2002/03/09 23:04:11
@@ -342,8 +342,8 @@
 
 
 #define VR_MAXFRAGS		16
-#define VR_RX_LIST_CNT		64
-#define VR_TX_LIST_CNT		128
+#define VR_RX_LIST_CNT		128
+#define VR_TX_LIST_CNT		256
 #define VR_MIN_FRAMELEN		60
 #define VR_FRAMELEN		1536
 #define VR_RXLEN		1520

	


>Release-Note:
>Audit-Trail:

From: The Anarcat <anarcat@anarcat.dyndns.org>
To: freebsd-gnats-submit@FreeBSD.org, dominic_marks@btinternet.com
Cc:  
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Wed, 24 Apr 2002 00:50:52 -0400

 I had to hack the source to apply the patch on -stable. I can confirm
 the fix works on stable, please commit!
 
 The .h file is not affected.=20
 
 --- if_vr.c.orig	Sun Dec 16 10:46:08 2001
 +++ if_vr.c	Wed Apr 24 00:24:17 2002
 @@ -1308,14 +1308,24 @@
  static void vr_start(ifp)
  	struct ifnet		*ifp;
  {
 +	register int    i;
  	struct vr_softc		*sc;
  	struct mbuf		*m_head =3D NULL;
 -	struct vr_chain		*cur_tx =3D NULL, *start_tx;
 +	struct vr_chain		*cur_tx =3D NULL, *start_tx, *tx_item;
 =20
  	sc =3D ifp->if_softc;
 =20
 -	if (ifp->if_flags & IFF_OACTIVE)
 +	if (ifp->if_flags & IFF_OACTIVE) {
 +		for (i =3D 0; i < VR_TX_LIST_CNT; i++) {
 +			tx_item =3D &sc->vr_cdata.vr_tx_chain[i];
 +			if (tx_item->vr_mbuf !=3D NULL) {
 +				m_freem (tx_item->vr_mbuf);
 +				tx_item->vr_mbuf =3D NULL;
 +				ifp->if_flags &=3D ~IFF_OACTIVE;
 +			}
 +		}
  		return;
 +	}
 =20
  	/*
  	 * Check for an available queue slot. If there are none,
 
 
 --=20
 N'aimer qu'un seul est barbarie, car c'est au d=E9triment de tous les
 autres. F=FBt-ce l'amour de Dieu.
                         - Nietzsche, "Par del=E0 le bien et le mal"

From: Dominic Marks <dominic_marks@btinternet.com>
To: The Anarcat <anarcat@anarcat.dyndns.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Wed, 24 Apr 2002 13:29:36 +0100

 On Wed, Apr 24, 2002 at 12:50:52AM -0400, The Anarcat wrote:
 > I had to hack the source to apply the patch on -stable. I can confirm
 > the fix works on stable, please commit!
 
 How much load have you tested this under?
 
 > The .h file is not affected. 
 > 
 > --- if_vr.c.orig	Sun Dec 16 10:46:08 2001
 > +++ if_vr.c	Wed Apr 24 00:24:17 2002
 > @@ -1308,14 +1308,24 @@
 >  static void vr_start(ifp)
 >  	struct ifnet		*ifp;
 >  {
 > +	register int    i;
 >  	struct vr_softc		*sc;
 >  	struct mbuf		*m_head = NULL;
 > -	struct vr_chain		*cur_tx = NULL, *start_tx;
 > +	struct vr_chain		*cur_tx = NULL, *start_tx, *tx_item;
 >  
 >  	sc = ifp->if_softc;
 >  
 > -	if (ifp->if_flags & IFF_OACTIVE)
 > +	if (ifp->if_flags & IFF_OACTIVE) {
 > +		for (i = 0; i < VR_TX_LIST_CNT; i++) {
 > +			tx_item = &sc->vr_cdata.vr_tx_chain[i];
 > +			if (tx_item->vr_mbuf != NULL) {
 > +				m_freem (tx_item->vr_mbuf);
 > +				tx_item->vr_mbuf = NULL;
 > +				ifp->if_flags &= ~IFF_OACTIVE;
 > +			}
 > +		}
 >  		return;
 > +	}
 >  
 >  	/*
 >  	 * Check for an available queue slot. If there are none,
 > 
 > 
 > -- 
 > N'aimer qu'un seul est barbarie, car c'est au dtriment de tous les
 > autres. Ft-ce l'amour de Dieu.
 >                         - Nietzsche, "Par del le bien et le mal"
 
 -- 
 Dominic

From: The Anarcat <anarcat@anarcat.dyndns.org>
To: Dominic Marks <dominic_marks@btinternet.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Wed, 24 Apr 2002 08:37:52 -0400

 On Wed Apr 24, 2002 at 01:29:36PM +0100, Dominic Marks wrote:
 > On Wed, Apr 24, 2002 at 12:50:52AM -0400, The Anarcat wrote:
 > > I had to hack the source to apply the patch on -stable. I can confirm
 > > the fix works on stable, please commit!
 >=20
 > How much load have you tested this under?
 
 Approximatly as the PR states.
 
 Usually, after transferring around 10MB at >1MB/s, the iface would
 hang, that is it was hanging after around 10 or 15 seconds of maxing
 the throughput.
 
 Now I am able to transfer a 90MB file without problems. I could run
 further tests by transfering missing bits on my mp3 collection, if you
 wish. That would put to load on for a longer period.
 
 A.
 --=20
 =46rom the age of uniformity, from the age of solitude, from the age of
 Big Brother, from the age of doublethink - greetings!

From: Dominic Marks <dominic_marks@btinternet.com>
To: The Anarcat <anarcat@anarcat.dyndns.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Wed, 24 Apr 2002 16:10:33 +0100

 On Wed, Apr 24, 2002 at 08:37:52AM -0400, The Anarcat wrote:
 > On Wed Apr 24, 2002 at 01:29:36PM +0100, Dominic Marks wrote:
 > > On Wed, Apr 24, 2002 at 12:50:52AM -0400, The Anarcat wrote:
 > > > I had to hack the source to apply the patch on -stable. I can confirm
 > > > the fix works on stable, please commit!
 > > 
 > > How much load have you tested this under?
 > 
 > Approximatly as the PR states.
 > 
 > Usually, after transferring around 10MB at >1MB/s, the iface would
 > hang, that is it was hanging after around 10 or 15 seconds of maxing
 > the throughput.
 > 
 > Now I am able to transfer a 90MB file without problems. I could run
 > further tests by transfering missing bits on my mp3 collection, if you
 > wish. That would put to load on for a longer period.
 
 I found my fix worked for a period. Much more than the original code.
 But would still bottle out after about 500MB of continuous throughput.
 I was wondering if you had the same problems.
 
 > A.
 > -- 
 > From the age of uniformity, from the age of solitude, from the age of
 > Big Brother, from the age of doublethink - greetings!
 
 Thanks
 
 -- 
 Dominic

From: Antoine Beaupre <anarcat@anarcat.ath.cx>
To: Dominic Marks <dominic_marks@btinternet.com>
Cc: The Anarcat <anarcat@anarcat.dyndns.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Wed, 24 Apr 2002 11:05:49 -0400

 Le Mercredi 24 avril 2002, =E0 11:10 , Dominic Marks a =E9crit :
 >
 > I found my fix worked for a period. Much more than the original code.
 > But would still bottle out after about 500MB of continuous throughput.
 > I was wondering if you had the same problems.
 >
 > Thanks
 >
 > --
 > Dominic
 
 Much better indeed. It makes a whole difference between having a useable=20=
 
 ftp server vs a stupid crashing box.
 
 I'll take a look at testing 500Mb of continuous throughpout.
 
 A.
 

From: The Anarcat <anarcat@anarcat.dyndns.org>
To: Dominic Marks <dominic_marks@btinternet.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/35720: Patch to vr(4) to fix network load problems
Date: Thu, 25 Apr 2002 19:04:55 -0400

 --MGYHOYXEY6WxJCY8
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed Apr 24, 2002 at 04:10:33PM +0100, Dominic Marks wrote:
 > On Wed, Apr 24, 2002 at 08:37:52AM -0400, The Anarcat wrote:
 > > On Wed Apr 24, 2002 at 01:29:36PM +0100, Dominic Marks wrote:
 > > > On Wed, Apr 24, 2002 at 12:50:52AM -0400, The Anarcat wrote:
 > > > > I had to hack the source to apply the patch on -stable. I can confi=
 rm
 > > > > the fix works on stable, please commit!
 > > >=20
 > > > How much load have you tested this under?
 > >=20
 > > Approximatly as the PR states.
 > >=20
 > > Usually, after transferring around 10MB at >1MB/s, the iface would
 > > hang, that is it was hanging after around 10 or 15 seconds of maxing
 > > the throughput.
 > >=20
 > > Now I am able to transfer a 90MB file without problems. I could run
 > > further tests by transfering missing bits on my mp3 collection, if you
 > > wish. That would put to load on for a longer period.
 >=20
 > I found my fix worked for a period. Much more than the original code.
 > But would still bottle out after about 500MB of continuous throughput.
 > I was wondering if you had the same problems.
 
 I just transfered a 2GB file to test this, and it works
 fine. Throughput has been almost steady at 1MB/s all the time, and no
 hang.
 
 100% |**************************************************|  2394 MB    00:00=
  ETA
 2510619136 bytes sent in 2752,87 seconds (890,62 KB/s)
 
 I'm very happy. :)
 
 Please someone commit this to the tree.
 
 A.
 --=20
 =46rom the age of uniformity, from the age of solitude, from the age of
 Big Brother, from the age of doublethink - greetings!
 
 --MGYHOYXEY6WxJCY8
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjzIi5YACgkQttcWHAnWiGdL8gCdGfGFBdkYx5VGY1JKHPrWPvGI
 ABgAnRCiVBGixTFkE+ZO5sybFjLkqfDa
 =Tu5y
 -----END PGP SIGNATURE-----
 
 --MGYHOYXEY6WxJCY8--
Responsible-Changed-From-To: freebsd-bugs->wpaul 
Responsible-Changed-By: dougb 
Responsible-Changed-When: Thu Apr 25 21:50:25 PDT 2002 
Responsible-Changed-Why:  

Bill already has some of the other vr pr's. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35720 
Responsible-Changed-From-To: wpaul->silby 
Responsible-Changed-By: silby 
Responsible-Changed-When: Fri May 17 10:46:47 PDT 2002 
Responsible-Changed-Why:  
I'm taking the vr-related PRs for now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35720 
State-Changed-From-To: open->closed 
State-Changed-By: silby 
State-Changed-When: Sun May 19 18:24:02 PDT 2002 
State-Changed-Why:  
With submitter's help, a much simplified version of this 
patch has been committed, effectively solving the problem. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35720 
>Unformatted:
