>Number:         5222
>Category:       port-i386
>Synopsis:       kernel traps on i386 can drop into ddb when ddb.onpanic is false
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 27 17:35:01 1998
>Last-Modified:
>Originator:     Nathan J. Williams
>Organization:
	Massachvsetts Institvte of Technology
>Release:        NetBSD-current of 1998/3/27
>Environment:
System: NetBSD road-runner.mit.edu 1.3E NetBSD 1.3E (ROAD-RUNNER) #98: Mon Mar 23 22:12:16 EST 1998 nathanw@road-runner.mit.edu:/u1/usr/src/sys/arch/i386/compile/ROAD-RUNNER i386


>Description:
	The ddb.onpanic sysctl variable (affecting the db_onpanic kernel 
variable) is conceptually intened to prevent dropping into DDB when something 
breaks. It mostly achieves this, but in the case of a trap that makes it's 
way to the we_re_toast label in arch/i386/i386/trap.c, kdb_trap() 
(in db_interface.c) is called if DDB is defined, and drops into the debugger 
regardless of the value of db_onpanic. This is sometimes good, as when 
control-alt-escape is pressed, but can be bad, as when some other kind of 
non-intentional fault happens that (without DDB defined) would cause a panic. 
	This makes debugging my system difficult; it's been "wedging" 
occasionally over the last couple of weeks, and as I'm usually in X
there's no way to get a dump without giving up DDB in my kernel entirely.
>How-To-Repeat:
>Fix:
	Not clear. Something in ddb (or perhaps kdb_trap()) should figure out 
if the trap was a deliberate debugging trap (breakpoint, watchpoint,
DDB-invoking keypress, etc) or an exceptional kernel condition, and not drop 
into the debugger in the latter case when db_onpanic is 0.

>Audit-Trail:
>Unformatted:
>How-to-Repeat:
	Trigger a trap caught in that code (in my case, try to vnconfig a 
file in AFS), and watch the debugger show up (if you are on a vt) or watch 
the machine apparantly hang (if you are in X). Such a trap should be pretty 
easy to generate with a properly constructed LKM.