Date: Mon, 30 Oct 1995 01:38:38 +1100 (EST) From: michael butler <imb@scgt.oz.au> To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: freebsd-current@freebsd.org Subject: Re: load related problem or my compilation ? Message-ID: <199510291438.BAA09021@asstdc.scgt.oz.au> In-Reply-To: <199510291407.QAA09219@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 29, 95 04:07:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510291438.BAA09021>