From owner-freebsd-arm@freebsd.org Sun Jun 21 16:02:34 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 E7BB8354032 for ; Sun, 21 Jun 2020 16:02:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 49qckd6BGbz4BnL for ; Sun, 21 Jun 2020 16:02:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: FPwljc8VM1m67HclU.TtP3QFTLOGoPnl3He7i0RJQ4Pnq7EqmhhpHDlCbnpz04f k3sqfJV8KmDh4DTccOuWwHjSUcHXnugcVHQm2kDnmWpT1LZmUfhKMaCX1X2iGbHhQiC2WcFFosAy PlEryPkriXNJczIV3Gpz7El2cgZieRr69pmDJE8VYpdpNmYZdEyTHo0bNYLhwSsbWmS2RwoGVvZJ _2sos.j3e9O9LSCr313qmpGR4J_s6JmGJR0AI4lKku._fbGJqnMeN0pxfOzw2P9yN9ukTTsCODt5 sgLz2sFTVBrQqcYW0nepDHO.zOQQhi7NS7JrV9vKxny8JJvpJ0ZG13wwM5CWIMjQDA945xD8dX7c .gi6a7cQLVFACY51xcZLeqrKyn2LeH03uofHGfFVvhDl.rcwFnXi93HdvWebC9gcUZgpwxUyH9gG KP.EPNr7UJsarEZnyQ9Oaw3PKSRQeTOk2S4vykVPxS4uO38Zs5b6kmCeTt5nQa_04aNhYHC97Dg7 PuqMzF1qwQujIRSkrZ_Z0Y9iWGd4AXrPVogbsGby13akKa5yoGdl424dYpLc7FAlAyeGbdKdQvu9 _bkUDdgV3uzi1LKUDXLWBfJEXRMzmoUuxcg7Qj0rOL1Oja35k2OC5lwrBCx101cnyS4eGlZhihp0 e9hsKUUrQhvXnznmzeBDTJx2ruY1GonBpBW53Vf3lVKvW7KJtvzl9rn8JTdrXSbNdviqxi9CoNDS UTLmVRuKZh15DWN6FX.quDS9YdRu0L4.LdDImL25NPZxZ39FVd5FCojsisXoyQwMKVjoTA8EVr7v _eViqGxGeSMKreW45KlsaXC4M7JbdLaD0LpGnH4_ga2HrXZD0Viyjws6_eCgmKrBxthw4XDAd8xI 5QKb7I9FAVlHCYa9fRqpqvvj9_hHE7QfwvgAEWJQ_Xj7TpAqRmh_L6aiS8k35tOGd0oFxlZY3IV0 0u22F3KwyUHf3Ufeg4GORmbLrkGFYJDMMjwvnLSFIL6aUgj3UNdyf.2Yv0f8T0IHW8Jq1SVMoI2B 5M9lJWDOQlncNxtVFrMwR9SG3klBSDB8P2eqa4eaP1fGXmmBb5v9SHZ.KrySp9SZZzWFnX2.SNWw fxg2cKWn7vUGEbEZ50bjEbusmLzK5tmFJRx6b8VGFhrj2oQG2ttZ3CXomjODRZPrpcKRlS8Y7KQt ooUlHSnLf0s.YNEGKpI2YpllTNCluNU2cvfzqnKhwQNTzL5EbS2gv9GX_Uu99P7N509NAhb1z6gB DOq7pdcY9SSxE9xgB9Q5_eUVRsXbuo6q.R92PE0QjXEeEbapq8alPeEhRaWeXB2ljBhmf17yNLQw 8W8DQjY5sV2.DpEB_P2BYPbnXq2q7QokMiQDxkOWT1V.ad3SxPjzRDxj71FTF0lPybkdrfEcWO7A n26zJKKgoWkSylAdRcWK8JKrK7fTN2IrFdEx7xTRGB2K_SBzThB7D62cL Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Jun 2020 16:02:31 +0000 Received: by smtp426.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4cec819c0f50f3a7e39ac60b6a6ac207; Sun, 21 Jun 2020 16:02:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) 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> Date: Sun, 21 Jun 2020 09:02:25 -0700 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <476DD0F0-2286-4B2C-8E44-4404AF17F5A8.ref@yahoo.com> X-Rspamd-Queue-Id: 49qckd6BGbz4BnL X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.76 / 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.64.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.02)[-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.64.31:from]; NEURAL_HAM_SHORT(-0.23)[-0.228]; 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 16:02:35 -0000 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)