From nobody Wed Feb 02 00:47:48 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 F407F198FD79 for ; Wed, 2 Feb 2022 00:48:02 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpNSf0LZsz57lS for ; Wed, 2 Feb 2022 00:48:02 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id j10so16932303pgc.6 for ; Tue, 01 Feb 2022 16:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=31rx4jxUw5W70eBWo0o/65WfgnoK/AqkD+qJz/agU54=; b=CnerIUw7EkpLdPqNuGlODYBOh8BQQ/Vb5JO9Yo+vifdxmkIAWJdPPY/6w9ll+RFKTC SSPUJ+ZpG9cLA0KHWzCj/TN7dUpfu7UJWw3r3z5faxd+reKRtBX5NtziWwv35GHB6iP8 vnXbbb0oRlyATTMtEdPBZqWqX21xLwp4WDzKKtI/C4et5nZ/CVkJclWQlp8PeoR4ahc8 0xYOKI3Ludu4Cx2800ncOzu7Jlwn3txLqOw074svYQz8sB0jJELCZlm9HExrATpVwi/R DCmInVRT45ugLFVAWdXF7WsY02F7S0D8wBOSlLVseEvbV3nv7uyI2yTnmE+37zlDf3Gr lh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=31rx4jxUw5W70eBWo0o/65WfgnoK/AqkD+qJz/agU54=; b=2yflmJsECxdAmC2CcHKMXfE8wQhBoGrzUnCu/SEehd7XREtgNZRGh2dKmEAFFrpvJx t9cBqjCHX3f/KhGLX6L5oa+zl7VUYBmr+rl2iLug71KQ942YXneC+zL5PCnb+37rw3R8 HtOBq7tx4ZOcbGBK3BrXeIVxGv/+Tba28GYqLhinBKxnNmV6AgwKGhn3NShX2K8LEKSc IsNLjJoUv5A+j7XDazyz+uYLammwk4J2Gw052ELAZFvKkxdwoR1JHaiAALcNTUQEEIWm HSQqHvNNm4+qbatcU6reHCGyASAy2aM+30RJk9e8U5T0eAm0JdKlWrgwho3rlEgSyV29 KkFQ== X-Gm-Message-State: AOAM532av7mYkIkRRTnTmCh8sHV1HXke81LXsxxkjHyspu78HbmMY1Ef t8OrHme/XOwB8b5lIH6mnsu/2sp3ZRpD5w== X-Google-Smtp-Source: ABdhPJwgScSJlhgFdkPd38h8+fgD7AoiEbyP1jIs5piZxTyS5n4Ubbjv2p2ouFqwiXqGS876V30ykw== X-Received: by 2002:a63:e818:: with SMTP id s24mr22676063pgh.21.1643762874716; Tue, 01 Feb 2022 16:47:54 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id ck21sm3723632pjb.51.2022.02.01.16.47.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 16:47:54 -0800 (PST) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 To: freebsd-arm@freebsd.org 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> From: MJ Message-ID: <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> Date: Wed, 2 Feb 2022 11:47:48 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20220201161808.GA73977@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpNSf0LZsz57lS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CnerIUw7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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: >> >> 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 Is this true? I would have thought it used some form of error detection in the firmware or in the controller. > 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. 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? > > 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. 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. > > Is there any error detection/correction employed by the > virtual memory system as it reads and writes mass storage? You would think there should be. > > Thanks for reading! > > MJ