Hello list.

A recent installation of OpenBSD 6.8 on an RPI4B was killing processes,
whilst the previous installation worked fine. Eventually the only
difference between the two turned out to be the presence of a swap
partition, and the issue seems to be specific to AArch64.

Please see below the configurations I have tested to establish the
reason for failure. The workload is identical across all three, and all
three have 2GB RAM.

1. RPI4B, OpenBSD 6.8, 2GB swap:

$ swapctl                                                       
Device      512-blocks     Used    Avail Capacity  Priority
/dev/sd0b      4194304        0  4194304     0%    0

Everything works fine, the swap is never used.

2. AMD64 VM, OpenBSD 6.8, no swap:

$ swapctl
swapctl: no swap devices configured

Everything works fine.

3. RPI4B, OpenBSD 6.8, no swap. The system boots fine, but random
processes terminate unexpectedly. The simplest way to reproduce is to
set MAKEFLAGS='-j 4' and to try compiling libpcap:

$ make -s clean
$ make -s
Killed 
*** Error 137 in target 'fad-getad.o'
Killed 
*** Error 137 in target 'optimize.o'
*** Error 137 in /home/denis/gitrepos/libpcap (Makefile:89
'optimize.o': cc -fvisibility=hidden  -fpic -I.  -DBUILDING_PCAP
-Dpcap_EXPORTS -...)
*** Error 137 (Makefile:89 'fad-getad.o': cc -fvisibility=hidden  -fpic
-I.  -DBUILDING_PCAP -Dpcap_EXPORTS -DHAVE_CONFIG_H  -g -O2    -c ./...)

However, the issue was not specific to libpcap compilation or C
compilers in general. I had observed random process termination trying
to install software with pkg_add or just trying to log in with SSH.
There were no relevant messages in the syslog. Random processes were
just shot down.

People on the interwebs mention that in OpenBSD SIGKILL is a response to
the process trying to allocate more virtual memory than the OS can
provide. In the case of RPI the amount of RAM is clearly sufficient
(this workload runs fine on 1GB and less RAM elsewhere), but somehow
on AArch64 the sheer absence of the swap space seems to skew the memory
size comparison and to trigger the signal way before the OS runs out of
RAM.

For the time being I have worked around the problem by adding a swap
partition. If anybody is willing to look into the issue, let me know
what other information you need.

-- 
    Denis Ovsienko

Reply via email to