From owner-freebsd-current Tue Jul 16 10:46:56 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 2BED537B401 for ; Tue, 16 Jul 2002 10:46:52 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F0FD43E77 for ; Tue, 16 Jul 2002 10:46:47 -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 NAA20062; Tue, 16 Jul 2002 13:46:46 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6GHkGK51893; Tue, 16 Jul 2002 13:46:16 -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: <15668.23528.719956.574605@grasshopper.cs.duke.edu> Date: Tue, 16 Jul 2002 13:46:16 -0400 (EDT) To: Andrew Kolchoogin Cc: current@freebsd.org Subject: Re: VOP_GETATTR panic on Alpha In-Reply-To: <20020716145107.GA69162@snark.rinet.ru> References: <20020716145107.GA69162@snark.rinet.ru> 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 Andrew Kolchoogin writes: > Hi! > > On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote: > > > The following panic is 100% reproducable - it happens whenever I boot > > a recent kernel on Alpha, just before init(8) starts getty(8) on the > > console: > sorry, kernel from today's sources at 17:38 works just fine. > > Yet another question about kernel core dumps: what should I do to get one?-) > Why "panic" from debugger on i386 gives core dump and reboots the system > and "panic" from debugger on Alpha does not? > Because, as BDE says, that crashdumps work at all is mosty accidental. On alpha, a random kernel thread is waking up, and is unable to go back to sleep because of the panicstr hack msleep: mtx_lock_spin(&sched_lock); if (cold || panicstr) { /* * After a panic, or during autoconfiguration, * just give interrupts a chance, then just return; * don't run any other procs or panic below, * in case this is the idle process and already asleep. */ if (mtx != NULL && priority & PDROP) mtx_unlock(mtx); mtx_unlock_spin(&sched_lock); return (0); } We need to somehow let only interrupt threads and the panic'ed process run after a panic. I have no idea how to do this in a clean, low-impact way. Drew PS: I was trying to make crashdumps fail on x86 by increasing HZ. But I cannot. I have no idea why this only happens on alpha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message