Re: Ultrasparc III+ kernel panic

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Mon, 2 Mar 2015, BERTRAND Joël wrote:

> Martin Husemann a écrit :
> > On Sun, Mar 01, 2015 at 12:28:44PM +0100, BERTRAND Joël wrote:
> > > 	I have set ddb.onpanic=1. When kernel panics, it enters in ddb, but
> > > console does not respond. I only obtain :
> > > 
> > > cpu data fault: pc=f000a4b4 rpc=102dfae50 addr=1ffeec000
> > > kernel trap 30: data access exception
> > > Stopped in pid 23349,1 (netstat) at f000a4b4: ld [%g4 + 0x0], %g4
> > > db{1}>
> > 
> > Please also set ddb.commandonenter to "show reg; bt" or similar; this
> > definitively is good news and will allow debugging.
> > 
> > 
> > Martin
> > 
> 
> 	I have added show reg; bt to ddb.commandonenter. This morning, I have
> obtained a core image, but I don't think it is usable. Please have a look :
> 
> legendre# gdb --symbols=/usr/obj/sys/arch/sparc64/compile/CUSTOM/netbsd.gdb
> --eval-command="file /usr/obj/sys/arch/sparc64/compile/CUSTOM/netbsd.gdb"
> --eval-command="target kvm netbsd.12.core" --eval-command "bt" --eval-command
> "list" --eval-command "info all-registers" 2>&1
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "sparc64--netbsd".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from
> /usr/obj/sys/arch/sparc64/compile/CUSTOM/netbsd.gdb...done.
> Load new symbol table from
> "/usr/obj/sys/arch/sparc64/compile/CUSTOM/netbsd.gdb"? (y or n) y
> Reading symbols from
> /usr/obj/sys/arch/sparc64/compile/CUSTOM/netbsd.gdb...done.
> dumpsys () at /usr/src/sys/arch/sparc64/sparc64/machdep.c:758
> 758             snapshot(&dumppcb);
> #0  dumpsys () at /usr/src/sys/arch/sparc64/sparc64/machdep.c:758
> #1  0x0000000001338510 in maybe_dump (howto=256)
>     at /usr/src/sys/arch/sparc64/sparc64/machdep.c:570
> #2  cpu_reboot (howto=howto@entry=256,
>     user_boot_string=user_boot_string@entry=0x0)
>     at /usr/src/sys/arch/sparc64/sparc64/machdep.c:600
> #3  0x00000000010ff208 in db_sync_cmd (addr=4361690775,
>     have_addr=<optimized out>, count=0, modif=0x15ac5f0a8 "")
>     at /usr/src/sys/ddb/db_command.c:1354
> #4  0x00000000010ffadc in db_command (
>     last_cmdp=last_cmdp@entry=0x1c16be8 <db_last_command>)
>     at /usr/src/sys/ddb/db_command.c:903
> #5  0x00000000010fff60 in db_command_loop ()
>     at /usr/src/sys/ddb/db_command.c:561
> #6  0x0000000001107428 in db_trap (type=type@entry=48, code=code@entry=0)
>     at /usr/src/sys/ddb/db_trap.c:90
> #7  0x0000000001103b04 in kdb_trap (type=type@entry=48,
>     tf=tf@entry=0x15ac5f520)
>     at /usr/src/sys/arch/sparc64/sparc64/db_interface.c:329
> #8  0x000000000151a534 in data_access_fault (tf=0x15ac5f520,
>     type=<optimized out>, pc=4026565752, addr=8588804096, sfva=8588804263,
>     sfsr=<optimized out>) at /usr/src/sys/arch/sparc64/sparc64/trap.c:1169
> #9  0x00000000010106cc in Ldatafault_internal ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

gdb does not know how to decypher sparc64 trap frames.  You need to dump 
the contents of tf.  That will contain the first trapframe.  There may be 
several of them.  The window at the time of the trap, or at least the out 
registers, are stored in the trapframe itself, because trying to save them 
to the stack may cause a trap that will destroy the trap state.  The 
contents of the register window on the stack may not be accurate.

sparc64 has some useful machine dependent commands to help debug this sort 
of situation.  "mach tf" will dump the trapframe.  "mach stack" uses a 
different algorithm to try to walk the stack, and "mach window" will allow 
you to dump an individual register window.

What I generally do with an interactive DDB is dump the first trapframe, 
then use the "mach stack" command to walk the stack to the next trapframe.

Eduardo