From owner-freebsd-hackers  Fri Jan 24 06:47:57 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id GAA01388
          for hackers-outgoing; Fri, 24 Jan 1997 06:47:57 -0800 (PST)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA01381;
          Fri, 24 Jan 1997 06:47:45 -0800 (PST)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22])
          by alpo.whistle.com (8.8.4/8.8.4) with SMTP
	  id FAA06600; Fri, 24 Jan 1997 05:55:40 -0800 (PST)
Message-ID: <32E8BEFD.167EB0E7@whistle.com>
Date: Fri, 24 Jan 1997 05:54:05 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: bde@FreeBSD.org
CC: hackers@FreeBSD.org
Subject: Bruce! HHHEEELLLLPPPP!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Ok well the subject laine says most of it..

I have a device driver,
that does some fancy linking with other modules in the kernel
(i.e. a netgraph node)

I can run the test program once which links the nodes up and 
sends some messages around, and then shuts down.
the second time I do that the system hangs.

attempts to follow it in the kernel debugger
result in the system 'stoppping' on passing an splx().
I presume that it's racing off somewhere and falling over
or looping, buit whatever it's doing, it doesn't make it back to 
the debugger. I've traced the problem down to s few simple bits of
TOTALLY INNOCENT bits of code (i.e if they aer linked into
the  node graph the problem occurs but if they are replaced by
a dummy (echo) node. I an run the test forever..

Bruce.. I spent quite a few hours trying to understand
the interrupt masking system and failed..

can you tell me what I should do to make the interrupt from sio1
bust it's way in through ANYTHING so that I can put a breakpoint
on it and try get a stacktrace when the thing freezes by sending
a character in? 
This system has no keyboard unfortunatly.. just 2 sio devices
one of which is the console and has the debugger running on it..

Any other suggestions accepted..
(I don't have the info and tools to put a button on NMI 
much as I'd like to....)

This has had me stopped in my tracks for 3 days now..
I'm trying to make a test case that I can mail out
but it's kinda tricky as it's in a driver for a prototype board
that no-one else has (yet).

is this the sort of thing you could trap with the "Bruce debugger?"

julian
(sitting next to the terminal and anxiously awating your reply)