From owner-freebsd-current Sat Jul 6 2:51:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5F5737B400 for ; Sat, 6 Jul 2002 02:51:52 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDE043E3B for ; Sat, 6 Jul 2002 02:51:51 -0700 (PDT) (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 TAA18876; Sat, 6 Jul 2002 19:51:42 +1000 Date: Sat, 6 Jul 2002 19:57:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Andrew Gallatin Cc: freebsd-current@FreeBSD.ORG Subject: Re: more on dumping In-Reply-To: <15654.31389.772589.952477@grasshopper.cs.duke.edu> Message-ID: <20020706192954.I4315-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 6 Jul 2002, Andrew Gallatin wrote: > OK, current is really confusing me. When we are panic'ing and syncing > disks, how are we supposed to come back to the current thread which > caused the dump after we do an mi_switch() to allow an interrupt > thread to run? > > The alpha seems to get stuck running various sorts of kernel > processes, but it never comes back to the one that caused the dump. > > How is this supposed to work? Accidentally at best. panic() cannot sleep and should not call mi_switch(), but sync() wants to do both. msleep() has a hack that prevents it from doing very much if (cold || panicstr). This works in most cases in FreeBSD-2, but has been rotting as the kernel became more complicated. Before KSEII, it was normal for synch() to hit a deadlock and panic recursively (with no sync() the second time). KSEII may have made things worse by putting a lot of code before the hack in msleep(). The cv_wait() family has the same (cold || panicstr) hack (including cloned (rotted) comments about doing something to give interrupts a chance) but no KSE checks before it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message