From nobody Tue Feb 1 17:58:38 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 A102619BB021 for ; Tue, 1 Feb 2022 17:58:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4JpCNT4vkhz3jJc for ; Tue, 1 Feb 2022 17:58:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643738322; bh=h5cctThHFge5aOjX0MWdm3h3SJYsJXlYgmujCm3Q0bU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tmdKCorqyRpD5kyonB3rJq9tcv0bDFwfISV6oJNjJLCC+AlrmlwAfmuj+zdkg709uojp3Bs4mVKUkx1mfRV9EhJH25lAbcEusH5Fgm/2/hNijoVIp3NW0adgYCl5Ng8MKv2XISpufUaN+82wI7QwwIkoBlMNog2VOsDXuk51z34l9HCKRSM+WlvNPVrcbx7bz953Vk8bJeIlFLgLjLZWa0b7q3xSZeSk4mQJEPHf89iLj0lmWW0hDFTya1ShgzrwsgS9xpDHCke5u7YiP4Ek25gcUZyzk0dKLwZDAw+WZSH9Iy0Bub9VCibFQlNUyYGUOe2INI5CFOBSNxtfbWy+Fw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643738322; bh=shZIlDOPBIk8RXIRRRUCNLQN6AJzZHmDG2OVm+OQNBh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fMfh4y0kTG8zRVi4bZ3CJY0OzAjWkUq0Zf6EZx5yXqj33StXa9R8vapQ+r6bVm8zaRIbCiGuvydknigTv1zjxT7SkBMsZg1fNmhunoKxDNJ9+NoI8hwSgWjBt+w/HP0YP41uVolj6lDpkVKl8hgkoifOnRt1QS6Z4Z5rQmFyQlOy5ynM1wxP2lzM78i0pXbgfG16908zrXkrMiQkYRdHcDF5VjLWZnVUCnGGHu1cYeXEEvpZaVE7/t+ojj4qKmtWTOiIJEzKh1gojJ5ro2eqVE2Rliri6QfimXc8yXGejsj6SpPb7zGzydUZt54/q/5zD8Smjxig/oWd3n3JsqDGpQ== X-YMail-OSG: jZawnV0VM1msDq2VE1utG6cxvg7Y1oKJVt4vjqck7aCx94.WobAKXHQhVTPE1Uo 3_P9NbvrByaJL7AL.Xv11WMN0861GNcx7pBqsxYX8tV1UUHEloIq4_NVyTNG3wzfd1hiz6p3vqt4 1YycFuFStxPygJh.gGUeNthtebaM.ZMOvnMGDu.Jez_G6Np7AmuTKdtExsSTnP_WmvKVfLaFESWG aex1eZ13OGO3KBR7lB8SdujsRXWp9eDnK8LqTcGGqCris4EaHJTB0tpC8y1ParnbJ_euuAGHs7BU oHQhFTmKyNBB3bw2mK31mGhHrHfaDCKZuVAhObKfF8daQ4L.TKejV9Cv2hiGJB_oqwH2Hmce.kV8 d4TCHuald056rVn5YNi5.IBa6ODEOtrOxdSaNA9i9br4lFAxJ0ej1AbcPuRbQZ1p74zVWSERT_e9 cdc9QRaIOEMioMvYGWxyDSAoR2QUs_ZiwgWGg.w0JE.XhPQtais.BGelrmugpcu753YXkBchVHU3 iOnVyUfXGhUOwHOeGq0NQo_R67KUJNMc5Gjq1w4c4giQXcsvM1nNmpOdvIBkXuoylQ90oVcHWovL p7pWal1T5Mlz0lAH4soNUy6b6UBQ6stNce69C74uQdkBs9CmSvsMqXGKGjWaUU2P9UvLkW7thitd JugDinyp3ZFJTxMqUne0uJP.wGDJ5gYJY8T.SFFjyETGC7l76FTs6._mVMBJKszCkJA8lVaYUq9c Z.Uy.p3tjQB7m2ds_DjknQu3stH4qMhenhw4fOdTxCLNasJLnuiFYKgzx46iK_uKD1VltqeyoHSr dLAx44UCS4KCUnFm6maRjRoGBg6xv_83IUr5c7mqNmXjkiz4WQwyevr5YaxBbDxBwd0eDMnOvQAP OuVxBoutxL2uJ7d5Dk5wWILE14kbvBP5FtHY7Shz1vdx4PM0HaRoiRS_XNR4uecYqk2ioql7O_Np _NBpWTkL8.ae79jBPitr9ZjlgnDpssj3bgFJxmVE9SSoX5VTp.y1ox___TB5NOylRT5lP4EtVO6w gF9ADcX_I0j4yBGigjqDVi0hXJHoDFWRJ9147B3xnHJuDidw26qsjS35muyeag123XC_OjXFbgdR wfkVV69k8Zql6nnx7KoOY855RTbjWR0se5QROXzNz9vTkov7YXk5Gg.R7pjEqv4yREGAzw0tlFV_ 6lR.GUep9F7Tev.WO5zuSmaKJnYblVPJONqiedud65JoAbDBCo1JQAvtsfzL5c1_xnIXVrQqHDMh REBUtjBEy21S2N67jMPkf32U7K6IVQP8ogo7qw0gY1XqUdbKVjgdzYUFgN_f9cdQx9o8WE2BHIpj Azy13ef7i9GHJ6dvWNSHlCk_DFn2raRuQ3zJZ5aUKHKgdJgEFPl8cJ72rZMvkNz0ezGqRGG5uDy. cpZbsXM3.Fy0g3ulUAs5Gpg9YriCJyaVliHuwbjZRKWqqnJPtrS1Ok0FVghONAvPPKbArmMw_.hJ FBUobXKfyk8_fCCnQvvzwGPlr8iLbZoky54by6t762bXxu0T9bK1dz4VT6uDaGbw2tNlCZPDM2gy 1yq_4zDuYitKNWUBLdHvTw8Evji1HxBFkkMaD_whlan4TY3PvaVgXOEIMRGQCqz.Hw_ipPYpZQwp w.P4dXCAYoMxBkJxfXlCoR50TdMo6lnzPNVLiiFPddVG0xtHI_oQWK334SzmpPdFZ6ECdlYZPz2A ECPx3B3W3_FS6nB92YbN9JS7f0xpS_3aDEJ3S98FchQumS26yhfiFMNic14fZ.hIBNE448hSeA6. G8ol1cF77LbPDL4qUYbMOvJhctt95daUvc0gdo8ZstftPXDSp8KIHbR3KFrWs9rg6jZy7R2rE4Z8 I2L.oGN3xS3Z4bYRgAu0uhZcCt2NyXf51r9nlXVG0lJL_pk0zjF.qjUVIPRTG8HInC8dY0w.UAq0 GjOoJV6M6bg0YB94cU0Qgv6v9Igwgo6K7GEu.O6gBcZvCqyr3RLlxMF0.xdnWKr6U0BV0wk1lY1Q 74Ki3LIx12LwCJl1BgQQAK7QfXle812FvNuuJzknh6jhPwdFVMpn2uQPfltHGB25rEP6Gvp4aoh. hYMwy_iJd6454t6T3iJJYldJzMGD1NPFoPZbP2bmzBjsJgLaFM2cYHI.Q6y2_P_ITXRWdy.VzHqY DjH.rO_9feJ8dbqkyNLlTAtgzvvrxtD6CXMKA.x4Q4QGMGYPOkXxNOLjyjQ3CbcEHVT8XFfF12nN OnMp0t6F0K1XOLU5ZF3Uy78Q5e94YIxiFiovhoNUgiPsFeTJuPE29v7XS8lMyf7LpWsKDqVBjDD2 0Pvz0HW_Eg9U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Feb 2022 17:58:42 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b7e4f4c1c303c428331870815c762a94; Tue, 01 Feb 2022 17:58:39 +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: <20220201161808.GA73977@www.zefox.net> Date: Tue, 1 Feb 2022 09:58:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <304EFD6E-2D92-42F6-AB13-285BE0B15363@yahoo.com> 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> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpCNT4vkhz3jJc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tmdKCorq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; 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]; 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.69.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3524 Lines: 98 On 2022-Feb-1, at 08:18, bob prohaska wrote: > [new subject, different emphasis, old problem] >=20 > 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.=20 >=20 > [spaced for emphasis] >=20 >> 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 >=20 > If/when the stable/13 Pi3 finishes its -j1 single-user > build/install cycle I'll make a point of trying the=20 > .sh/.cpp test under lldb. =20 >=20 > 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 > then undetected corruption of data from swap is a real > possibility. Getting a systematic error (SEGV) at a specific point in a compile across many attempts with various prior histories, reboots, etc. involved is not likely to be from somehow hitting the same bad page in the swap space each time. This variety has varying -jN figures, which can lead to variations in which compile get an error first. But when it is a specific file that gets the failure, the detail seems repeatable. This is true of the .sh/.cpp pairs that fail reliably for you as well --especially given that they work for me, even without swap enabled: the 1 GiBytes of RAM is enough. (Swap required for running under lldb.) If the problem is a corruption, it would most likely be in some file in use by the compiler (possibly its own file): a file in the UFS file system. > I expected that storage errors would be > reported but maybe not, especially outside file systems. =20 Not likely to be a swap space issue. > 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. Storage media can not generally detect if the data being written is already corrupt before it is written. > Is there any error detection/correction employed by the > virtual memory system as it reads and writes mass storage?=20 >=20 No separate one that I know of. But getting a systematic error at a systematic point across a wide variety of histories is not likely to be a swap I/O problem. If I understand correctly, the normal recommendation is to avoid using microsd card for a heavily used swap space, reliability over time being an issue. (But I'm no expert.) For reference, as I understand the following is a repeatable part of the failure notice for compiling contrib/googletest/googletest/src/gtest-all.cc : 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:806:37: current parser token '{' 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' But we know that when I make a copy of the .cpp/.sh pair and execute the .sh the compile works fine. This is evidence against the source code being compiled being corrupt. =3D=3D=3D Mark Millard marklmi at yahoo.com