Date: Tue, 25 Feb 2020 15:05:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Showstoppers for RPI3 Message-ID: <11951E01-EC13-4FBB-938A-AEB5700C4281@yahoo.com> In-Reply-To: <20200225175446.GA77976@www.zefox.net> References: <20200225175446.GA77976@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Feb-25, at 09:54, bob prohaska <fbsd at www.zefox.net> wrote: > There seem to be a handful of problems for -current on the RPI3 at > the moment. Those I've noticed include not getting multicore operation, > cpu_reset failing and OOMA kills with vm.pfault_oom_attempts="-1" set > in /boot/loader.conf. If you are seeing vm.pfault_oom_attempts="-1" fail to work on or after head -r357253 (from 2020-Jan-29) that is likely new news. However, for aarch64 RPi*'s, this is after -r356767 where the kernel needs to be told to avoid touching all the armstub8-gic.bin or armstub8.bin RAM. (Previously worked only by accident, i.e., despite not being told to avoid all that RAM.) It is messy to make judgments about aarch64 RPi*'s on or after -r356767 (until/unless all the armstub8*.bin is being reported to the kernel as RAM to avoid): too much ends up messed up by the kernel replacing part of armstub8*.bin's RAM content. The problem -r357253 fixed was for all platforms, not just aarch64, much less being aarch64 RPi* specific. As far as I've seen, the platforms that do not have problems at -r356767 are no longer getting reports of vm.pfault_oom_attempts="-1" problems. The armstub8-gic.bin/armstub8.bin RAM not being reported to the kernel as RAM to avoid touching is a known problem for aarch64 RPi*'s. But, as far as I know, no one has indicated that they are working on getting such RPi*'s to well report armstub8*.bin RAM to the kernel --or that they are planning to do so. As far as I know, there is no evidence that the kernel is doing anything that it should not relative to what has been reported to it. The problem is aarch64 RPi* specific for what is being insufficiently reported to the kernel. > What's a good way to figure out when it's safe(ish) to stick a toe > back in -current? Are there any relevant bug reports to watch? For aarch64 RPi*'s, either one sticks to head -r356676 or before (which is also before -r357026 introduced the vm.pfault_oom_attempts="-1" failure) or one patches in a work around for reporting armstub8*.bin RAM to the kernel sufficiently for now and otherwise uses -r357253 or later. The patch could be to FreeBSD code or to u-boot code. In my case, I kept my sysutils/u-boot-rpi4 based investigative workaround in place: adjusting an efi_add_memory_map use to change an in-line constant from 1 to 2, indicating to avoid another page of RAM. I do *not* have FreeBSD patched for the armstub8-gic.bin RAM issue at all, just sysutils/u-boot-rpi4 . === 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?11951E01-EC13-4FBB-938A-AEB5700C4281>