Subject: Methods of debugging a locked-up/hung system that doesn't generate a kernel core dump?
To: None <gdt@ir.bbn.com, dheeraj@ece.gatech.edu>
From: None <davef1624@aol.com>
List: tech-kern
Date: 04/12/2005 20:59:57
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.

Thanks for your help,
Dave


-----Original Message-----
From: Greg Troxel <gdt@ir.bbn.com>
To: Dheeraj S <dheeraj@ece.gatech.edu>
Cc: davef1624@aol.com; tech-net@NetBSD.org
Sent: 12 Apr 2005 19:52:36 -0400
Subject: Re: How do I get protocol statistics on a 
per-networking-interface level ?

  Dheeraj S <dheeraj@ece.gatech.edu> writes:

> On Mon, Apr 11, 2005 at 02:17:51PM -0400, davef1624@aol.com wrote:
>
> > Can anyone tell me how to get per-protocol based statistics (e.g., 
for
> > udp or ip protocols),
> > but on a per-network-interface level?
> >
> > netstat has the -p <protocol> option, as well as the -I <interface>
> > option,
> > but it seems that when I use the -p option, the -I option is 
ignored,
> > and I get stats for all interfaces for the specified protocol.
> >
> > Am I not using netstat correctly, or are there other tools out 
there?

c.  The statistics you want are gathered globally, not per interface.

> netstat -I wi0 -p tcp
>
> works as intended for me.

For me, it prints out the same thing as

netstat -p tcp

This makes sense, given how the statistics are kept, but a) I can't
see how that matches your notion of intended and b) is a bug; using -I
with -p should give an error, since it doesn't print what might
reasonably be expected.

--
        Greg Troxel <gdt@ir.bbn.com>