Subject: Re: Methods of debugging a locked-up/hung system that doesn't generate a kernel core dump?
To: None <bouyer@antioche.lip6.fr>
From: None <davef1624@aol.com>
List: tech-kern
Date: 04/13/2005 15:42:35
Yes, it's a i386.
Problem is I don't know how to generate an NMI.
Breaking into ddb using a keyboard sequence won't work if interrupts 
are held off - correct?

thanks,
Dave


-----Original Message-----
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: davef1624@aol.com
Cc: gdt@ir.bbn.com; dheeraj@ece.gatech.edu; tech-kern@NetBSD.org
Sent: Wed, 13 Apr 2005 12:20:54 +0200
Subject: Re: Methods of debugging a locked-up/hung system that doesn't 
generate a kernel core dump?

  On Tue, Apr 12, 2005 at 08:59:57PM -0400, davef1624@aol.com wrote:
> I have a NetBSD 1.6 based system that randomly locks-up/hangs
> (as though a thread had indefinitely disabled interrupts).
>
> Eventually, our H/W based watchdog resets the CPU, and the system
> reboots
> but without saving the kernel core (since the normal panic path 
wasn't
> executed).
>
> Are there any debugging techniques that can be used to capture the
> state of the
> system when such a lock-up occurs?
> One idea is to reconfigure the H/W watchdog to instead generate a NMI
> to the processor;
> the NMI handler could then capture system state prior to resetting 
the
> CPU.

I assume it's x86 ?
If ddb is compiled in the kernel, a NMI should drop the box to debugger.

--
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer@lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--