From owner-cvs-all  Mon Dec 28 15:03:10 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA07888
          for cvs-all-outgoing; Mon, 28 Dec 1998 15:03:10 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07883;
          Mon, 28 Dec 1998 15:03:09 -0800 (PST)
          (envelope-from msmith@FreeBSD.org)
From: Michael Smith <msmith@FreeBSD.ORG>
Received: (from msmith@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id PAA16566;
	Mon, 28 Dec 1998 15:03:01 -0800 (PST)
Date: Mon, 28 Dec 1998 15:03:01 -0800 (PST)
Message-Id: <199812282303.PAA16566@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/i386/i386 db_interface.c trap.c src/sys/kern
         kern_shutdown.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

msmith      1998/12/28 15:03:01 PST

  Modified files:
    sys/i386/i386        db_interface.c trap.c 
    sys/kern             kern_shutdown.c 
  Log:
  Improved DDB_UNATTENDED behaviour.  From the submitter:
  
    There's something that's been bugging me for a while, so I decided to fix it.
  FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least
  in my opinion. The behavior change is such that:
  
  	1. Nothing changes when debugger_on_panic != 0.
  	2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the
  		machine will reboot. Also, if a trap occurs, the machine will
  		panic and reboot, unlike how it broke to DDB before. HOWEVER,
  		a trap inside DDB will not cause a panic, allowing full use
  		of DDB without having to worry about the machine being stuck
  		at a DDB prompt if something goes wrong during the day.
  		Patches for this behavior follow my signature, and it would
  		be a boon to anyone (like me) who uses DDB_UNATTENDED, but
  		actually wants the machine to panic on a trap (otherwise,
  		what's the use, if the machine causes a fatal trap rather than
  		a true panic, of debugger_on_panic?). The changes cause no
  		adverse behavior, but do involve two symbols becoming global
  
  Submitted by:	Brian Feldman <green@unixhelp.org>
  
  Revision  Changes    Path
  1.43      +3 -2      src/sys/i386/i386/db_interface.c
  1.132     +6 -2      src/sys/i386/i386/trap.c
  1.44      +3 -3      src/sys/kern/kern_shutdown.c

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message