Date: Sat, 03 Aug 2013 08:04:41 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 Message-ID: <1375538681.45247.273.camel@revolution.hippie.lan> In-Reply-To: <20130803083248.342108c2@bender.Home> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> <51FA8946.8030301@gmail.com> <1375374521.45247.211.camel@revolution.hippie.lan> <20130803083248.342108c2@bender.Home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2013-08-03 at 08:32 +0100, Andrew Turner wrote: > On Thu, 01 Aug 2013 10:28:41 -0600 > Ian Lepore <ian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1375538681.45247.273.camel>