Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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?


Home | Main Index | Thread Index | Old Index