From owner-freebsd-current Tue Mar 18 18:13:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25698 for current-outgoing; Tue, 18 Mar 1997 18:13:37 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA25679 for ; Tue, 18 Mar 1997 18:13:24 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA20865; Wed, 19 Mar 1997 12:42:38 +1030 (CST) From: Michael Smith Message-Id: <199703190212.MAA20865@genesis.atrad.adelaide.edu.au> Subject: Re: 2.2 Kernel Unstable In-Reply-To: from The Hermit Hacker at "Mar 18, 97 10:06:23 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Wed, 19 Mar 1997 12:42:37 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, imp@village.org, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The Hermit Hacker stands accused of saying: > > > > It all depends on where the fault occurs; if it's in memory used by a > > program, the program gets killed. If it's in memory used by the > > kernel, the kernel gets killed. > > > I hate to beat a dead horse here, but so far as I'm able to tell, > if I were to plug in the March 18th kernel I created and do a 'make cleandir' > on /usr/src, it will cause a panic/reboot. Same thing with the Feb 7th > kernel just causes a SegFault...annoying, but liveable. So the kernels have different memory usage patterns. You still have bad memory, and if your hardware is faulty, all bets are off. > It seems kind of suspicious to me that with the Feb 7th kernel, > it consistently *doesn't* reboot where the March 18th one does...I don't > know if there is anything in the bug reports I submitted for the > March 18th kernel that will help, but they are there, and I still have > the appropriate core files... If the faults are 100% reproducible, with identical stack backtraces each time, then it might be possible to either locate the memory address that's faulty or locate the bug (if it's a bug). -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[