Date: Sun, 7 May 2000 22:15:40 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: brian@Awfulhak.org (Brian Somers) Cc: brian@FreeBSD.org (Brian Somers), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: cvs commit: src/usr.sbin/ppp mbuf.c Message-ID: <200005080515.WAA23852@gndrsh.dnsmgr.net> In-Reply-To: <200005072221.XAA51544@hak.lan.Awfulhak.org> from Brian Somers at "May 7, 2000 11:21:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
... > > Killing off and restarting ppp clears it right up. We started out with 3.4 > > and are now at 4.0-stable and still seeing it. I am starting to suspect > > the equipment on the other end (Max TNT TOS 7.2.3). > > It would be interesting to know if the memory footprint was > growing... If this bug did actually cause problems, it would > eventually cause enough (probably fragmented) leakage to have a > noticeable effect. I am tracking memory usage now though I don't recall it being anything very large ever. > > However, as m_append() is only called from nat_cmd.c, you'd need to > be using NAT to be affected by this in the first place. Well, then it's not this bug ! No NAT on that link. > FWIW, I've now got a ppp-over-ppp setup with the top ppp being a > permanent (-ddial) link, and I don't see any slowdown - *BUT*, I > re-open the link twice a day when the transport-level ppp switches > ISP. It may be interesting to just ``open lcp'' next time you see > the slow-down. If that solves the problem temporarily, it indicates > that it's probably not anything local that's going wrong. Well do. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005080515.WAA23852>