Date: Sun, 29 Oct 1995 17:45:38 +0200 From: Heikki Suonsivu <hsu@cs.hut.fi> To: michael butler <imb@scgt.oz.au> Cc: hsu@cs.hut.fi (Heikki Suonsivu), freebsd-current@freebsd.org Subject: Re: load related problem or my compilation ? Message-ID: <199510291545.RAA09345@shadows.cs.hut.fi> In-Reply-To: <199510291438.BAA09021@asstdc.scgt.oz.au> References: <199510291407.QAA09219@shadows.cs.hut.fi> <199510291438.BAA09021@asstdc.scgt.oz.au>
next in thread | previous in thread | raw e-mail | index | archive | help
michael butler writes: > Watching the mbuf clusters, I see no more than ~120k allocated in ~40-50 > clusters so there doesn't seem to be any shortage .. I did another compile > with NMBCLUSTERS=2048 but, as expected, nothing different happened. It still > dies without logging anything at all about the failure event. > > I have a feeling (more than actual observation as the machine's 4km from > here) that it may be dying when one of the modems drops the link whilst in > full flight .. ~16k of data in the PPP send queue with more rapidly arriving > .. but I haven't been able to catch it doing it whilst I'm actually there > and watching it. The panics I get are almost always in the same place, and it could be something like this, but also it could be just getting a freed mbuf mid-fligth. I have had similar panic problems with a slow (38.4k) leased line which certainly does not loose carrier, and it panics sometimes, usually when a load peak suddenly arrives after idling (start up a heavy X program or like). Increasing TTYHOG and RS_IBUF_SIZE considerably reduces the number of panics I kept having, with the additional bonus of increased serial performance and no more data loss on non-flow-controlled leased lines. The 38.4k link was unusable without patching them to 4 times as big. All my systems are dedicated routing/terminal server setups, nothing else is done with them but routing. A workaround seems to be to increase TTYHOG and RS_IBUF_SIZE (I have 4k and 1k). It helps a bit, but does not fix the problem. > Another possibility is that this one is a relatively slow machine with only > 16 meg of RAM, so it's also vaguely possible that it's finding a kernel > memory allocation problem that doesn't worry faster ones. We have 486DX100 and 486DX120 machines, and they hardly ever have more than 10% CPU loads, even when all 32 ports are full. > Mine is -current as of ~7am, Oct 15th .. a week or so after the VM stuff got > fixed .. has anyone changed anything else since then that might affect/fix > this ? I'm now running -current on one machine and will switch the other two to -current to see how it works. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510291545.RAA09345>