Date: Sun, 7 Mar 2021 08:46:10 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4 Status and sysutils/rpi-firmware (and rng) Message-ID: <67BF2EAC-04AD-4822-99B2-48A99563331F@yahoo.com> In-Reply-To: <20210307155515.GA4591@www.zefox.net> References: <BDF8C846-1CB3-421E-A8D5-25E0075C7106.ref@yahoo.com> <BDF8C846-1CB3-421E-A8D5-25E0075C7106@yahoo.com> <20210307021628.GA99890@www.zefox.net> <AAA4E495-4E9E-4C55-A07E-74D9737EC15B@yahoo.com> <20210307155515.GA4591@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-7, at 07:55, bob prohaska <fbsd at www.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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67BF2EAC-04AD-4822-99B2-48A99563331F>