From owner-freebsd-current Tue Mar 18 16:53:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18401 for current-outgoing; Tue, 18 Mar 1997 16:53:14 -0800 (PST) Received: from thelab.hub.org (hal-ns1-46.netcom.ca [207.181.94.110]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18373 for ; Tue, 18 Mar 1997 16:53:02 -0800 (PST) Received: from thelab.hub.org (LOCALHOST [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id UAA16388; Tue, 18 Mar 1997 20:52:17 -0400 (AST) Date: Tue, 18 Mar 1997 20:52:17 -0400 (AST) From: The Hermit Hacker To: Bruce Evans cc: imp@village.org, current@freebsd.org Subject: Re: 2.2 Kernel Unstable In-Reply-To: <199703190029.LAA28501@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 19 Mar 1997, Bruce Evans wrote: > Recursive panics became normal with the Lite2 merge. sync() in panic() > has never run in the quite the right context, and now that there is a > lot more locking in sync(), the panic sync() is likely to stumble over > a lock, especially if the first panic was for a lock. Panics aren't > much more common than before the merge. > Okay, but this doesn't quite explain why a kernel (2.2, not 3.0) from around Feb 7th causes a SegFault, while a kernel generated by the 2.2-RELEASE source tree causes a system reboot... I can live with the SegFault's, and know *why* those are happening, so I'm not suggesting that those are a result of a bug in the kernel...what I am wondering is what changed so that MemFaults(aka SegFaults) are causing a system reboot instead of just causing an error... That would be like a GPF in MicroSloth causing a reboot instead of a GPF, no?