From nobody Wed Feb 02 01:25:33 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23F1119B58E9 for ; Wed, 2 Feb 2022 01:25:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4JpPJ84hXlz3PYV for ; Wed, 2 Feb 2022 01:25:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643765136; bh=sbQdHWX72+RR/x0pM/PGXuvQva5aU25JTYb2A4c2ND0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i/X3zcTkOnSNmHjFu0QEBaDOFL5HMIUsUXadYjhGog4fONcTFcaNA/uUQrB4fWHhQnoN2cRthAbRShKCw3ug6bkuMvZhXEBZnFLaOybAFeiSF3cNGcLcKQXNaCMDvAJHvaaw4PhmkCf+JnMV+0MgVeeV478L3C/Lwl7Oc1UBXVbxazkGDMXYFV+whpEDeEndPvS6seBx/YV+3J8yy0/njJHz76bD/mZ98zaE2ybRehL4tnTLOt9SYXzLkoyJCkECTtz2o6yAxPUSOUQUtz0/RsCPFSl9VknwSTqGoSYe7AZurqIIiEE9Z/+oIpXLuujwgt4GKeyhqp9WXrn4sEp6wA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643765136; bh=yW0c9OrVIKEECMf2bhlJvOb46LobUFj2kHo3T+k4AuQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=o7ne0cS+jN/1CcBOjbyE/Rz2D6cxkDpsLSkVmY0lQWMscPXM7wuuur1PxYc9auTYFqyR93pDVSD0Kof/nTuNumuZKO7USStw3ul6TaoGphQevdrx7/BuQNRHQi7hHsIpkAE+q/ow5PZbcQvzoR2lVbMICEy0Hn7fHAG2iQqnH37WEdqG0CgTyRHdw73qi/f04+2KREztYBqRYM0B0Cvl05SrgQlpRG9WovvKeZnc64nPvf4JfG1znIkWG6KyDUDm6tJPoKf1dQARmTXsc4nHWRdo2sVrTwNLCuj7Bwp9DdCuvubk1lyo6ymLFMUmE9WRl1K5ordeI2IHXcr43/5QdA== X-YMail-OSG: doFJjBYVM1mwaod8DqslsAgi8M0bokJSCmODwv0C2UZlGpqVMb2L9ZRuysMhrLx PLC5Nrfv_aBcQTc3N3iWIFCqCMPnNQOEpWwVTerjyGFoQYoBm743ZVLUq5wQiN3ixdPJc1rR3fzA UHsTHLGBKHQXEd1gKo6w612r5OpXZU22Elip1apCjXr9P5qbBLctm3QMMPqNvVecQDyRayxMyRWI HLKm4dfxKL.cu6ANg0PM2ArInJfhlcLMZep1X7JD3qdR_NFH5IUU1ni6iUBTmmy4vjg5o10oJdq7 Xq7yiHr3l9CNlcKFfxe5x_CWC6P96wef4njZxC296Nc_tDYccuuu96fAc4Ox9ONKcJyXMXwk5RzR y0TMeaOwqoKkI3cV27neLQRcMUEVYsLk2WIf8U1Qnnu4F4uQbK6faHYjJNwiARy8juBjVy7blE5X 0g1qbu8fZ5tdc1jwLS_Eti96pfzsC0slxkA3.Hv7NZJwUKNjmZMXKf9AbuKGFfyPb0cI4ykwXNee 0A1YqsYm65yo8ZIL58Tn.kobE5ksvkrHYjdvmj62H3l0fNnJ31CR9OOyzWKSxrSDsW6y84fWfCy_ rgcHqEyano9qaaCMb._td1NlJD7Nvcb56lIv22igCht890Es5DWdmtyVFlnXg_KP_movug_.TgzV .pH.P4gPW1C0Yk303JA_czqYfMyhTAke1EdSagJZlXblRofu7kRT8RKXoW0Q8PsUnc6uWgFacoE3 AL2MQGn1UbHky5K1iCvMwlNDxHWhHxbcRFR3ffpy3tL5NQliG5lQ8OODlHT6a5WTLWpEClAYjH9S 2DMDcQd4.cI5tHxSzA0relH74wxrkzeDH_i9.qU2BaKpNc8jOwWgq0tzm7vwcML1_ZZDxD7ctgWO 0Liiotnqd3e8X3GmCFTk_MRShU1l8AxcdUt_2KXd3sUVcAIPdhCpZ5oOLxjM0_jhTfGDMtrcws8t 0AmafdoGtxf.to3ibDjC721osDqHbimNbvCtF3cFjidw.qV1KcWuVZYOmKQxkAHxFoOw1qsMla81 GGBf0E1OwBOIPCDFLP.Z4Zrnhunhw6OLEa3cbbLOY0wNiOZ7K_e51i5Y5cNqf6_w4pLKu6tKOSDC q8Vbg7Yg81YC4QvR7WTfQie6b9RlvxcHISAPoXreiUUHkyFaJwnsZDWEjC_xqbn2e2oWPI0YFaME GlyGQAWcZd480lY2Oak5ySOo10dSQl8dhpD550DRBlDBkeyaFFhCinbkVhuZrUh3TpFnnmLBYwhY od5ORC.Z6FUUU1nvEla3GmD93kV.vRag9BOBfRjjjD.d7foTopazgdHXLeIJ7RGpjv1YIuvBdkVN 9grW8ksmrNdznLSolVzFWJJJH3OAxUb7WQgcjfkW4Za_NOUqhF6mPQ3Cy.e8lQHXGPiwBU_GPjE4 wgZBVC2vlxYyXOew2pm.SymK336gsQBrlweaVcCkN_gQjh1e3.0zhyqvP4sQYUqhkkSqcIrn0yK8 XXzNFEHqwFAdust35PX9ssal__5M.l577gYX90JGVmFvndcI7NINLPztYbr498.dfLXGfE7wlZzs n9kfT.tpJq5kSRyAMuzE9hOBD3BzKvyHjadbdfxB7q2Zl0hNLs5U9rk.wjkLPhclJwFNa4nullbn yKXHyLL4cdh6El5gzB9j6JzPCQJKfMSwJVdnx4apYjqya5DI31cAPysBWP2yTX4QZ9Ah1Z1jbisM O3Z7cgT_LzgotMYR3AOrTxyN4t1mGeM_aQ2PGrzyj5TZFulAE9L3kt7R9WuRE.cs.uGKZBmXVuu4 PSTbBsBwgaXJXpdDXk3kolq1vil5VuyQhsa5EFu44W_0YvWgZGmVKAEiiChcFVIBjlvl3h.iEka. UYzz6sAq2RPSlgRQwpGjkYH35XDKT8gN.enxS4SYX2R6tkulZbK28XxtL4SNYSFmcm6FzWQY5jU0 JvxEXyqZWlZOb9v5apIeZ99_MwYC5cOlXgafK0L1u2cPSL33exMDtHAgJLjg9XYblVILAwDJxYd4 UiCv8sJEOB.VU07xgD8Eo0li8ntjiLBHJGLaQZGbvycoCgexONgX7Q8TNykI7g9TMgswF7mH5nRJ 1QF.G7WodcNIt4zo4iIU4xDM_zM8V.XSfIQWDvhssKhn9jpU_VuEBGoq23Qof3hIWjrse_kG_Pen KmOXM3bYk8IwXKOeKpwoZrjn2QQrCtOaMOzfCNUXSZxzAg6i8bJ6j0a8bZTic0q.mgYkYqhT2QlG GhbhMRh9qAXEh1hvZiVI6IXz.cY87Xkgtm54z3W40oAwoBl59ypOGA192fSXHH.UFq2adB7r3d0y JsvPFlO7Q9gCL X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Feb 2022 01:25:36 +0000 Received: by kubenode502.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ac14ce952261fb7ef9399afbc7281a14; Wed, 02 Feb 2022 01:25:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 From: Mark Millard In-Reply-To: <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> Date: Tue, 1 Feb 2022 17:25:33 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> To: MJ X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpPJ84hXlz3PYV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="i/X3zcTk"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Feb-1, at 16:47, MJ wrote: > On 2/02/2022 3:18 am, bob prohaska wrote: >> [new subject, different emphasis, old problem] >> On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>>=20 >>> One thing that could fit the behavior is if small part(s) >>> of the system c++ compiler (or libraires it uses) were >>> corrupted on that specific media. In that case, nothing >>> elsewhere would replicate the failures but a lot might >>> work without using the corrupted part(s), making the >>> failures not random. >> [spaced for emphasis] >>> Checking on that is part of why >>> I'd hoped to get a lldb report for a .sh/.cpp pair >>> leading to failure on your RPi3* in question. >>>=20 >> If/when the stable/13 Pi3 finishes its -j1 single-user >> build/install cycle I'll make a point of trying the >> .sh/.cpp test under lldb. >> For most of their operational history both troublesome Pi3 >> systems have had some of their swap on microSD. If there >> is no error detection at all for microSD-based storage >=20 > Is this true? I would have thought it used some form of error = detection in the firmware or in > the controller. The type of error and stage at which the error occurs matters. The firmware can not cover all issues that lead to corrupted content on media. >> then undetected corruption of data from swap is a real >> possibility. I expected that storage errors would be >> reported but maybe not, especially outside file systems. >=20 > If indeed your suppositions are correct, would a file for swap be more = prudent as it has to > go through the file system (UFS/VFS) to read/write to swap? No. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 and its comments #7 and #8. >> Mechanical disks have some internal error detection and >> report explictly when data can't be retrieved. As I think >> back on it at least one flash device (a USB thumb drive) >> failed silently, no reported errors but also no-write. >> That was on a filesystem, so the OS noticed and so did I. >=20 > But this could "simply" be because one of the NAND blocks has failed, = not that it could not > detect an error. Is there a lack of error detection in the driver = handling USB thumb drives and reported back to the kernel? I do not = know. Bob's context is reproducible at the same places in compiling the same files across buildworld with varing -jN figures, prior history since boot, use of the .sh/.cpp files that the compiler saves, and across reboots. Such is unlikely for hitting the same problem page(s) in the swap space each way things are run. >> Is there any error detection/correction employed by the >> virtual memory system as it reads and writes mass storage? >=20 > You would think there should be. Any corruption on media would more likely be in the compiler's file(s) for Bob's context. (Source code that fails to compile in Bob's specific RPi3* context compile fine when copied to other machines.) If there is such a corruption (unknown), the memory content to be written might have already been corrupt before it was queued to be written out. At this point we do not know if there is any corruption involved. =3D=3D=3D Mark Millard marklmi at yahoo.com