Re: Error detection for microSD-based swap, buildworld failures on pi3
- In reply to: Mark Millard : "Re: Error detection for microSD-based swap, buildworld failures on pi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 02 Feb 2022 06:46:26 UTC
On 2/02/2022 3:10 pm, Mark Millard wrote: > On 2022-Feb-1, at 18:52, MJ <mafsys1234@gmail.com> wrote: > >> On 2/02/2022 12:25 pm, Mark Millard wrote: >>> On 2022-Feb-1, at 16:47, MJ <mafsys1234@gmail.com> 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.) > <snip> Ok, understood, I will refrain. No more noise from me. MJ