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
- Reply: Mark Millard : "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"
- In reply to: Mark Millard : "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"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 30 Nov 2022 04:05:58 UTC
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.) (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?) and: B) the message sequences like (both "C0T" and "B0T" RPi4B's): 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