Date: 07 Dec 2001 01:22:11 +0800 From: "Brandon S. Allbery " KF8NH <allbery@ece.cmu.edu> To: Kal Torak <kaltorak@quake.com.au> Cc: Doug Silver <dsilver@quantified.com>, Jonathan Hanna <jhanna@shaw.ca>, FreeBSD ISP <freebsd-isp@FreeBSD.ORG>, FreeBSD Stable <freebsd-stable@FreeBSD.ORG> Subject: Re: Whats with this -> sendto: No buffer space available Message-ID: <1007659334.3280.1.camel@pyanfar.ece.cmu.edu> In-Reply-To: <3C0F1E30.3040508@quake.com.au> References: <Pine.LNX.4.21.0112050852200.29127-100000@danzig.sd.quantified.net> <3C0F1E30.3040508@quake.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2001-12-05 at 23:28, Kal Torak wrote: > The problem the rest of us have is different... I am almost 100% sure > this is being caused by a problem upstream, the data cant get out so > the sendto buffer fills and seems to lock up the interface... I have a > feeling this may be specific to PPP connections, anyone finding this > locks there interface on a non PPP connection??? (pppoe is still ppp > could this even be specific to pppoe??) Add PPTP to the list; that's how I lose. And in my case the "problem" is that when I see it I'm using wavelan to either a machine with a 28.8 dialup, or a congested access point. Also, ppp on the former locks up in this fashion. However, in the case of the PPTP connection there are some differences: - it tends to drop loopback packets as an early indication that it's about to report ENOBUFS; - it recovers by itself after a few minutes. Note that "netstat -m" shows this machine nowhere near any mbuf limits, and increasing #mbufs or #mbclusters has no effect. -- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university ["better check the oblivious first" -ke6sls] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1007659334.3280.1.camel>