>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.