Date: Fri, 24 Jan 2020 05:10:22 -0800 From: Mark Millard <marklmi@yahoo.com> To: Francis Little <oggy@farscape.co.uk> Cc: Michael Tuexen <Michael.Tuexen@macmic.franken.de>, "powerpc@freebsd.org" <powerpc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: panic: data storage interrupt trap when building world on PowerMac G5 Message-ID: <3F27CA51-8DC9-43C8-A2AB-63F055641276@yahoo.com> In-Reply-To: <CAGSRtz7Pj8ox5wBDBhYyzGPgmdHP_50Kvjbf4AZd5eJ=v6RgEw@mail.gmail.com> References: <7722F637-2C3D-4199-B2C9-F0616B0A5AE1@freebsd.org> <20200123134114.75d9c771@titan.knownspace> <CAGSRtz49L_AOqm-y0FtZR6Ejesb7Xs85-sy-YXn=2b59SE7UoA@mail.gmail.com> <4652291B-6D2B-4D21-9F01-576913DF0B54@macmic.franken.de> <CAGSRtz7Pj8ox5wBDBhYyzGPgmdHP_50Kvjbf4AZd5eJ=v6RgEw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jan-24, at 04:27, Francis Little <oggy at farscape.co.uk> wrote: > I'm not getting panics, I get similar errors to this: > > cc: error: unable to execute command: Abort trap (core dumped) > cc: error: clang frontend command failed due to signal (use -v to see > invocation) > FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > Target: powerpc64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > cc: note: diagnostic msg: PLEASE submit a bug report to > https://bugs.freebsd.org/submit/ and include the crash backtrace, > preprocessed source, and associated run script. > cc: note: diagnostic msg: > ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > cc: note: diagnostic msg: /tmp/addsf3-67691f.c > cc: note: diagnostic msg: /tmp/addsf3-67691f.sh > cc: note: diagnostic msg: > > ******************** > *** [addsf3.o] Error code 254 > > make[4]: stopped in /usr/src/lib/libcompiler_rt > 1 error > > make[4]: stopped in /usr/src/lib/libcompiler_rt > *** [lib/libcompiler_rt__PL] Error code 2 > > make[3]: stopped in /usr/src > 1 error > > make[3]: stopped in /usr/src > *** [libraries] Error code 2 > > make[2]: stopped in /usr/src > 1 error > > make[2]: stopped in /usr/src > *** [_libraries] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 > > make: stopped in /usr/src > > make: stopped in /usr/src Is the console ( or dmesg or /var/log/messages ) showing the likes of: pid . . . , jid 0, uid 0, was killed: out of swap space ? If yes, then is it also showing the likes of: . . . sentinel kernel: swap_pager_getswapspace(32): failed If it shows both then you likely really are low on swap/paging space. (The first message's wording is a misnomer.) If it only shows the first, then you are not likely to actually be low on swap/paging space. But FreeBSD does such kills for the free RAM just staying too low for too many tries at increasing it. On small arm boards folks have this problem with buildworld a lot during its llvm related build activity. How much RAM is there? Building with a smaller -jN can help avoid such issues. But there may be alternatives. The below notes may or may not prove useful for your FreeBSD head-based context. For delaying how long free RAM staying low is tolerated, one can increase vm.pageout_oom_seq from 12 to larger. The management of slow paging I've less experience with but do have some notes about below. Examples follow that I use in contexts with sufficient RAM that I do not have to worry about out of swap/page space. These I've set in /etc/sysctl.conf . (Of course, I'm not trying to deliberately run out of RAM.) # # Delay when persisstent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 (I'll note that figures like 1024 or 1200 or even more are possible. This is controlling how many tries at regaining sufficient free RAM that that level would be tolerated long-term. After that it starts Out Of Memory kills to get some free RAM.) # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=-1 (Note: In my context "plunty" really means sufficient RAM that paging is rare. But others have reported on using the -1 in contexts where paging was heavy at times and OOM kills had been happening that were eliminated by the assignment.) I've no experience with the below alternative to that -1 use: # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts= ??? #vm.pfault_oom_wait= ??? # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'm not claiming that these 3 vm.???_oom_??? figures are always sufficient. Nor am I claiming that tunables are always available that would be sufficient. Nor that it is easy to find the ones that do exist that might help for specific OOM kill issues. I have seen reports of OOM kills for other reasons when both vm.pageout_oom_seq and vm.pfault_oom_attempts=-1 were in use. As I understand, FreeBSD did not report what kind of condition lead to the decision to do an OOM kill. (I do not remember the vm.pageout_oom_seq figures from those reports but no figure is designed to make the delay unbounded. There may be large enough figures to effectively be bounded beyond any reasonable time to wait for an oom.) === 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?3F27CA51-8DC9-43C8-A2AB-63F055641276>