Date: Wed, 08 Jan 2014 09:04:51 -0700 From: Ian Lepore <ian@FreeBSD.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <1389197091.1158.370.camel@revolution.hippie.lan> In-Reply-To: <20140108071643.GB99167@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2014-01-07 at 23:16 -0800, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Dec 20, 2013 at 22:10 -0800: > > Ian Lepore wrote this message on Thu, Nov 21, 2013 at 01:08 +0000: > > > Author: ian > > > Date: Thu Nov 21 01:08:10 2013 > > > New Revision: 258412 > > > URL: http://svnweb.freebsd.org/changeset/base/258412 > > > > > > Log: > > > Call cpu_setup() from the initarm() routine on platforms that don't use > > > the common FDT-aware initarm() in arm/machdep.c. > > > > > > Pointed out by: cognet > > > Pointy hat to: ian > > > > [...] > > > > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > > > ============================================================================== > > > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 00:54:26 2013 (r258411) > > > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 01:08:10 2013 (r258412) > > > @@ -405,6 +405,8 @@ initarm(struct arm_boot_params *abp) > > > * this problem will not occur after initarm(). > > > */ > > > cpu_idcache_wbinv_all(); > > > + cpu_setup(""); > > > + > > > /* ready to setup the console (XXX move earlier if possible) */ > > > cninit(); > > > /* > > > > > > > So, I finally got an AVILA board (thanks Jim@netgate) to do some testing > > on what stopped working... > > > > Turns out this commit break early output on the AVILA board... With > > this commit, I get no output when booting the kernel: > > RedBoot> load -b 0x200000 kernel.avila.avila > > Using default protocol (TFTP) > > Address offset = 0x40000000 > > Entry point: 0x00200100, address range: 0x00200000-0x006aedc8 > > RedBoot> go > > > > some previous pmap changes made the AVILA board panic... The pmap > > changes were made some time between July 1st and Aug 1st, and on kernels > > since then, I get: > > RedBoot> go > > panic: mtx_lock() of spin mutex pmap @ /usr/src.avila/sys/arm/arm/pmap.c:3677 > > Uptime: 1s > > So, finally tracked this panic down to the switch to EABI. If I > compiled kernel-toolchain from 253395 (before the EABI switch) and build > a kernel from HEAD, I get: > FreeBSD 11.0-CURRENT #41 r260441: Tue Jan 7 22:50:42 PST 2014 > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > gcc version 4.2.1 20070831 patched [FreeBSD] > CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > 32KB/32B 32-way instruction cache > 32KB/32B 32-way write-back-locking data cache > real memory = 67108864 (64 MB) > avail memory = 57008128 (54 MB) > > The question is why does turning on EABI cause the kernel_pmap mutex > to be a spin mutex instead of a mtx_lock mutex? > > Oh, I did track down the above panic and the trace is basicly: > pmap_extract > pmap_init_l1 > pmap_bootstrap > initarm > > pmap_extract's arg is pmap_kernel() which is kernel_pmap, and > kernel_pmap's lock is init'd earlier in pmap_bootstrap before calling > pmap_init_l1... > > So I have no clue why it isn't work... > > Is someone going to help who has a clue? or am I just going to get > silence again? > I wonder if you're the first person actually run-testing big-endian EABI since we switched to eabi by default? Looking at the code involved in validating the mutex type, nothing jumps out at me as suspicious for endian-related trouble... the code involved appears to always access the data as a 32-bit flags field with shifting and masking (no unions or bogus re-casting to char pointers or anything). Setting WITHOUT_ARM_EABI in make.conf would be a workaround, but probably only useful to allow a build of -current to see if the problem truly toggles with the abi, and isn't somehow related to some other changes that happened since the switch to default eabi. (Remember you've got to blow away the MAKEOBJDIR and build fresh from scratch when changing abi.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1389197091.1158.370.camel>