FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 29 Mar 2020 00:29:00 -0700
While trying to update the head version
in use I ran into boot hangups on the
OrangePi+ 2e and did an approximate
bisect of artificact.freebsd.org kernels
to find approximately which kernel
version the issue started at.

I found that head -r359309 boots and
-r359311 fails (shown later below).
The original update attempt was from
-r359966 to -r359376 and -r359376
stopped there as well. (I kept world
there and varied the kernel version
for the approximate bisect activity.)

It seems that at least one of the
"MI-namespace" atomics added do not work
in all its usage-contexts on the cortexA7
(armv7) involved.

[I also ran into boot problems on the
RPi4 (arch64 CortexA72) for the original
upgrade in that context. But the RPi4 is
incomplete and is not a long-established
FreeBSD context. I've not tested it
specifically against -r359309 and
-r359311 . I'll otherwise ignore the
RPi4 here, at least for now.]

The OPi+2e hangups look like (a boot -v
example):

. . .
Release APs
CPU(1) applied BP hardening: not necessary
CPU(3) applied BP hardening: not necessary
CPU(2) applied BP hardening: not necessary
regulator: shutting down unused regulators
regulator: shutting down vcc3v0... Trying to mount root from ufs:/dev/gpt/BPIM3root []...
ok
Root mount waiting for:regulator: shutting down vcc3v3...  usbus0busy
 usbus2regulator: shutting down vcc5v0...  usbus4ok
 usbus6regulator: shutting down gmac-3v3...  CAMbusy

uhub1: 1 port with 1 removable, self powered
uhub3: 1 port with 1 removable, self powered
uhub4: 1 port with 1 removable, self powered
uhub6: 1 port with 1 removable, self powered
Root mount waiting for: usbus6 CAM
ugen6.2: <OWC Envoy Pro mini> at usbus6
umass0 on uhub6
umass0: <OWC Envoy Pro mini, class 0/0, rev 2.10/1.00, addr 2> on usbus6
umass0:0:0: Attached to scbus0
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
GEOM: new disk da0
pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
pass0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
pass0: Serial Number REPLACED
pass0: 40.000MB/s transfers
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REPLACED
da0: 40.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
da0: Delete methods: <NONE(*),ZERO>
mountroot: waiting for device /dev/gpt/BPIM3root...
random: unblocking device.
rtc0: providing initial system time
start_init: trying /sbin/init

(And that is as far as it gets. I can break
into the debugger on the console.)


Notes:

vfs.root.mountfrom= is used in
/boot/loader.conf to direct the root
file system to be from the USB SSD. The
original kernel and world were non-debug
builds. But the artifact kernels are
debug builds. They did not report
anything odd.

(The /dev/gpt/BPIM3* based naming is from 
repurposing media without bothering to
rename things.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Sun Mar 29 2020 - 05:29:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC