From owner-freebsd-current Sat Jul 6 7:20:27 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 D2B1037B400 for ; Sat, 6 Jul 2002 07:20:24 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB5B843E52 for ; Sat, 6 Jul 2002 07:20:20 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA15257; Sat, 6 Jul 2002 10:20:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g66EJnB33383; Sat, 6 Jul 2002 10:19:49 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15654.64645.513754.920800@grasshopper.cs.duke.edu> Date: Sat, 6 Jul 2002 10:19:49 -0400 (EDT) To: Bruce Evans Cc: freebsd-current@FreeBSD.ORG Subject: Re: more on dumping In-Reply-To: <20020706192954.I4315-100000@gamplex.bde.org> References: <15654.31389.772589.952477@grasshopper.cs.duke.edu> <20020706192954.I4315-100000@gamplex.bde.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Bruce Evans writes: > 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 That's the impression I've been getting too ;) > 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) I tried adding the panicstr hack to the new KSE code in msleep(), but it had no noticable affect. I may have done it wrong, as it was a blind stab w/o any understanding (just skip the KSE code if panicstr). > hack (including cloned (rotted) comments about doing something to give > interrupts a chance) but no KSE checks before it. > > Bruce Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message