>Number:         9367
>Category:       port-i386
>Synopsis:       i386 kernel crash dump tracebacks not so useful
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-i386-maintainer (NetBSD/i386 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb  7 12:20:59 2000
>Last-Modified:
>Originator:     Chris Demetriou
>Organization:
>Release:        1.4.x (1.4-branch, as of mid-september 1999)
>Environment:
NetBSD bacon 1.4.1 NetBSD 1.4.1 (GENERIC_CGD) #16: Thu Sep 16 18:52:54 PDT 1999     cgd@bacon:/a/src/src-1-4-branch/sys/arch/i386/compile/GENERIC_CGD i386

>Description:
NetBSD/i386 kernel crash dump tracebacks in gdb are just about
useless.  For instance, consider the following trace provided
by a crash that I just experienced:

(gdb) whe
#0  0xf023bcce in sys_sysarch ()
#1  0xf023545f in cpu_reboot ()
#2  0xf01876c8 in log ()
#3  0xf023bf5d in trap ()


(the sys_sysarch() thing is just wrong, of course.)  The actual
call chain goes way beyond the trap call, though.  the kernel
printfs -- the eip reported by the trap handler -- say that this
particular trap() was caused by gdt_compact().  The traceback
should have provided that -- and deeper -- frame information.

>How-To-Repeat:
Get an i386 kernel to crash and dump a core.  examine it in gdb.

Note lack of useful information.
>Fix:
Unknown.  This is a production system, use of DDB is not an option.
>Audit-Trail:
>Unformatted: