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>