Skip site navigation (1)Skip section navigation (2)
Date:      Sat,  9 Mar 2002 23:32:53 +0000 (GMT)
From:      Dominic Marks <dominic_marks@btinternet.com>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/35720: Patch to vr(4) to fix network load problems
Message-ID:  <20020309233253.CEB4120C@host213-123-132-59.in-addr.btopenworld.com>

next in thread | raw e-mail | index | archive | help

>Number:         35720
>Category:       kern
>Synopsis:       Patch to vr(4) to fix network load problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 09 15:40:01 PST 2002
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020309233253.CEB4120C>