Date: Thu, 2 Aug 2018 18:09:32 -0700 From: bob prohaska <fbsd@www.zefox.net> To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (insufficient swap) Message-ID: <20180803010932.GA4321@www.zefox.net> In-Reply-To: <20180802015135.GC99523@www.zefox.net> References: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Just for fun, and to provide an alternate view of OOMA behavior on an RPI3, a j4 buildworld was again run with deliberately insufficient swap. A single 1 GB partition was used, on the microSD card. Having sufficient swap on microSD allows a successful -j4 buildworld. The debris I could collect is on display at http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/1gbsdflash/ The behavior suggests that OOMA misbehaves in both possible directions: It kills processes when it shouldn't, and does _not_ kill them when it should. The same behavior was observed some weeks ago, but this time it's possible to watch the gstat output. Please note that the messages Aug 1 18:08:13 www kernel: v_free_count: 5439, v_inactive_count: 1 Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of swap space are stale, left over from an earlier run with swap on USB flash. There are a couple of core files included in the exhibit. At least the top session crashed with a signal 11, it happened when I was watching and I restarted top, which then ran normally until I left the console. That's a somewhat unusual occurrence, signal 11's haven't been seen on this box any time recently. I did not see what happened to tcsh, but it left one core file. In the end the console carried a stream of what look like hardware errors referencing da0, but all was forgiven after reboot and a couple cycles of fsck -fy. An excerpt is in the readme file. One curiosity is that the system remained responsive to ping. The console wasn't responsive, ssh sessions either disconnected or froze. Power-cycling was the only way to reboot. Thanks for reading, I hope the observations are of some use. bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180803010932.GA4321>