Due to an unfortunate update of an RPi-B (processes are terminated with signal 4 during boot) I noticed, that the newer images provided at https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES/13.0/ shows the same problem. The last image which is booting fine is FreeBSD-13.0-CURRENT-arm-armv6-RPI-B-20191004-r353072.img.xz. Booting the newer images looks always like this: uhub1: 3 ports with 2 removable, self powered Growing root partition to fill device pid 37 (awk), jid 0, uid 0: exited on signal 4 Illegal instruction pid 40 (awk), jid 0, uid 0: exited on signal 4 Illegal instruction Don't know how to grow root filesystem type: ugen0.3: <vendor 0x0424 product 0xec00> at usbus0 smsc0 on uhub1 smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: <MII bus> on smsc0 smscphy0: <SMC LAN8700 10/100 interface> PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: <USB Ethernet> on smsc0 ue0: xxxxxxx pid 46 (logger), jid 0, uid 0: exited on signal 4 Illegal instruction /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one pid 47 (sleep), jid 0, uid 0: exited on signal 4 Illegal instruction Setting hostuuid: a-b-c-d. Setting hostid: 0xabcd. No suitable dump device was found. ugen0.4: <Fujitsu Fujitsu Keyboard> at usbus0 ukbd0 on uhub1 ukbd0: <Fujitsu Fujitsu Keyboard, class 0/0, rev 1.10/1.09, addr 4> on usbus0 kbd1 at ukbd0 Starting file system checks: /dev/ufs/roopid 68 (fsck_ufs), jid 0, uid 0: exited on signal 4 tfs: FILE SYSTEM CLEAN; SKIPPING CHECKS fsck: /dev/ufs/rootfs: Illegal instruction Unknown error 1; help! ERROR: ABORTING BOOT (sending SIGTER With a disabled fsck in /etc/fstab, my unfortunate update shows a login-prompt. But a successful login is not possible due to signal 4. Ralf
We've been discussing this on irc, here's what we've found : This seems to be a regression from the LLVM9 import. Some of the generated code use the d17 VFP register which doesn't exists for vfpv2. Some patch in LLVM might fix this : https://reviews.llvm.org/D67375 Setting -mfpu=vfp2d16sp to cpuflags might also fix this diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk index 8a72368babb..25b2a2ae5f5 100644 --- a/share/mk/bsd.cpu.mk +++ b/share/mk/bsd.cpu.mk @@ -128,7 +128,7 @@ _CPUCFLAGS = -march=${CPUTYPE} # arm1176jzf-s, generic-armv7-a, cortex-a5, cortex-a7, cortex-a8, # cortex-a9, cortex-a12, cortex-a15, cortex-a17, cortex-a53, cortex-a57, # cortex-a72, exynos-m1 -_CPUCFLAGS = -mcpu=${CPUTYPE} +_CPUCFLAGS = -mcpu=${CPUTYPE} -mfpu=vfp2d16sp . endif . elif ${MACHINE_ARCH} == "powerpc" . if ${CPUTYPE} == "e500" mmel@ and I thinks that we should backport the LLVM commit into the tree and test what is the default vfp usage when we do not use -mfpu.
(In reply to Emmanuel Vadot from comment #1) > Setting -mfpu=vfp2d16sp to cpuflags might also fix this Unfortunately no, it does not fix it for me. Made buildworld and buildkernel from base r353962. Build started with empty object path/directory. The resulting system shows the same symptoms.
Confirmed that this is still an issue with this week's snapshots of 13.0-CURRENT. I had presumed the problem to be the builder needed to be updated (i.e., new system call added or some such thing), but I see the same boot-time failure as is in this report.
After updating cross-compilation system and the RPi-B to base r354130 (a little bit newer than base r354097, which contains the related llvm/clang fixes), I can announce that the issue is gone. Thank you.