Date: Sun, 29 Mar 2020 00:29:00 -0700 From: Mark Millard <marklmi@yahoo.com> To: Conrad Meyer <cem@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions) Message-ID: <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> References: <221A0E27-6A0F-4136-AB76-2D6664279363.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D0x2<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=3D 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=20 repurposing media without bothering to rename things.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?221A0E27-6A0F-4136-AB76-2D6664279363>