Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!in2.uu.net!news-in.tiac.net!news-central.tiac.net!dana From: jtk@kolvir.arlington.ma.us (John Kohl) Newsgroups: comp.unix.bsd.misc Subject: Re: Why does this program panic 4.4BSD? Date: 25 May 1996 22:55:43 -0400 Organization: NetBSD Kernel Hackers `R` Us Lines: 22 Sender: jtk@pattern.arlington.ma.us Message-ID: <vqyohnc16ts.fsf@pattern.arlington.ma.us> References: <4o2kn3$21u@panix2.panix.com> NNTP-Posting-Host: jtk.tiac.net In-reply-to: tls@panix.com's message of 23 May 1996 17:18:27 -0400 X-Newsreader: Gnus v5.1 On my NetBSD/i386 -current system, MEGS=4 was not enough to crash the system. MEGS=16 was enough, and it panic'ed with "ptdi %x". This is symptomatic of the kernel exhausting its kernel VA space and having no PTEs left to map the new memory. It also would only crash for the program when run as root. When run as a nonprivileged user, the mlock() call was returning EPERM. I don't know why you were able to get it to crash when you were an unprivileged user--perhaps this is a recent repair to the NetBSD sources? The question boils down a bit to "why can user space cause this?" I would expect that if the VM ever gets rewritten that it will be smart enough not to allow attempts to wire down more kernel VA than it can handle. -- John Kohl <jtk@kolvir.arlington.ma.us> Hacking on NetBSD/i386 when I can. See <URL:http://www.netbsd.org/>. Member of the League for Programming Freedom--see http://www.lpf.org/