Date: Tue, 29 Nov 2022 20:05:58 -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: <DE0D6303-17D9-4D71-9617-E17D3B90EABB@yahoo.com> In-Reply-To: <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com> References: <A916C0E2-671C-4DFD-A5A5-592F4CC9E4E9@yahoo.com> <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com> <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=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
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.)
=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?DE0D6303-17D9-4D71-9617-E17D3B90EABB>