Kernel Panic on DREAMPLUG: Alignment Fault 1

[Ian Lepore]

On Sat, 2013-08-03 at 08:32 +0100, Andrew Turner wrote:
> On Thu, 01 Aug 2013 10:28:41 -0600
> Ian Lepore <ian at FreeBSD.org> wrote:
> 
> > On Thu, 2013-08-01 at 18:13 +0200, Mattia Rossi wrote:
> > > On 01/08/13 15:28, Ian Lepore wrote:
> > > > On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote:
> > > >> <snip>
> > > >>
> > > >> Anyhow, I'll try to compile with gcc, and see what happens.
> > > > The host system's compiler (gcc in your case) is used to build the
> > > > selected compiler from src/, then that new compiler is used to
> > > > build the rest of src/ into a runnable system.  You can define
> > > > WITHOUT_CLANG_IS_CC and WITHOUT_EABI to use gcc, and you should
> > > > probably add WITHOUT_CLANG to avoid building it since it won't be
> > > > used (and it takes forever to build).
> > > Kernel built with gcc:
> > > [snip... same fault as with clang]
> > 
> > Yep, I just had the same experience -- same fault, same place,
> > addresses differ by a few bytes which is to be expected with a
> > different compiler.
> > 
> > I've just confirmed that gcc and WITHOUT_ARM_EABI=yes works fine, so
> > the problem seems to be that we're somehow not maintaining stack
> > alignment correctly for EABI on architectures prior to armv6.  I have
> > a feeling somewhere in the code is something conditional on ARMV6
> > that really needs to include armv5te (which has the ldrd/strd
> > instructions).
> 
> Can you try the patch at [1]. It should fix the stack alignment in
> exceptions. I suspect gcc is working in this case because it doesn't
> generate any instructions that rely on the stack alignment, where clang
> does.
> 
> Andrew
> 
> [1] http://people.freebsd.org/~andrew/trapframe_align2.diff

It's actually not clang vs gcc, it's EABI vs OABI on armv5te.  EABI
fails the same with clang and gcc.

With your patch and gcc EABI I get:

...
da1: 40.000MB/s transfers
da1: 15193MB (31116288 512 byte sectors: 255H 63S/T 1936C)
da1: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>
Fatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
[lots more lines of that]
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
Fatal kernel mode prefetch abort at 0xFatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'
trapframe: Fatal kernel mode data abort: 'Alignment Fault 1'

And it just continued like that for quite a while, mostly data abort
with the occasional prefetch abort thrown in.  Eventually it locked
hard.

-- Ian