Re: How to get a crash dump with recursive panic?

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

On Mon, 9 Jun 2014, Darren Reed wrote:

> In testing out ipfilter on sparc64, I see a bunch of "Alignment error"
> messages like these:
> 
> Alignment error: pid=24522.1 comm=ipfstat dsfsr=00000000:00800001
> dsfar=ffffffff:fea0c252 isfsr=00000000:00808000 pc=10e3b0
> Alignment error: pid=22537.1 comm=ipfstat dsfsr=00000000:00800001
> dsfar=ffffffff:fea02252 isfsr=00000000:00808000 pc=10e3b0
> Alignment error: pid=6845.1 comm=ipfstat dsfsr=00000000:00800001
> dsfar=ffffffff:fea02252 isfsr=00000000:00808000 pc=10e3b0
> 
> Followed by a panic like this:
> 
> trap type 0x34: cpu 0, pc=109faac npc=109fab0 pstate=0x820006<PRIV,IE>
> Skipping crash dump on recursive panic
> panic: mem address not aligned
> cpu0: Begin traceback...
> cpu0: End traceback...
> cpu1: shutting down
> cpu0: rebooting
> 
> All that I can do is:
> (gdb) x/i 0x109faac
>    0x109faac <ipf_fixskip+44>:  ldx  [ %g4 + 0x20 ], %g4
> 
> Further tips anyone?

What's the previous panic look like?  (I wonder if we have an SMP bug in 
vpanic()...)

Trap type 0x34 is an alignment trap.  The instruction in question is 
trying to load an 8-byte integer pointed to by %g4+0x20 into %g4.  You can 
enable DDB and dump the registers to find the contents of %g4.  That 
should not be 8-byte aligned.

Beyond that it's a question of debugging the ipfilter code.

That ipfstat is getting unaligned accesses implies some data structure is 
unaligned.  You can slap gdb on it to find out what, or you can break into 
DDB and set the TDB_STOPSIG bit in trapdebug to have the kernel break into 
DDB on each unaligned access and debug it from there. 

Eduardo