Date: Sun, 21 Jun 2020 09:02:25 -0700 From: Mark Millard <marklmi@yahoo.com> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Potential USB3 problems when using UEFi v1.16 to boot RPi4: notes as I explore Message-ID: <476DD0F0-2286-4B2C-8E44-4404AF17F5A8@yahoo.com> References: <476DD0F0-2286-4B2C-8E44-4404AF17F5A8.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This reports on intermediate results of some 4 GiBYte RPi4 use via UWFI based booting. Extracted from my reply to a different message: > The following may be a function of the conditions/configuration > I'm experimenting with. For example over_voltage=6 and > arm_freq=2000 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. > > 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. > > 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. > > 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. > > 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. > > Of note: > > 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. > > 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. 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. 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?) 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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476DD0F0-2286-4B2C-8E44-4404AF17F5A8>