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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
