From nobody Tue Feb 01 16:18:08 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 5168419A0F70 for ; Tue, 1 Feb 2022 16:18:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jp98N4qPHz4WCp for ; Tue, 1 Feb 2022 16:18:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 211GI99q074075 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Feb 2022 08:18:09 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 211GI9FS074074; Tue, 1 Feb 2022 08:18:09 -0800 (PST) (envelope-from fbsd) Date: Tue, 1 Feb 2022 08:18:08 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Error detection for microSD-based swap, buildworld failures on pi3 Message-ID: <20220201161808.GA73977@www.zefox.net> 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> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> X-Rspamd-Queue-Id: 4Jp98N4qPHz4WCp X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [1.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.995]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:query timed out]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.08)[0.076]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N [new subject, different emphasis, old problem] On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: > > 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. > 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 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. 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. Is there any error detection/correction employed by the virtual memory system as it reads and writes mass storage? Thanks for reading!