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

[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 <[email protected]> wrote:

> Two things. First:
> 
> 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.
> 
> 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.)
> 
> 
> Second:
> 
> As a cross-check, I again set up the USB3 SSD media based on:
> 
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221123-b51ee7ac252c-253133.img
> 
> with a (in this case):
> 
> -rw-r--r--   1 root  wheel  27706924032 Nov 29 22:16:51 2022 larger-than-RAM.tar
> 
> added. I then used it to boot a 16 GiByte MACCHIATObin Double Shot
> that is EDK2 UEFI/ACPI based and tried:
> 
> # 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)
> 
> So: it worked fine.
> 
> Thus, it does appear that the 2 problems (as shown by
> messages):
> 
> 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 
> (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=60578037760, length=1048576)]error = 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=60579086336, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60580134912, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60581183488, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60582232064, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60583280640, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60584329216, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60585377792, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60586426368, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60587474944, length=1048576)]error = 6
> g_vfs_done():ufs/rootfs[READ(offset=76881494016, length=32768)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=1806729216, length=12288)]error = 6
> g_vfs_done():ufs/rootfs[WRITE(offset=60576989184, length=1048576)]error = 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 = 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=0x2<NO_6_BYTE>
> pid 627 (cron), jid 0, uid 0: exited on signal 4
> 
> 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.)
> 


===
Mark Millard
marklmi at yahoo.com