From owner-freebsd-arm@freebsd.org Sun Jun 21 20:04:24 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 292CA331165 for ; Sun, 21 Jun 2020 20:04:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49qk5f6qQXz4WQB for ; Sun, 21 Jun 2020 20:04:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nE2rfMYVM1k6EN1qPQeXzPIEdv4j8qNAPkUi1DOwNI.U9eq.YT8gE_pkap93.MZ 00OwxMnNTeCi1gnNAT1jxo5nIIRRNCWeaFHAuwAyxP4EIEBJXn7DmKzM2HlNyKTzWSjLw_zE43V0 fXf4fSQqiTgZ30YPuLhiJJoxtsubq9fgz_5NPIkRjRkSzYLWPWM1jnfZk9MdYke5EzfQf32jAjcb sdDzPS4BMmtUJpkIfljpO8d8_.c3RhQDH0KCZRGGVcGgaoenBZyjPmwzshsn.tUYf4QKZTJxQnJo .pvsVv432IJ55LN8HTgGCajhDdnif3drQpho_wDCRpkihZjQ3nxLPO8BMFglzc4CvBByig8MHW4S 01SRpzyLw28WIBOMLXDBFEgWiiVcWjUmBRRaMjHKjTOd5EtTBS_yStyVekUfdbD8tdZF.qe7_KQF WNCrK1HYHhBSr5wtFFbqgs2XzslfPjI0P0yem8nMVvdAyNpszSqqsWJ6uwnOxn_Yv7hbowJ40xKK PtxzP1huPYGIdFawqWmanSq1ssi7mA4EEuQZZqp3c5NT.zVI2BOnX6jQ4ejhmG2kA4O6ODveXxmn 0Qiz8944Pb.bKd.QIyf2wDh4U17507V.kVfmHWHCUWGVqxX6Ht8JBG9d2uYEUay8diJ0J93AABNR EVQMdxrjZGkg2LYDaPbLTKGwh53FDQoJzB8RjoWtC6kLJ5uzcpraW20m7wpqfhxLW8aVmw_98ynr Nr02vcRwD535oVSHCKtaVmDVfOEX3OLS38NfeyVYeALAzh4LXqYxDFEX3LZEGOwZ7pqhYoyRHHab 8h2E3B5PoSisRRBoqTjWRpqYOFKeDKGbUbmBe20k0APfHzgpNCa72blWzwPjBjYhD0o9LBxwtMZT UYSQAkaKWjbLxp6J8.akSJIxjh7.LNa0MgCM6aNBhJDKx4krJdHHZNRlG3CizyyHVcpHD1tBAyZ7 Bz5WCKNhWmdGZvY4Z8OKytThpAnolvN.blUYQfQRCVBWYbEnUJ9pjETJ9wdApsjbx8rW59spxUcY vdWTVFGGgfzpMXr5dnLVvLRnlG9SkOQD76JQfhJiqO7Pnv6u.U3XePNqc9m4hVr7L5SLQ3ZIDCBY qHni.kuJz4vjn.PYCT5.RNRWJYivHYFykmWXyDb5QE3EaWPJBxi1zp44B7J7jhCb3OXK47ZSL2O3 HjGbdKzKcrQXV4HlI4cvShPqc9DZlbiiA6mmamAzb88Zl8.JSIL.Z2QX_w.1niqPXp_08CxDVYei orS4My_RpqpMBYB474Su8be3A0_pm2v2sXmXYAAJ9C7BAsI0E_9geyvK3nR1N4J7ofP.E2SqKkyp vMRwjRRO1Mf5AePPv5f9K_Reeenmz0_Xbil0XU4_qgGtgGX7njWqFItBIGm9Q4kyjXu6GTuyqgcY 3IJR2E2XhcgdPYvPlF69o0qfxUXOl3SacMcg1IpXYct9IyRo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Jun 2020 20:04:20 +0000 Received: by smtp414.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f6fdd53b07be0f3ecb23d7502e07e3fe; Sun, 21 Jun 2020 20:04:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Potential USB [USB3 and USB2] problems when using UEFi v1.16 to boot RPi4: notes as I explore Date: Sun, 21 Jun 2020 13:04:17 -0700 References: <476DD0F0-2286-4B2C-8E44-4404AF17F5A8@yahoo.com> To: "freebsd-arm@freebsd.org" In-Reply-To: <476DD0F0-2286-4B2C-8E44-4404AF17F5A8@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49qk5f6qQXz4WQB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.13 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.019]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.01)[-1.015]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; NEURAL_HAM_SHORT(-0.59)[-0.594]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 20:04:24 -0000 On 2020-Jun-21, at 09:02, Mark Millard wrote: > This reports on intermediate results of some > 4 GiBYte RPi4 use via UWFI based booting. >=20 > Extracted from my reply to a different message: >=20 >> The following may be a function of the conditions/configuration >> I'm experimenting with. For example over_voltage=3D6 and >> arm_freq=3D2000 and it is the 1st time using two USB3 devices (SSD >> and Ethernet): no powered hub involved (yet). I've not investigated >> variations yet. I am using a 5.1V 3.5A power supply. While >> I'm not generally where I can see/use it, an HDMI connection is >> present but nothing is logged in there. >>=20 >> It appears that I get occasional USB SSD data corruption >> during writes: building ports a few later extracts of prior >> ports builds get ". . . from package: Lzma library error: >> Corrupted input data". Out of 419 ports built so far I've >> had 4 such failures (40 other ports skipped). The last port >> (llvm10) is still building and probably has 4 or more hours >> to go. >>=20 >> Possibly going along with that is that, when I try to >> copy a large tar file during the poudriere bulk, the copy >> ends up corrupted (diff/cmp find differences). I've not >> yet tried when the RPi4 was basically idle. Using cmp shows >> that long sequences of bytes are different. Sometimes the >> new copy has large blocks of binary zeros but not always. >> It looks like the blocks might be 4096 in size. (Some bytes >> at the beginning or ends of 4096 might happen to match >> so the size of the mismatch is can be somewhat less than >> 4096.) The alignment of the mismatched blocks also >> stays inside 4096 alignment boundaries, not crossing. >> (I've not seen back-to-back failed blocks yet.) The messed >> up blocks are rare. >>=20 >> The poudriere bulk is using 4 builders, each allowed >> 4 processes. So much of the time there was/is a significant >> load average involved (4+) and there was such when I was >> testing copies. >>=20 >> So far I've not seen variability in the read results of the >> files that were created. It appears to be a write-time >> variability. >>=20 >> Of note: >>=20 >> The USB SSD is the same media also used to boot and >> operate a Rock64. I've not observed any problems in >> that alternate usage context. But I should do more >> explicit checking now. >>=20 >> My testing NetBSD with the built-in Ethernet in use and >> only a USB3 SSD has not suggested problems for the >> over_voltage and arm_freq so far. But I need better >> checking than I did. NetBSD was using the same type of >> USB3 SSD on the same RPi4. >=20 >=20 > Of the 4 port builds that failed for ". . . from package: > Lzma library error Corrupted input data", only 2 files are > involved. 3 of the 4 failures are attempted extractions > of the same package (llvm80-8.0.1_3) and the same file > fails for each of the 3. >=20 > But, more interesting is that, prior to the failures, llvm80 > was extracted 3 other times successfully after it was built. > This may be nothing more than in-memory copies of content > still being available at the time. (No USB-read required of > what what ended up being written?) >=20 > mesa-libs-19.0.8 , mesa-dri-19.0.8 , and xorg-server-1.20.8_1,1 > had no failures. The later xf86-video-scfb-0.0.5_2 , > xf86-input-libinput-0.30.0 , and xf86-video-vesa-2.4.0_3 had > failures while preparing to build. The llvm10 build finished. As for the bad large-file copy under a head -r360311 based context. . . Having the RPi4 otherwise idle made no difference. Having only the USB3 SSD as a USB device (on USB3) made no difference. Nor did also not having HDMI connected. Changing the arm_freq in use made no difference. Using the default arm_freq (no assignment) and having no over_voltage assignment made no difference. Using an external powered hub instead of a direct plug-in for the USB3 SSD made no difference. All the above at the same time made no difference. Plugging in the USB SSD to a USB2 port instead of a USB3 port and booting that way made no difference. Booting the Rock64 with the media and doing the experiment had no problems. It looks like the v1.16 UEFI based context has a general problem that shows up in at least USB "disk" I/O. The file copied during the tests is: # ls -ldT /usr/obj/clang-cortexA53-installworld-poud.tar -rw-r--r-- 1 root wheel 4011026432 Apr 25 21:04:42 2020 = /usr/obj/clang-cortexA53-installworld-poud.tar Note: diffing this file with the original on another machine consistently shows no differences. The above copy was established via copying to the Rock64. It is only attempting to write new copies via the RPi4 that end up with the new copies not fully matching this file. Copies over the network (scp and nfs) made to the RPi4 from where the original file is also end up partially corrupted on the RPi4. In this context, the RPi4 is using an external USB3 Ethernet device as the source of the data. Copies made from the RPi4 to the other machine end up with no differences (i.e., a good copy results). It looks like the problem is for writes to the USB media, not reads of the media. For reference on the RPi4: USB3 boot context: ugen0.3: at usbus0 umass0 on uhub1 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:0:0: Attached to scbus0 . . . (Root mount waiting for: CAM notices) . . . da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number # da0: 400.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 USB2 boot context: ugen0.3: at usbus0 umass0 on uhub2 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:0:0: Attached to scbus0 . . . (Root mount waiting for: CAM notices) . . . da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number # da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)