Date: Wed, 30 Nov 2022 00:35:25 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: "mckusick@freebsd.org" <mckusick@FreeBSD.org> Subject: Re: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file test for UEFI/ACPI contexts: fails far worse than past B0T testing did Message-ID: <E3CC400C-FB7E-475D-9C45-04C22D727B54@yahoo.com> In-Reply-To: <DE0D6303-17D9-4D71-9617-E17D3B90EABB@yahoo.com> References: <A916C0E2-671C-4DFD-A5A5-592F4CC9E4E9@yahoo.com> <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com> <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com> <DE0D6303-17D9-4D71-9617-E17D3B90EABB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Summary: With the patching for handling the ACPI DMA
information also in the kernel, booting UEFI/ACPI style
13.1-STABLE works with the USB3 SSD just fine.]
On Nov 29, 2022, at 20:05, Mark Millard <marklmi@yahoo.com> wrote:
> Two things. First:
>=20
> It turns out that I misremembered: Only my normal main [so: 14]
> builds have the patching of sys/dev/acpica/acpi.c at this point.
> Thus I have not yet actually tested anything with the patching
> related to ACPI XHCI DMA handling.
>=20
> There is still a chance that the "cylinder checksum failed"
> messages would be eliminated by such patching. (This may make
> my request for information from mckusick@ related to "cylinder
> checksum failed" messages not so important.)
Now that my builds of 13.1-STABLE actually are based on
source that has the ACPI DMA information handling code
for XHCI added, sure enough the "cylinder checksum failed"
messages are gone when I test with my kernel build. So
those checks are useful cross checks on media I/O for UFS
being appropriate.
The diff of the original and copy of the large file found
no differences.
> (My other builds do have some patching of
> sys/arm/broadcom/bcm2835/bcm2838_pci.c and
> sys/arm/broadcom/bcm2835/bcm2838_xhci.c that my main also has.
> That is appearently what I was misremembering the details of.)
>=20
>=20
> Second:
>=20
> As a cross-check, I again set up the USB3 SSD media based on:
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221123-b51ee7ac252c-253133.img
>=20
> with a (in this case):
>=20
> -rw-r--r-- 1 root wheel 27706924032 Nov 29 22:16:51 2022 =
larger-than-RAM.tar
>=20
> added. I then used it to boot a 16 GiByte MACCHIATObin Double Shot
> that is EDK2 UEFI/ACPI based and tried:
>=20
> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
> # diff larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
> # fsck_ffs /
> ** /dev/ufs/rootfs (NO WRITE)
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 25613 files, 14286816 used, 42464044 free (996 frags, 5307881 blocks, =
0.0% fragmentation)
>=20
> So: it worked fine.
>=20
> Thus, it does appear that the 2 problems (as shown by
> messages):
>=20
> A) "cylinder checksum failed" messages ("B0T" RPi4B's only?)
Now known to be a ACPI DMA description handling problem
that would need to be fixed to support the "B0T" RPi4B's
XHCI.
> and:
> B) the message sequences like (both "C0T" and "B0T" RPi4B's):
For the "B0T" and "C0T" RPi4B's, no such message sequence
occurred with the ACPI DMA information handling patching
present.
> xhci_interrupt: host system error
> xhci0: Resetting controller
> uhub0: at usbus1, port 1, addr 1 (disconnected)
> ugen1.2: <vendor 0x2109 USB2.0 Hub> at usbus1 (disconnected)
> uhub2: at uhub0, port 1, addr 1 (disconnected)
> uhub2: detached
> ugen1.3: <OWC Envoy Pro mini> at usbus1 (disconnected)
> umass0: at uhub0, port 3, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 0e ee 40 00 08 00 00=20=
> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <OWC Envoy Pro mini 0> s/n 000000000014 detached
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60578037760, =
length=3D1048576)]error =3D 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60579086336, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60580134912, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60581183488, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60582232064, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60583280640, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60584329216, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60585377792, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60586426368, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60587474944, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[READ(offset=3D76881494016, length=3D32768)]error=
=3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806729216, length=3D12288)]error=
=3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60576989184, =
length=3D1048576)]error =3D 6
> larger-than-RAM.tar: Device not configured
> pid 658 (sh), jid 0, uid 0: exited on signal 4
> (da0:umass-sim0:0:0:0): Periph destroyed
> pid 355 (devd), jid 0, uid 0: exited on signal 4
> umass0: detached
> pid 657 (login), jid 0, uid 0: exited on signal 4
> uhub0: detached
> uhub0 on usbus1
> uhub0: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on =
usbus1
> uhub0: 5 ports with 4 removable, self powered
> ugen1.2: <vendor 0x2109 USB2.0 Hub> at usbus1
> uhub2 on uhub0
> uhub2: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.3: <OWC Envoy Pro mini> at usbus1
> umass0 on uhub0
> umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 2> on =
usbus1
> umass0: SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> 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 ***REDACTED***
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2<NO_6_BYTE>
> pid 627 (cron), jid 0, uid 0: exited on signal 4
>=20
> are both tied to issues more specific to aspects that RPi4B's
> have involved but that various other EDK2 UEFI/ACPI's do not
> present to the FreeBSD kernel. (That wording may be
> incomplete for the possibilities but should be suggestive.)
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E3CC400C-FB7E-475D-9C45-04C22D727B54>