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

On 10/06/2014 1:45 AM, Eduardo Horvath wrote:
> 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()...)

How do I find it?

As this is from the serial console, I'm assuming that if it never
gets printed on the console then it never gets printed anywhere.


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

Yes - are those messages from the user space code running or kernel space?

Darren