Date: Sun, 14 May 2023 13:00:46 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current Message-ID: <F6FDA155-C0CE-4BE6-9145-FB1038290326@yahoo.com> In-Reply-To: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> References: <ZGD/8CXbIFtCuiFF@www.zefox.net> <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 14, 2023, at 12:31, Mark Millard <marklmi@yahoo.com> wrote: > On May 14, 2023, at 08:36, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> Lately a Pi2 running -current has gotten stuck while buildworld is = running. >> There's no escape to debugger, no obvious errors on the console and = only >> modest swap use (tens of MB). So far the stoppages have been when = building >> clang. >>=20 >> One possible culprit is /boot/loader.conf, which has accumulated some = baggage >> over the years: >>=20 >> bob@www:/usr/src % more /boot/loader.conf >> # Configure USB OTG; see usb_template(4). >> hw.usb.template=3D3 >> umodem_load=3D"YES" >> # Disable the beastie menu and color >> beastie_disable=3D"YES" >> loader_color=3D"NO" >> vm.pageout_oom_seq=3D"4096" >> #vm.pfault_oom_attempts=3D"3" >> vm.pfault_oom_attempts=3D"120" >> vm.pfault_oom_wait=3D"20" >=20 > (I oroginally had a note here but I think it > would just confuse things and not be tied to > your problem.) . . . >=20 > However, I expect that your user process had > its kernel stack swapped out. See below. >=20 >> kern.cam.boot_delay=3D"20000" >> vfs.ffs.dotrimcons=3D"1" >> vfs.root_mount_always_wait=3D"1" >> filemon_load=3D"YES" >> net.inet.tcp.tolerate_missing_ts=3D"1" >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >=20 > Those last two lines are for avoiding having > interactive sessions (sshd, serial console) > processes end up with their kernel stacks swapped > out. (But it does so by preventing such for all > kernel stacks, not just the ones of interest.) >=20 > When a kernel stack is swapped out for a > process/thread, the process/thread can not run > at all until the kernel stack is is read back > into the kernel. >=20 > Those last two lines you have in a file for > tunables --but are not tunables: >=20 > # sysctl -T vm.swap_enabled > # sysctl -T vm.swap_idle_enabled > #=20 >=20 > Compared that to the check for the writable > category: >=20 > # sysctl -W vm.swap_enabled > vm.swap_enabled: 0 > # sysctl -W vm.swap_idle_enabled > vm.swap_idle_enabled: 0 > #=20 >=20 > In my environment, I use /etc/sysctl.conf , which > is a place appropriate for non-tunable but writable > sysctl values: >=20 > # grep vm.swap_ /etc/sysctl.conf=20 > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0 >=20 > I suggest moving the assignments to /etc/sysctl.conf . > I expect that this will get rid of your problem once > you reboot with them in a right place. (You can also > interactively set them via sysctl use.) >=20 > I suggest avoiding confusions by not having copies of > those 2 lines in /boot/loader.conf (where they will > not work). >=20 >> --More--(END) >>=20 >> However, the problem emerged well after the changes above were made. >>=20 >>=20 >> A running diary of experiments is at >> http://www.zefox.net/~fbsd/rpi2/crashes/20230514/armv7hang >=20 > There you report reducing the swap space partition size. > Were you getting the message about the swap possibly being > mistuned prior to that? >=20 > For 1 GiByte of RAM 3647M looks to me to likely be a little > below where that message about mistuning shows up. If you > were not getting the message, the size should have been > fine. >=20 > In other words, I expect it is appropriate to put back > the original size (or some approximation of it that > avoids the message about possibly being mistuned). >=20 >=20 > Everything that you reported looks to me to be consistent > with some kernel stacks having been swapped out for some > processes/threads that would otherwise be involved in > interactive I/O activity. >=20 Just adding an FYI about: load-time-Tunable and Writable vs. load-time-Tunable (spanning both writable and read-only ones) vs. Writable (spanning both tunable and not) and loader.conf vs. sysctl.conf appropriateness: # sysctl -aTW | wc # ( all: either loader.conf or sysctl.conf ) 431 860 12410 # sysctl -aT | wc # ( 617-431: just loader.conf ) 617 1231 17343 # sysctl -aW | wc # ( 1415-431: just sysctl.conf ) 1415 2821 42158 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6FDA155-C0CE-4BE6-9145-FB1038290326>