From owner-cvs-all  Wed Jun 12  6:30:56 2002
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 68E9737B408; Wed, 12 Jun 2002 06:30:52 -0700 (PDT)
Received: (from bde@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g5CDUqP37981;
	Wed, 12 Jun 2002 06:30:52 -0700 (PDT)
	(envelope-from bde)
Message-Id: <200206121330.g5CDUqP37981@freefall.freebsd.org>
From: Bruce Evans <bde@FreeBSD.org>
Date: Wed, 12 Jun 2002 06:30:52 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/i386/i386 trap.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

bde         2002/06/12 06:30:52 PDT

  Modified files:
    sys/i386/i386        trap.c 
  Log:
  If trap() is called when ddb is active, then go directly to trap_fatal();
  do not blunder around enabling interrupts and running trap handlers.
  trap_pfault() will normally pass control to ddb's fault handler which
  will normally do the right thing.
  
  This bug is very old. but in old versions of FreeBSD it is probably only
  serious for trap handling that involves sleeping.  In -current, attempting
  to examine unmapped memory while stopped at a breakpoint at mi_switch()
  was always fatal.
  
  Revision  Changes    Path
  1.225     +9 -2      src/sys/i386/i386/trap.c

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