From owner-freebsd-arm@freebsd.org Tue Jan 24 19:21:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB4E7CBFC9D for ; Tue, 24 Jan 2017 19:21:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 5805F18F0 for ; Tue, 24 Jan 2017 19:21:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 49D5CD8561; Tue, 24 Jan 2017 19:09:26 +0000 (UTC) Date: Tue, 24 Jan 2017 19:13:57 +0000 From: Andrew Turner To: Tom Vijlbrief Cc: Mark Millard , freebsd-arm Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <20170124191357.0ec0abfd@zapp> In-Reply-To: References: X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 19:21:31 -0000 Can you try with r312703 and without the malloc.conf change? I think the issue was because errno was stored just before some internal jemalloc state in the bss and there was a bug where the setting of errno where it would overwrite 32 bits of this state. Andrew On Fri, 20 Jan 2017 08:39:15 +0000 Tom Vijlbrief wrote: > I'm using the image from > > http://www.raspbsd.org/pine64.html (thanks Brad) > > After applying the jemalloc work around at the bottom of: > > https://wiki.freebsd.org/arm64/rpi3 > > and the dynamic linker fix: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214971 > > I could build most ports but not world because it does not use the > /etc/malloc.conf setting. > > Using: > > MALLOC_CONF=tcache:false script bw.log make buildworld NO_CLEAN=YES > -j2 > > I can do a build world but what is more interesting is that without > the MALLOC_CONF setting I get a lot of: > > gic0: Spurious interrupt detected: last irq: 27 on CPU3 > > These errors disappear when disabling tcache. > > The jemalloc tcache allocates on the stack so this hints at a bad > interaction between the interrupt stack frames and the application > stack. > > Op 17:35 ZO 2 Okt 2016 schreef Mark Millard : > > [Adding a clarification.] > > On 2016-Oct-2, at 8:20 AM, Mark Millard wrote: > > > Thanks for the notes. > > > > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief > ]gmail.com> > wrote: > >> > >> No change (at least in my tree) since my last report on this list > somewhere in May or June. > >> > >> The kernel boots with 4 cpus and working usb. I use an usb > >> ethernet > device and usb disk with the root filesysteem. Compiling and running > ports works, but a build world fails randomly with a memory access > error eg after running 15 minutes. > > > > Sounds possibly similar to TARGET_ARCH=powerpc 's stack-handling > > SVR4 ABI > violation when world is built by clang 3.8.0 (bad clang code > generation). To get to the point of buildworld going through I had to > change the kernel to provide a so-called "red-zone" on the stack > during signal handling to protect the stack from being trashed. > buildworld gets extensive signals (SIGCHLD) and so without the > "red-zone" it would eventually get trashed addresses, far before > getting near completion. > > I see my wording was poor for indicating the staging: I was already > running a powerpc world built with clang 3.8.0's bad powerpc code > generation when I tried to buildworld and had the signal handling > problems (stack usage conflicts). The "red-zone" kernel hack allowed > such buildworld activity to reliably work despite the clang 3.8.0 > based bad code that was in use. > > > [Context: buildkernel via gcc 4.2.1 but buildworld via clang > > 3.8.0 .] > > > > [Side note: I've tried aarch64 releng/11.0 (first RELEASE's raw) > > under > qemu on Ubuntu 16.04.1 on the ODroid-C2 but it gots periodic illegal > instructions in very basic operation, no builds active.] > > > >> I don't think it makes sense to work on this until a freebsd rpi3 > >> arm64 > port is officially supported... > > > > [FYI: http://ameridroid.com/products/raspberry-pi-2-model-b-1gb-ram > > lists > the RPi2B as both "out of stock" and "discontinued" and has for some > time.] > > > >> Op zo 2 okt. 2016 15:04 schreef Mark Millard >> ]dsl-only.net>: . . . > >> Anything worth reporting on the ODroid-C2 details for FreeBSD: > >> what > works, what does not, what needs to be done to boot FreeBSD, and so > on? (I assume head [CURRENT-12 these days].) > >> > >> > >> Looking around. . . > >> > >> > >> https://github.com/tomtor/image-freebsd-c2 > >> > >> seems to have last been updated on May 7 (vs. > https://github.com/tomtor/image-freebsd-pine64 's April 17). > >> > >> > >> https://github.com/tomtor/freebsd/tree/tc2 > >> > >> seems to have last been updated on June 17. > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >