Subject: port-i386/5222: ddb.onpanic support incomplete on i386
To: None <email@example.com>
From: None <nathanw@MIT.EDU>
Date: 03/27/1998 20:31:10
>Synopsis: kernel traps on i386 can drop into ddb when ddb.onpanic is false
>Responsible: gnats-admin (GNATS administrator)
>Arrival-Date: Fri Mar 27 17:35:01 1998
>Originator: Nathan J. Williams
Massachvsetts Institvte of Technology
>Release: NetBSD-current of 1998/3/27
System: NetBSD road-runner.mit.edu 1.3E NetBSD 1.3E (ROAD-RUNNER) #98: Mon Mar 23 22:12:16 EST 1998 firstname.lastname@example.org:/u1/usr/src/sys/arch/i386/compile/ROAD-RUNNER i386
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.
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.
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.