Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?)

[Tom Vijlbrief]

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 at dsl-only.net>:

[Adding a clarification.]

On 2016-Oct-2, at 8:20 AM, Mark Millard <markmi at 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 at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"