From nobody Wed Feb 02 06:46:26 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 BC5B319A4D8E for ; Wed, 2 Feb 2022 06:46:40 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4JpXQQ0ywVz3PL2 for ; Wed, 2 Feb 2022 06:46:38 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x1036.google.com with SMTP id o64so19413285pjo.2 for ; Tue, 01 Feb 2022 22:46:38 -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=QxsRMBxHGFu0DxKlgeSr6FPbj/GszCjoWuW3fHFyac0=; b=IMFrEaK+YPvERTWAsUCcfMPJReWC/kTGCVofkxwgX/5mTdjdEJNFiANXqoZUm6+OAo pn27S8F9tMVGPzxJH8pNcyd+NtLZdsfpvd4rrzkpHGJVkEisih/TfDqrNOwfnVEm8l5N R74JBb+lBuA/Q8hzFHm/NTk3SmJTNcLIb8oemBz9RYKhYzDij7eIRGW63thavR2Y9gKE ocmRjN8X9TRwNA5cIeqJMhPQLchy6R33utyMeBYX6d1d09HQAndoHQ9Mj2GkxmfNAY7W NVppouK0sJUw85m1Ag7MqhNP9EVUHlpMKg7d7XyzyTBcTnDBYGqSYjit+q/+swkb65WB 8W+g== 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=QxsRMBxHGFu0DxKlgeSr6FPbj/GszCjoWuW3fHFyac0=; b=4gHXwCksdSTkwnUxzhvB+0aYgorDhiqiosf9mRLglz0w3xcinS6Kg4GUKipXRoSSR/ Q+tiH/4FdYx0dKFvLNuhBculASTAvTExqHmgwmrWPQW/dTCxngh7ZV9vwX/6S34un6Pv ys9lBe2ormQbINU78yXrDPnLNeQK/hRcIfhyMdLna4bWTzkl0pBZHB+McB1AxaUo7iUR u8TfEZ4pWWvA3QvEpMc7A+uBB6W6AR1jD5trk+BuKhCyMFRQtVLjjb8gtRiO6pFMBGrB TDd7aVMUgeb3ZZzSn+A1SfsU32XkxFNHGWteKP7s0Jk/QWbhpA4G/Ts8AVGC3xpz/uNz YTkw== X-Gm-Message-State: AOAM530GkQH1jaMLMk3UQ67ZCCPyBccPX6HwqV6S0kCC8QG3mYNbK4/B Jd5AtNjQLEUV26hyRVUVnoednkBuePGgqQ== X-Google-Smtp-Source: ABdhPJytoQN3hnYOHnUmnZO9rn2jYCz171yQ08qm1JS5zwsufIcuHp849HU8ukUWMHHs7pwU2keKgA== X-Received: by 2002:a17:902:758c:: with SMTP id j12mr29345425pll.79.1643784390436; Tue, 01 Feb 2022 22:46:30 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id mq3sm5499747pjb.4.2022.02.01.22.46.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 22:46:30 -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> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> From: MJ Message-ID: <4f915aa6-4382-217e-d0b8-28346e5bb8f5@gmail.com> Date: Wed, 2 Feb 2022 17:46:26 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpXQQ0ywVz3PL2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IMFrEaK+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-2.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]; 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)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; INTRODUCTION(2.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; 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]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::1036:server fail,115.69.53.183:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/02/2022 3:10 pm, Mark Millard wrote: > On 2022-Feb-1, at 18:52, MJ wrote: > >> On 2/02/2022 12:25 pm, Mark Millard wrote: >>> 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: >>>>>> >>>>>> 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. >>> 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. >> >> I did not state it covers all corruption. However, I would be totally surprised if the controller in >> ALL SD cards does not do error checking, whether ECC or even BCH. That remains my point. > > I've a lot more context on Bob's problem and was mostly > giving more context than he supplied. (My name is on the > most nested text that he sent. I've been working with him > for a while on this.) > Ok, understood, I will refrain. No more noise from me. MJ