From owner-freebsd-current Fri Jul 12 16:24: 1 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 BFA7F37B400 for ; Fri, 12 Jul 2002 16:23:58 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D90143E58 for ; Fri, 12 Jul 2002 16:23:58 -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 TAA05103; Fri, 12 Jul 2002 19:23:57 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6CNNRc43269; Fri, 12 Jul 2002 19:23:27 -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: <15663.25839.352038.649456@grasshopper.cs.duke.edu> Date: Fri, 12 Jul 2002 19:23:27 -0400 (EDT) To: Ian Dowse Cc: current@freebsd.org Subject: Re: bdwrite: buffer is not busy In-Reply-To: <200207122218.aa20866@salmon.maths.tcd.ie> References: <20020712182534.GA336@nagual.pp.ru> <200207122218.aa20866@salmon.maths.tcd.ie> 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 Ian Dowse writes: > In message <20020712182534.GA336@nagual.pp.ru>, "Andrey A. Chernov" writes: > >I see this panic constantly during last month or two, UP machine, no > >softupdates. Anybody else saw it too? Any ideas? > > The "buffer is not busy" panic is usually a secondary panic that > occurs while trying to sync the disks after a different panic. If > possible, try to get the first panic message, or ideally a stack > trace. > Why do we dump after sync'ing fs's? It seems like we should dump first, then sync later. Also, with interrupt threads in -current, panic's are totally bizzare. Alphas can't dump because they get into a situation where some system thread wakes up and can never go to sleep again (like bufdaemon). I think the whole set of panicstr hacks need to be re-thought.. I'd like to do something that (as Julian says) puts a big stick in the works just after we panic which allows only interrupt threads and the panic'ing thread to run. What's the best way to do this? Should I add to the panicstr hacks, or is there a more elegent way to achieve this? Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message