From nobody Wed Feb 02 02:52:10 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 DFE3719A4290 for ; Wed, 2 Feb 2022 02:52:24 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4JpRD76Yw6z4h7s for ; Wed, 2 Feb 2022 02:52:23 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x1033.google.com with SMTP id o64so18987316pjo.2 for ; Tue, 01 Feb 2022 18:52:23 -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=AYRcSmvBO32GDjiIzIRpmw04mzYSpQeRA4kvs45d5Io=; b=C1452iDQSIkcktnKUNBh8wtHAsQY7YkTzSRqnhCCvP2IgCxKl8KTBZi047GvrOejxj eF4QlOhhwgUYBk77zjTMmqSyt2oPPmaP5ASQPjfprDcoMTCrzNG/XukzuHUIpAKQvle4 yWjAih+GYk/gqvdWf5KedtkJPagOp/KYdth4eI/vIIC29CXX1JLHwf7ingIDV8ijVV3r JwlEu8Gq68Cbi6BZJdkOB1+Dv7gdMJvAdsZHQR9n1+yZk8xFlNOQMTxwz5ld37P1g6FO l99FnT+eue6nIEj2VoD+JgAHgiLEW+RXcMdWm17FQIZOdjvzRanODikQYLfMKQ1SvYSy jn/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=AYRcSmvBO32GDjiIzIRpmw04mzYSpQeRA4kvs45d5Io=; b=5aCKcMzaiz0419gNuDJPqpQ3OsrnWUXujAmmXGxjH3879WT3DPsUzEC3LsEMYUKG+K 3Xo7PCqANYdGqBlmInuL1RmOhjnT2A8DDu41IiJGTscpVkM0FyASfYjsXDQjfaMrzVPV 2LKWxqAvWPeLb9GdtuCiu3VIH9psr3ZN5GtmXyrqnNPVe000zN1/CF6wE42+TwIBhArX cCGkPYlGJz0+F+14mXOb8T9wLrAYh3ekhcYJ4hHs6jypEDZ90+v+VQNQIqAzrRGLcXXT GpJ2K70HepqvEXL3xX9DfHejZjUee2Ff+yVQfwCuqSNFHfPxmYskh1DvyjK9+dFDk1/Q vErQ== X-Gm-Message-State: AOAM532oJX36UBpQxnmbYrNbDlCSQeqoqDlEKx2ZKKm6KgJhUbvQSI+O yOj8XlsrgmklDbZ+2SSLKFEFhgtRgfbbzQ== X-Google-Smtp-Source: ABdhPJz1fd+rgBz05DZKQE3pivt25upypAC/AwsHWB6ZuN7N6A/u7EaEGyD0HE1bmcaZYevmQNvr2w== X-Received: by 2002:a17:902:da87:: with SMTP id j7mr27870185plx.57.1643770336371; Tue, 01 Feb 2022 18:52:16 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id x17sm21756842pfu.135.2022.02.01.18.52.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 18:52:15 -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> From: MJ Message-ID: <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> Date: Wed, 2 Feb 2022 13:52:10 +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: 4JpRD76Yw6z4h7s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=C1452iDQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; 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::1033: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 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. > >>> 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? > > No. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 and > its comments #7 and #8. > This seems to address potential memory over-use because of a swapfile, not the safety of it over a swap partition. I still contend the UFS file system has better protection against corruption than a raw partition labelled swap. If Bob's requirement is a "safer" swap, then a file would be the answer. Whether there are other issues to contend with are likely out of context in this particular discussion. >>> 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. > > Bob's context is reproducible at the same places in No, he was talking about a "failed silently" event and this is what I was replying to. I am not up-to-date with the previous discussion on the failure of llvm/clang. > > Such is unlikely for hitting the same problem page(s) > in the swap space each way things are run. I couldn't agree more. The chances would seem remote, unless that partition is on a part of the SD card/USB drive that is failing and the USB driver is not detecting these as reported by the controller. MJ