From owner-freebsd-stable Fri May 2 09:19:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08710 for stable-outgoing; Fri, 2 May 1997 09:19:52 -0700 (PDT) Received: from dopey.pathlink.com (dopey.pathlink.com [204.30.237.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08705 for ; Fri, 2 May 1997 09:19:49 -0700 (PDT) Received: from dvl-1.pathlink.com (dvl-1.pathlink.com [204.30.237.241]) by dopey.pathlink.com (8.8.5/8.8.5) with SMTP id JAA13147; Fri, 2 May 1997 09:28:36 -0700 (PDT) Message-Id: <1.5.4.32.19970502091932.006d6bc4@dopey.pathlink.com> X-Sender: kachun@dopey.pathlink.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 May 1997 09:19:32 +0000 To: dg@root.com From: Kachun Lee Subject: Re: kmem_map full with 2.2beta to 2.2-releng-970422 Cc: freebsd-stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 02:05 PM 5/1/97 -0700, you wrote: >>clients, and our NFS servers have quite a lot of these: >> >> /kernel: nfsd send error 55 >> >>They does not seem cause any ill effect. I assume 55=ENOBUFS No buffer space >>available. But I thought with the unified VM/Buffer, there are no MAXBUFFER >>setting any more. Do you know what parameter I should adjust? > > ...that one indicates that network buffers were depleted. This usually >happens when the interface queue reaches it's limit of 50 queued packets, >although it can also happen if the global pool of network buffers is deleted. >The most common cause of this error is a stuck network device driver - some >NICs, for example will stop sending if the cable is unplugged. It can also >happen on PPP/SLIP lines if hardware flow control (CTS) stays de-asserted too >long. I kind of know it is probably related to the 'de' drivers and the 50+% collicion rate. I am almost there giving up waiting for the 'new' de driver to make it to stable. I should just throw away all the SMC cards, get some Intel ones and use your driver. Thank again for the info.