From owner-freebsd-current Mon May 27 21:52:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA00435 for current-outgoing; Mon, 27 May 1996 21:52:55 -0700 (PDT) Received: from ki.net (root@ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA00430 for ; Mon, 27 May 1996 21:52:52 -0700 (PDT) Received: from localhost (scrappy@localhost) by ki.net (8.7.5/8.7.5) with SMTP id AAA16858 for ; Tue, 28 May 1996 00:52:53 -0400 (EDT) Date: Tue, 28 May 1996 00:52:52 -0400 (EDT) From: "Marc G. Fournier" To: current@freebsd.org Subject: possible bug in DDB? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Since the only real active development is done on current, I'm posting this here, even thought it only pertains to -stable right now (I dare not ask about -current yet *grin*)... A couple of weeks back, someone posted about instabilities on his machine, and by disabling DDB he seemed to have improved his stability. So, me in my wishful state of mind, decided to try that out and see if it helped...it did. Right now, my uptimes look like: ki# ruptime ki up 17+14:34, 4 users, load 1.12, 1.28, 1.33 thrawn up 10+02:46, 0 users, load 0.00, 0.00, 0.00 For my stable machines. Right now, ki is running the news server, nfs server, web server, YP server...and a Postgres95 server, so its my most heavily loaded machine. On top of that, starting today (after being up 17days, I'm running successive 'make cleandir; make obj; make depend all' on /usr/src (i don't want it to install anything, just make it all) with -pipe enabled. Currently, I'm on my second iteration of that. The only change to the machine, other then disabling DDB, was to add in another 16Meg of RAM, so now I'm only running 50meg into swap instead of 66Meg *sigh*. I'm not sure how memory allocation works in RAM...does it fill up one chip first and then go to the next, or does it Randomly write as well as access? I put the new chip into bank 3, so if it fills up one chip then the next, the two old chips are the ones being taxed currently. So...from this: a) I'm totally f*cked and DDB has no bearing on it, its still a hardware problem; b) this theory has some merit and there might be a bug in DDB; or c) this theory has some merit in so far that altho DDB is okay, its taxing some aspect of the hardware that isn't taxed without DDB enabled. Since I'm kinda used to it, I'm kinda partial to a) myself, but I figurd I've been quiet for a *real* long time now, and my uptime *is* nice and high for a change, *and* I do seem to be able to run successive make's on the source true...so figured I'd take a shot :) Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org