The hardware configuration of the Raspberry Pi 2 used in these tests
consists of a powered USB 3 hub, HDMI display, USB keyboard/mouse
and an IDE mechanical hard drive mounted in a USB 2 enclosure. The
RPI2 has its own power cable/adapter, the hub has a second power
supply which runs the hard disk. The monitor is mains powered.
Networking is by wired ethernet. A serial console is connected
via a low-voltage level shifter to a standard rs232 port on an
adjacent FreeBSD machine with a serial port.

The root filesystem resides on the MicroSD card. /usr, /var, /tmp
and swap are all physical partitions on the 32 GB hard drive.
df reports:
/dev/mmcsd0s2a   7031260  2357424  4111336    36%    /
devfs                  1        1        0   100%    /dev
/dev/mmcsd0s1      51128     7332    43796    14%    /boot/msdos
/dev/da0p4       1279260   100900  1076020     9%    /tmp
/dev/da0p3      29442460 12766376 14320688    47%    /usr
/dev/da0p1       4053308   153420  3575624     4%    /var

Swap is 3 GB, which is probably excessive.

Early on, an attempt was made to use USB flash drives (one for
swap, another for everything else) in place of the mechanical
hard disk. Both flash drives got too hot to touch comfortably,
performance seemed slow and the effort was abandoned. With well
chosen flash drives the effort might have succeeded and is worth
revisiting once FreeBSD reaches a state of usable stability. 
Going to all-solid-state storage  would eliminate the drive, hub and
power supply, at considerable savings in wiring mess and money.

Having some swap space available seems to be mandatory, though
the amount used is comically small, seldom over 30 MB. One wonders
why such a token amount is demanded. If it's omitted makeworld fails.

The directory "crashes" records notes taken during experiments with
FreeBSD-11-current on the machine described above. The usual pattern
is to update source, build overnight and run stress tests the next
day, dating the notes by the date observed. Thus, the revision tested
is usually a day older than the report date.

Initially tests were not very consistent, but eventually a routine
developed: Update source, build, install, reboot, run fsck -fy twice,
go to multiuser, stress test to crash, record console, top and terminal.
After recovering from the crash repeat the cycle. In early cases the
stress tests were repeated on the same revision, lately the pattern
has been test only once before updating.

There seem to be three broad classes of crashes, usually in the stress2
syscall tests. One is an outright crash, with non-zero values reported
by the debugger. Another scenario is a crash in which most or all values
reported by the debugger are zero. In some cases there is no explict
crash, rather terminal sessions become unresponsive one by one. Usually
the controlling terminal for stress2 stops updating, but the top terminal
continues to update with the stress2 processes in the flswai state. A root
login on the console echoes commands, but does not seem to act on them. 
Break to debugger on the console generally works, but occasionally does not.

In a small number (perhaps two or three) cases the system got confused to the
point that power cycling was required to regain control. 

It's worth pointing out that crashes during OS build/install cycles seem to
be a thing of the past. That's a considerable improvement.