Date: Tue, 11 Jan 2000 23:33:39 -0500 (EST) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Kazutaka YOKOTA <yokota@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha db_interface.c src/sys/ddb db_input.c ddb.h src/sys/dev/syscons syscons.c src/sys/i386/i386 db_interface.c trap.c src/sys/i386/isa/pcvt pcvt_drv.c src/sys/isa sio.c src/sys/kern tty_cons.c src/sys/sys cons.h Message-ID: <Pine.BSF.4.10.10001112322250.12108-100000@green.dyndns.org> In-Reply-To: <200001111454.GAA82775@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Jan 2000, Kazutaka YOKOTA wrote:
> Add a new mechanism, cndbctl(), to tell the console driver that
> ddb is entered. Don't refer to `in_Debugger' to see if we
> are in the debugger. (The variable used to be static in Debugger()
> and wasn't updated if ddb is entered via traps and panic anyway.)
Yes, that was the idea. Here's how it worked (quoted from a commit log;
this was from before I was a committer); the commit log is from
src/sys/i386/i386/db_interface.c.
revision 1.43
date: 1998/12/28 23:02:56; author: msmith; state: Exp; lines: +3 -2
branches: 1.43.2;
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>
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10001112322250.12108-100000>