From owner-freebsd-current Wed Feb 28 21:28:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 97B1E37B718; Wed, 28 Feb 2001 21:28:34 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA12249; Thu, 1 Mar 2001 16:28:30 +1100 Date: Thu, 1 Mar 2001 16:28:26 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Gary Jennejohn , freebsd-current@FreeBSD.org, Leif Neland Subject: Re: make kernel failure: pecoff: machine/lock.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, John Baldwin wrote: > On 28-Feb-01 Bruce Evans wrote: > > Most of the pcb actually has the same persistence as the kernel stack > > (both mainly store the process's context while the process is in the > > kernel). But it is silly to put the pcb below the stack instead of > > above it. Perhaps the idea is to get a panic sooner when something > > is corrupted. > > That is the idea. Not all of the pcb is just used while in the kernel. The > pcb_ext that points to a TSS on the i386 for example. The problem I think > people are having with the ltr panic is that the stack gets deep enough to > overwrite that field of the pcb, and we die later on when we try to access an > invalid pointer there. Perhaps pcb_ext, pcb_ldt, and other things that are > persistent across kernel entry/exit should be stored in p_md instead of p_addr. I think that at least the pointers belong in p_md. I had some panics that looked a bit like the ltr one. These turned out to be caused by priority inversion (related to the native priority bugs) preventing an ithread from running. The ithread held a pointer to a process and the process exited before the pointer was used. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message