Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jul 2002 14:26:22 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        current@freebsd.org, Andrew Kolchoogin <andrew@snark.rinet.ru>
Subject:   Re: VOP_GETATTR panic on Alpha
Message-ID:  <XFMail.20020716142622.jhb@FreeBSD.org>
In-Reply-To: <15668.23528.719956.574605@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On 16-Jul-2002 Andrew Gallatin 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.

It's probably preemption.  However, the problem may be that you can't
switch to the ithread if you just turn preemption on for panics because
the ithread may already be on the run queue, thus why your earlier patch
may not have worked.  Try to see if it works ok if you turn on preemption
fully by making the second arg to ithread_schedule() be !cold.  FWIW, I
only have problems with preemption on alphas if I use SMP.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.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?XFMail.20020716142622.jhb>