Alignment error comm=vi

[Darren Reed <darrenr%netbsd.org@localhost>]

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

I'm starting to wonder if it is IPFilter's fault or something else
not quite right with sparc64 because I just saw this on my console:

Alignment error: pid=631.1 comm=vi dsfsr=00000000:00800001
dsfar=ffffffff:fec5d1f9 isfsr=00000000:00808000 pc=10892c

and I haven't even enabled IPFilter since boot.

Or does this represent another real fault elsewhere?

Darren