Date: Fri, 20 Jan 2017 08:39:15 +0000 From: Tom Vijlbrief <tvijlbrief@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <CAOQrpVfK-Dw_rSo_YVY5MT1wbc6Ah-Pj%2BWv8UGjeiUQ1b3%2B-mg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 <markmi@dsl-only.net>: [Adding a clarification.] On 2016-Oct-2, at 8:20 AM, Mark Millard <markmi@dsl-only.net> wrote: > Thanks for the notes. > > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief <tvijlbrief[ at ]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 <markmi[ at ]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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOQrpVfK-Dw_rSo_YVY5MT1wbc6Ah-Pj%2BWv8UGjeiUQ1b3%2B-mg>