Date: Sat, 19 Dec 2020 00:13:06 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org> Subject: RPi4 (8 GiByte) example: non-debug head -r368500 kernel fails to mount root where artifact debug kernel works fine (uefi/ACPI boot) Message-ID: <4D39055C-A0B8-4E2C-AA2C-F703D5061771@yahoo.com> References: <4D39055C-A0B8-4E2C-AA2C-F703D5061771.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/aarch6= 4/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=3D0x2<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=3Dcortex-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 =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> - CAM - Instruction Set Attributes 0 =3D <CRC32> - Instruction Set Attributes 1 =3D <> - Processor Features 0 =3D <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 = 32> - Processor Features 1 =3D <> +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 =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> +Root mount waiting for: Instruction Set Attributes 0 =3D <CRC32> + usbus0 Instruction Set Attributes 1 =3D <> + usbus1 Processor Features 0 =3D <AdvSIMD,FP,EL3 32,EL2 32,EL1 = 32,EL0 32> + CAM Processor Features 1 =3D <> + Memory Model Features 0 =3D <TGran4,TGran64,SNSMem,BigEnd,16bit = ASID,16TB PA> Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <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 =3D 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=3D0x2<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. =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?4D39055C-A0B8-4E2C-AA2C-F703D5061771>