From owner-freebsd-stable  Mon Aug  5 10:48:51 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA06033
          for stable-outgoing; Mon, 5 Aug 1996 10:48:51 -0700 (PDT)
Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06028
          for <freebsd-stable@freebsd.org>; Mon, 5 Aug 1996 10:48:48 -0700 (PDT)
Received: by havenx.uniserve.com id <18264-22441>; Mon, 5 Aug 1996 10:52:21 -0800
Date: 	Mon, 5 Aug 1996 10:52:18 -0700 (PDT)
From: Tom Samplonius <tom@uniserve.com>
To: Randy Terbush <randy@zyzzyva.com>
cc: freebsd-stable@freebsd.org
Subject: Re: ep0 problems and the stable tree 
In-Reply-To: <199608051405.JAA16614@sierra.zyzzyva.com>
Message-ID: <Pine.BSF.3.91.960805104646.3871A-100000@haven.uniserve.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Mon, 5 Aug 1996, Randy Terbush wrote:

> I'm would like to add the following to my previous post and
> bring this on to the current list, since the -stable list appears
> to be deserted...
> 
> I can further pin this behavior down to TCP NFS connections.
> UDP does not seem to be aflicted, but it is easily recreated
> over a TCP NFS connection.
> 
> Is there any chance that the "grinding to a halt" reports on
> -current are network related?
> 
> > I've seen a lot of discussion about the ep driver getting broken late
> > in the 2.1.5 release. Should I still be seeing this from sources dated
> > 
> > sierra:/sys/i386/isa
> > #> ll if_ep*
> > -rw-r--r--  1 root  wheel  36464 Jul 15 23:10 if_ep.c
> > -rw-r--r--  1 root  wheel  36457 May 26 14:54 if_ep.c.orig
> > -rw-r--r--  1 root  wheel  13946 Mar 31 23:08 if_epreg.h
> > 
> > Aug  3 16:11:25 sierra /kernel: ep0: Status: 2002 (input buffer overflow)
> > Aug  3 16:13:49 sierra /kernel: ep0: Status: 2002 (input buffer overflow)
> > Aug  3 16:13:52 sierra /kernel: ep0: Status: 2002 (input buffer overflow)
> > 
> > 
> > The net result is that a new NFS client on the net is suddenly freezing
> > quite frequently. Killing and restarting the 'nfsd' processes on the
> > server fix the problem.

  What kind of 3COM card are you using?  Some 3COM cards have very 
limited buffer space (8k ?), and will get buffer overflow very easily if 
your computer can't keep service interupts fast enough.

  This would explain why TCP would be effect, becasue TCP would transfer 
a whole window of packets at once, which would flood your buffer space.

  BTW, I ignored your first message to -stable because your never said 
what kind of card you were using, because if you are using one of the 
good cards, I'd wasting your and my time.

Tom