From owner-freebsd-current Sun Oct 29 06:39:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25165 for current-outgoing; Sun, 29 Oct 1995 06:39:13 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25160 for ; Sun, 29 Oct 1995 06:39:06 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id BAA09021; Mon, 30 Oct 1995 01:38:40 +1100 From: michael butler Message-Id: <199510291438.BAA09021@asstdc.scgt.oz.au> Subject: Re: load related problem or my compilation ? To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Mon, 30 Oct 1995 01:38:38 +1100 (EST) Cc: freebsd-current@freebsd.org In-Reply-To: <199510291407.QAA09219@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 29, 95 04:07:52 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2114 Sender: owner-current@freebsd.org Precedence: bulk > Make sure external cache is write through. The machine is sufficiently old so as not to have this optional .. i.e. I assume it can only be write-through. > We are seeing similar effects on -STABLE, but also get panics (dumps > available as ftp://clinet.fi/pub/FreeBSD/crashdumps/*.[2-8]. Maybe ppp is > releasing a mbuf which has already been freed (the contents are 0xdeadc0de > and such)? The lockups vary, either it just locks up, or it panics but > does not get far enough after dumping to reset. Probably all this is > because of wild pointers generated by access to freed data? I recompiled with "-O -pipe -m486". Now, with only two 28k8 modems being fed as fast as a Cisco with stacker compression enabled will allow (~3000cps each), it will now mostly just spontaneously reboot. One modem alone won't do it .. two running flat out will inside half an hour :-( Both modem links are running with an MTU/MRU of 552, so there is some (hopefully small) amount of fragmentation going on. 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. 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. > I'm trying going back to -current, as I did not have this problem before > (but we didn't get this much PPP dialin load before). 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 ? michael