Date: Wed, 26 May 1999 20:29:01 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Nicole Harrington <nicole@nmhtech.com> Cc: Sergey <serge69@nym.alias.net>, freebsd-stable@FreeBSD.ORG, Andrew <mynet@uq.net.au> Subject: Re: kernel panic in 3.2 WAS Re: [Q] How stable is FreeBSD 3.X ? Message-ID: <Pine.BSF.4.05.9905262027340.518-100000@herring.nlsystems.com> In-Reply-To: <XFMail.990526083158.nicole@nmhtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 May 1999, Nicole Harrington wrote: > > On 25-May-99 My Secret Spies Reported That Doug Rabson wrote: > > On Tue, 25 May 1999, Nicole Harrington wrote: > > >> > Andrew > >> > >> I too agree that 3.1 was Very stable and 3.2 for most things seems to be OK > >> so > >> far as I have used it for many things at the ISP I work for. However I have > >> come across a reproducable problem with 3.2. just as Sergey has spoken > >> about, > >> that does not seem to occur in 3.1. > >> > >> I am testing the new FreeBSD port of the Inktomi caching server. The size > >> of > >> the processes that are used can grow quite large and are multithreaded. > >> I have found that if I set MAXDSIZ and DFLDSIZ too small (like > >> 512*1024*1024) I > >> can make the server page fault and reboot by making it work hard. (IE make > >> the > >> process grow) > >> > >> SO far a setting of (2*1024*1024*1024) for both seems to be quite stable > >> under > >> .any load, but it seems unsettling that rather than kill a process that is > >> demanding too much memory, the kernel page faults. Especially since the > >> process > >> runs as a user process not as a system process. > >> > >> I am no expert on these things, but I welcome the assistance of anyone > >> willing > >> to help identify the root of this problem to make FreeBSD more stable. > >> Flames > >> and put downs about a lack of detail or knowlege like I have seen so far, > >> please > >> send to the linux list of choice to save us both some time please. I use > >> FreeBSD as it is a professional OS with mostly professional people willing > >> to > >> lend a hand. > > > > What message is printed when the kernel page faults. If there is an > > instructions pointer in the message, use 'nm -n kernel' to find which > > function it crashed in. If possible, compile a kernel with DDB, run it > > until it crashes and get a backtrace. Getting a full kernel dump from a > > kernel compiled for debugging (use config -g CONFIG for this) is > > invaluable as it allows a developer to gather as much information as > > possible. > > > > Once you have a backtrace and/or a kernel dump, you need to get someone > > interested in fixing it. Find out roughly what part of the system is > > involved and see if you can figure out who worked on it last. If you talk > > to that person and provide them with all the information you have > > gathered, then you have a chance of getting a fix (or maybe only a > > workaround). > > > > Ah, good point. I had built the kernel for DDB, but didn't get a readable > result as I forgot to compile my kernel with -g. > I woun't be back at work until Friday, but I will try that and send a copy to > the list and submit it as suggested. My Error message was basicly the same as > the one Sergey had sent to the list however. > > I am still very curious why the kernel would panic so easily rather than kill > the offending process..... It really depends on what is going on. If it gets an unexpected page fault in kernel mode, it really has to panic because something is badly wrong and attempting to continue would risk even more data loss than the panic itself. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905262027340.518-100000>