Date: Wed, 8 Jan 2014 09:39:09 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Ian Lepore <ian@FreeBSD.org> 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: <20140108173909.GF99167@funkthat.com> In-Reply-To: <1389197091.1158.370.camel@revolution.hippie.lan> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore wrote this message on Wed, Jan 08, 2014 at 09:04 -0700: > 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? Nope, I'm not, Berislav Purgar reported the same issue earlier: https://www.freebsd.org/cgi/mid.cgi?CAAUsrB7GT1gWpKPB_kY8hrs=2=Lsf=47EA3hAGpyyWN3KJ4u4Q@mail.gmail.com and found the same issue w/ EABI... > 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). Considering that mutex code worked before, it shouldn't be the code... I'm wondering if either there is an issue w/ smashing memory or a cache flush that is writing bogus data out, or that a cache flush failed to write data that was in the cache? > 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.) So, I've tested that HEAD (absolutely no tree changes) w/ WITHOUT_ARM_EABI boots fine... and just to make sure my test is correct, I've disabled it too to verify that the kernel just hangs (absolutely no output).. and reenabled it and verified it works (that my setting is changing something)... worky -> no worky -> worky... Now I just realized another interesting thing about setting WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your call to cpu_setup("") previously (w/ EABI) killing console output and not even seeing the mtx panic message... So, it is clearly changing something very early on in boot... Clean HEAD using WITHOUT_ARM_EABI=: RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #44 r260452: Wed Jan 8 09:35:24 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) [...] I haven't put together a root to boot into yet, so I don't know if it makes it to single user or not... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140108173909.GF99167>