From owner-freebsd-current Sun Oct 29 07:45:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA28074 for current-outgoing; Sun, 29 Oct 1995 07:45:36 -0800 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA28066 for ; Sun, 29 Oct 1995 07:45:31 -0800 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA29304 (5.65c8/HUTCS-S 1.4 for ); Sun, 29 Oct 1995 17:45:26 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id RAA09345; Sun, 29 Oct 1995 17:45:38 +0200 Date: Sun, 29 Oct 1995 17:45:38 +0200 Message-Id: <199510291545.RAA09345@shadows.cs.hut.fi> From: Heikki Suonsivu To: michael butler Cc: hsu@cs.hut.fi (Heikki Suonsivu), freebsd-current@freebsd.org Subject: Re: load related problem or my compilation ? In-Reply-To: <199510291438.BAA09021@asstdc.scgt.oz.au> References: <199510291407.QAA09219@shadows.cs.hut.fi> <199510291438.BAA09021@asstdc.scgt.oz.au> Sender: owner-current@freebsd.org Precedence: bulk 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