RPi4 Status and sysutils/rpi-firmware (and rng)

[Mark Millard]

On 2021-Mar-7, at 10:08, Robert Crowston <crowston at protonmail.com> wrote:

> You can generate a test file with something like
> head -c 8000000000 /dev/random > yourfile
> md5 before and after to see if they are unchanged. That was how I did my testing.

Great techniques.

I originally did the diff comparison in case an issue was on the
read side of things and to cause it to be less likely that cached
material was being used instead of going back to the media to have
all the stages of processing for most of the reads.

> [As for MicroSD wear&tear: I keep hearing people talk about how unreliable these cards are, but when you ask for hard numbers about lifetime, no one has any. I've had one SD card out of dozens fail on me, despite regularly dd'ing out entire cards -- this is a better failure rate than my mechanical hard disks. SD cards are also very cheap. To me it seems like an irrelevant concern, unless you don't keep backups.]

As I remember, Bob has in the past replaced significantly used
microsd card(s) to get rid of problems. That is what prompted
the thought. I've never had to replace any but some of Bob's
historical usage pattern put a much bigger load on his than
mine ever had. I also do not expect much value from doing the
specific tests, given my tests passed for the issue in question
and prior testing of older FreeBSD versions booted via u-boot.

> — RHC.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, 7 March 2021 16:46, Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
> 
>> 
>> 
>> On 2021-Mar-7, at 07:55, bob prohaska <fbsd atwww.zefox.net> wrote:
>> 
>>> On Sat, Mar 06, 2021 at 09:30:33PM -0800, Mark Millard wrote:
>>> 
>>>> I've not done the huge-file copy-corruption testing
>>>> recently, and never with stable/13 or releng/13.0 or
>>>> a 13.0-BETA*/RC* . I probably should try, booting
>>>> a 13.0-RC* image as the context (other than the
>>>> rpi-firmware replacements). I use a file that is
>>>> notably bigger than the RAM.
>>> 
>>> This is -current, chosen to be the latest offered.
>>> 
>>>> Historically, if the corruption problems show up
>>>> the technique to get a reliable environment was to
>>>> restrict it to using 3 GiBytes, possibly via some
>>>> text in config.txt . This also applied to the
>>>> RPi4B 4 GiByte models.
>>> 
>>> Might it be useful to attempt the huge-file corruption test?
>>> This is a microSD-only setup, but it's a 32 GB card so there's
>>> enough space for a file bigger than the 8 GB RAM. The most obvious
>>> sticking point is need to manufacture a test file since there's
>>> no ethernet. The second issue would be reporting; all I can
>>> do is look at the screen and make manual notes. Enough for a
>>> go/no-go test, not so good for details.
>> 
>> For u-boot based booting the expected result with 8 GiBytes
>> of RAM in use is that it would work fine: the problem was
>> addressed for that kind of context. It is the ACPI type of
>> booting that still has the known problem. For 13.0-RC1
>> my u-boot booting based testing would be that the code has
>> not reverted somehow.
>> 
>> I tested 13.0-RC1 using the normal u-boot style of booting
>> and it worked fine: no differences found.
>> 
>> I tested my main c113740f266e based non-debug build (about
>> 4 days old) and it worked fine as well.
>> 
>> I do not see that you would gain much from repeating the
>> tests on a microsd card. The wear-and-tear on the microsd
>> media used and time might not be worth it. Sneakernet of a
>> microsd card prepared elsewhere would be one technique
>> of getting a large file in place. Another would be to
>> compile a program and run it. What I did was to make a tar
>> of an already huge directory tree that I had.
>> 
>> Given the initial file, the test is simple: cp the file
>> then diff the files. If the diff finds the files are
>> different, then some problem happened, possibly the old
>> DMA handling issue. If the diff finds the files are the
>> same, then there is no evidence of the DMA handling
>> problem.
>> 
>> (cmp or the like could be used to see some about the
>> differences if there were some.)
>> 
>> I happened to use a file that was 11570948096 bytes
>> long. (It was a tar of a dirrectory tree.)
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)