Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jul 2002 11:10:05 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        Andrew Kolchoogin <andrew@snark.rinet.ru>, current@freebsd.org
Subject:   Re: VOP_GETATTR panic on Alpha
Message-ID:  <20020716181005.GW77219@elvis.mu.org>
In-Reply-To: <15668.23528.719956.574605@grasshopper.cs.duke.edu>
References:  <xzpele33kq0.fsf@flood.ping.uio.no> <20020716145107.GA69162@snark.rinet.ru> <15668.23528.719956.574605@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
* Andrew Gallatin <gallatin@cs.duke.edu> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020716181005.GW77219>