From owner-freebsd-current Tue Jul 16 11:10:20 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 6200137B410 for ; Tue, 16 Jul 2002 11:10:06 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFF443E31 for ; Tue, 16 Jul 2002 11:10:06 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id DF804AE162; Tue, 16 Jul 2002 11:10:05 -0700 (PDT) Date: Tue, 16 Jul 2002 11:10:05 -0700 From: Alfred Perlstein To: Andrew Gallatin Cc: Andrew Kolchoogin , current@freebsd.org Subject: Re: VOP_GETATTR panic on Alpha Message-ID: <20020716181005.GW77219@elvis.mu.org> References: <20020716145107.GA69162@snark.rinet.ru> <15668.23528.719956.574605@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15668.23528.719956.574605@grasshopper.cs.duke.edu> User-Agent: Mutt/1.3.27i 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 Gallatin [020716 10:46] wrote: > > 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. um, psuedocode... for ithreads, td->td_flags |= TD_ITHREAD for panicing thread, td->td_flags |= TD_INPANIC if ((cold || panicstr) && (td->td_flags & (TD_ITHREAD|TD_INPANIC)) != 0) { ? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message