RPi4 (8 GiByte) example: non-debug head -r368500 kernel fails to mount root where artifact debug kernel works fine (uefi/ACPI boot)

The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.

Non-debug kernels built for cortex-A72 and for cortex-A53 both got the
behavior that leads mount root failure. (This tends to eliminate some types
of missing synchronization as a potential issue: in the past the cortex-a72
style of build caught a problem that cortex-a53 builds did not show. So my
original thought to cc hps may have been a waste.) Still, the below is
based on my usual cortex-a72 based kernel being used as the non-debug kernel
example.

The artifact debug kernel from:

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz

does not get the problem.

The prior RPi4 context was back at head -r365932 or so and back then
the combination worked. The FreeBSD upgrade is recent.

In the failing contexts (i.e., non-debug contexts), the following
never shows up:

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: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

and the message:

Root mount waiting for: usbus0

repeats indefinitely, unlike historically for my configuration.


Capturing and diffing boot -v output did not show much interesting
but here is the range with usbusN and the like (+: for artifact debug
kernel, -: for non-debug -mcpu=cortex-a72 kernel):

@@ -197,18 +198,18 @@
 vlan: initialized, using hash tables with chaining
 IPsec: Initialized Security Association Processing.
 tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768
-AcpiOsExecute: enqueue 1 pending tasks
 usbus0: 5.0Gbps Super Speed USB v3.0
 usbus1: 480Mbps High Speed USB v2.0
-Release APs...Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
-done
-Root mount waiting for: usbus0CPU  0: ARM Cortex-A72 r0p3 affinity:  0
- usbus1                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
- CAM
- Instruction Set Attributes 0 = <CRC32>
- Instruction Set Attributes 1 = <>
-         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
-         Processor Features 1 = <>
+AcpiOsExecute: enqueue 1 pending tasks
+Release APs...done
+CPU  0: ARM Cortex-A72 r0p3 affinity:  0
+Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
+                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
+Root mount waiting for: Instruction Set Attributes 0 = <CRC32>
+ usbus0 Instruction Set Attributes 1 = <>
+ usbus1         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
+ CAM         Processor Features 1 = <>
+
       Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA>
       Memory Model Features 1 = <8bit VMID>
       Memory Model Features 2 = <32bit CCIDX,48bit VA>
@@ -219,12 +220,13 @@
 CPU  1: ARM Cortex-A72 r0p3 affinity:  1
 CPU  2: ARM Cortex-A72 r0p3 affinity:  2
 CPU  3: ARM Cortex-A72 r0p3 affinity:  3
+WARNING: WITNESS option enabled, expect reduced performance.
 regulator: shutting down unused regulators
 ugen1.1: <DWCOTG OTG Root HUB> at usbus1
 ugen0.1: <Generic XHCI root HUB> at usbus0
 uhub0 on usbus1
-uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
 uhub1 on usbus0
+uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
 uhub1: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
 uhub0: 1 port with 1 removable, self powered
 uhub1: 5 ports with 4 removable, self powered
@@ -233,15 +235,28 @@
 uhub2: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> on usbus0
 Root mount waiting for: usbus0 CAM
 uhub2: 4 ports with 4 removable, self powered
-Root mount waiting for: usbus0 CAM
 ugen0.3: <Realtek USB 10/100/1000 LAN> at usbus0
 Root mount waiting for: usbus0 CAM
 Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
+ugen0.4: <OWC Envoy Pro mini> at usbus0
+umass0 on uhub1
+umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 3> on usbus0
+umass0:  SCSI over Bulk-Only; quirks = 0x0100
+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
+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: 400.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: 400.000MB/s transfers
+da0: 228936MB (468862128 512 byte sectors)
+da0: quirks=0x2<NO_6_BYTE>
+da0: Delete methods: <NONE(*),ZERO>

(I did not include more of the waiting-for messages for the
non-debug kernel ("-"). I see no reason to have later text
from the debug kernel case ("+").)

I do have a working u-boot 2020.10 based, microsd card first-stages
boot for the same USB3 SSD that mounts the same root file system
just fine. The kernel is a copy of the same non-debug kernel that
the the above used, but the used copy is on the microsd card for
this type of booting. (The u-boot is not ready to deal with
USB-based booting of 8 GiByte RPi4's.)

So it seems that having both ACPI-boot-style and non-debug kernel
use combined are somehow involved to get the problem.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"