Date: Sun, 14 May 2023 12:31:29 -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: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> In-Reply-To: <ZGD/8CXbIFtCuiFF@www.zefox.net> References: <ZGD/8CXbIFtCuiFF@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 14, 2023, at 08:36, bob prohaska <fbsd@www.zefox.net> wrote: > 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" (I oroginally had a note here but I think it would just confuse things and not be tied to your problem.) . . . However, I expect that your user process had its kernel stack swapped out. See below. > 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 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.) 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. Those last two lines you have in a file for tunables --but are not tunables: # sysctl -T vm.swap_enabled # sysctl -T vm.swap_idle_enabled #=20 Compared that to the check for the writable category: # sysctl -W vm.swap_enabled vm.swap_enabled: 0 # sysctl -W vm.swap_idle_enabled vm.swap_idle_enabled: 0 #=20 In my environment, I use /etc/sysctl.conf , which is a place appropriate for non-tunable but writable sysctl values: # grep vm.swap_ /etc/sysctl.conf=20 vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 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.) I suggest avoiding confusions by not having copies of those 2 lines in /boot/loader.conf (where they will not work). > --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 There you report reducing the swap space partition size. Were you getting the message about the swap possibly being mistuned prior to that? 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. 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). 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. =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?7758885B-3115-47F0-A453-1C010313D4B8>