From owner-freebsd-smp Sat Jun 28 05:51:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA18909 for smp-outgoing; Sat, 28 Jun 1997 05:51:16 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA18904 for ; Sat, 28 Jun 1997 05:51:10 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id WAA28620; Sat, 28 Jun 1997 22:46:29 +1000 Date: Sat, 28 Jun 1997 22:46:29 +1000 From: Bruce Evans Message-Id: <199706281246.WAA28620@godzilla.zeta.org.au> To: smp@csn.net, smp@FreeBSD.ORG Subject: Re: NMI and debugging in general Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >the design of the card includes a db-15 connector on the bracket for remote >mounting the LEDs. I plan to build such a cable, along with a pair of >switches for RESET and NMI (finally I get to the point). this will hopefully >prove useful for breaking out of those "hung" conditions into the debugger >with useful information. with my machine kept in a machine closet this This will hopefully prove useful for fixing the uniprocessor handing of NMI :-). Accepting an NMI masks NMIs until the next IRET. Intel docs recommend using an interrupt gate for NMI's in order to disable nested maskable interrupts, since an IRET instruction from the maskable-interrupt handler would re-enable NMI. We are sloppy and use a trap gate for NMI's. trap() isn't designed to work when interrupts are masked (especially at the cpu level). I have no problems using interrupt gates for debugger interrupts, except for the obvious one that it stops everything including clocks while the debugger is active, but this is the point of using interrupt gates. If the system is about to panic, then stopping everything is OK, but reenabling interrupts later for sync() may cause reentrancy problems (this problem is not restricted to NMIs). In all other cases, stopping everything is unacceptable. There are also reentrancy problems, even for calling printf() (printf() is reentrant, but some console drivers aren't). Completely hung systems should rarely occur. sio interrupts rarely hang, so the breakpoint in siointr1() is usually reachable if the BREAK_TO_DEBUGGER option is configured. A similar result can be obtained by removing the keyboard IRQ bit from tty_imask. Then the breakpoint in scintr() is usually reachable. This is fairly safe (perhaps 100% safe) because ISA keyboard interrupts are edge triggered. The SMP lazy masking code makes it safer. In any case, it is safe if you don't touch the keyboard between corrupting tty_imask and attempting to get into the debugger when the system hangs. Bruce