From nobody Sun May 14 19:31:29 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QKCLC2VGPz4C2pL for ; Sun, 14 May 2023 19:31:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKCLB6x5Wz3hKr for ; Sun, 14 May 2023 19:31:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684092705; bh=KPbRTu8t/kb8WTg1Sp/Zraf4VcUPU69VvXHmbQx8Rqs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Oqjv8AiM65iWmvBrm4lRUgygcIjgjmt9lqBRLbDgO2vHqEQ8t1mOcmxyd3V/de/5juP7rnqTFwuFsMvIl6zRSxlKY7S7QejlAKXaCT/w5n/oQHwvZ2qgApwk0ZdLEx+3C4RmaOZ6bPA+oPRCOIiI9KPTayvyMTpuXhl6G2cdsqovAPGU3kNWKMS9prOi40GmjcNktEB+uypxWGJLIUHR9UsbopG8E5uvD3X/2/scXNtzF9+8KfOpBiOvnOC9Q9JQ86uRtol4uuy7m4lf5gEAXz+FbwGmuzcaVEdRTQyoqeFvyjg7C4tNGgjst945L9NHoKmqS0idXBk9SFZ9Rp2BKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684092705; bh=zBa9cGaWrXNKFjdQoAqv3fMEWqeZFb/XHKUhpqTda+1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qOI2kOWKcwBGCHRVSXL/AQXdqksgFeX5sgb8ERlB1gyb3fCO6mbFxp4RnBHQS9Wrk1lzxgJpUWg5FNTc1yHy9KzURV1QRPMKOxkQ9EwzlDXhXgL+t9LthrnWxH1Zecsw5vOc32x3B/S22/bi93m23SuPU8PNaxGnbXdAsgdlevtTsJxDeV3jt4LFAU2wgMIhx3c8L7K+bvIFsxiA0Tje7WbFpirjg2b3P5QoZJ4zE/t9K+qYohGkCx+otFX7HFqyEbQtaQpUPzL3USwo2xBpGYtj+OX0PrHBduyqU17XFwCC/FgaY+i4e6L2+ibTWRttwlep8uAlzIKFaqA/jDtOOg== X-YMail-OSG: hGZx5T4VM1nPUOcB74j5CB0LVtO.GHG59S7ifJUtkttoGiiccyNtJRnuCIRuBuE g2ssMYfd46y4DXrSV7X2WwAmm0ZCF4a1wKZsFVo8OaaqdFIz7b9Udi1KAMSjqmCDvW6nOZRZxF6o 9nX26YI2_xoYl5dcSQlGkXHG8KxB8BntBmxmEDrXSJDaequ5ZslhTuVz0fliluODT7tFehcbv9tC nyCPsspu5lwYoajYhbUlEwKoFc.Yv_rWmAunzQHFKlk9IV83dFytNjigzGC_dXzK8MK.lvJ1.lt2 WdD.OqmxScSyfSZ76umBtUGpQ.S79wTXuhxmZD4DvO6mpHi1.3kRe5FgtZHD2FE3sB6rGQg5J_Lm rVlSPcqUtAU1MXnuKO07A_voJAmsI8AHP_LP62.4JkDa5nUpn4.C_KgTJpQ1v9K7tiGORgu.apLR FN.plv4y99C_HUw.ey.gZw2bE7bhzgpvjt3hbOEkfx8re_1ytPaaD_UGuHkdSY5YWv_nfbcIteJZ OjCgFv_PmPaaV6rpDrpB_tFsEvUbEGBobdTOcGj2R4eF8ZI7_Nyp98KphMAnYJq.sTHgrYYk6Paz mZPIrObBwaO5uYnAOVL14OpNbTUn.skDSBs8qdP3Nz83kdCQHpid5TR4vfTe3VnBqPzl4waQSBKJ RDyxapWfNKzm1LugIc5V6_FPePk_vVP2cqeXtUSNmauV95la0YCdyS9cVoc6EhYgZRe6Y7mfiO_S koupIdlX4NiGB.VSoSOt4J8CfnCLvbnJq6kd8WUkXp935qFTtPDtPZwWTicHmqhVK5xZ08il.oxL jhQRmpx27EDpJrVGLzhfPyb.zVtJkZogOFs5qgyh9RNft1o3TJBzUYLiDxDdc.q_fGi5EY9iJz21 osK8uTp2lh31C.zwHCewf3G7PsP.wmHSvqBpJ_fJeESncAGJmA3nlkb6MPRn0XQdHNf3pEPDHBTc NL8X4trflrvHcS_hQp_h2yys.UJE3qRA33xVvxzXsJliSgWbp.pDD7iWzphHZIuBIhG7jzXkoCNl K6.fuoj.2DL9x0Ee4ys8Tp5.RuAAt1XGDlNG1v1DTDqkNNwacZlXFrFlh.I6XeieLYzgSUFKvQIR lJN7UL6zXgTktUYn4dRw5ktEEi4FxHBp0RwnYFry2Z_T9Q4e7WTwEapE3OUCEImu79TAvy4SgRaK vOzLIkaSDqTsU6B9x9GUcEA7S77sSmCXtDbOBup.gwRopK0SWL3.Q5N02mApsH9NxT_WW8nQYaHS FNyROgKcg4VK.vfkydOsQv8ZpWnSFw2QvFNAMzqK9kokoExTFb0MLMpSB79khOLtKZFjID4keWXj F0ELYgobRz91ZYh3Z3ytKeWDD9F5ZtiO.xlvALmpFp5EzAB5khOjKgZ1uNDImlaAU6bT3BHto3C1 8s2qWeGdlbpsm7mznj4QoE8pET5EJzHOoORIL1dPI.ZqgJOEecuoRou2bdoB64h.VGUSM1HrbEAu KlQrmJ4JXJmUrjFusRQ_.1rPtuhzbGtQk.UstewFz7FIs40WFqYVKCAWVf3I7rct9_uPb5Oxrnjp Zq05ntbwLKkU5HuRYbOyTdLTLYz8OckI0wtICkat3WsrCTf6McWl0_HFBvFVMCadYih74S5WSfVr SQO.fMEAYFkx5TiY6agZbBKdEDu4vYGvXDL6Prn4yFLDrzSKlqEz7xs38BHc5Om5Macs9nIepSsv W8K522hyHCwNNQriIW8dZ7mLLf3u_nE0k6n7UEz2nxPFTsYP6WoCWyIjesJ36PizqSppaTCWaGqX G0GGA983ZIce0zm4_qvv6tq2O1xlGrQZijqznuAMRPI4_ZdWKUquVjGSzgr9Jb1_5Ypt09xhX8fc TimfOyAg1tc5GlKU8zyWA0EAL74hcnEEo8UOENThrsdk0lBtI2_WyHWp5fpHTjZ6bpusChoP3CpL zyn3Rz4l2vu4L7T7L0tYGRtsVE0GBawnjcBn8axX3SVcbnZHDvBSCykj_0faSAczFWfF40aos2Wt 8AX3s6UV8EYyzz_8fnnuDWYVklJVVZSLVIA.2SsyGLjD.kdgn__1HKqiJGWiz5BaF1.GkOjZsH3j atDnyzrIqVkwiTwR3aoTmlFG4akQl38uVlr1ya6vVqyETZrkZNhu.xsDfOM.SoYFPcIOPHHzRQlw xpPJBAik5ohovZpwdfcOfcimVMkjQTurGMkbxhcaM8.c99E2zsOG.czUoEgJVq46oWIK7qZBzujT A.nbaffA4_phTh1wDWa8wgB8YEJ4lA.M7RlRP_xAoSNHXyUCggF5jvfSOA3A_gJac.wl.ovWjQvc n0w-- X-Sonic-MF: X-Sonic-ID: cce792f0-da2b-49a4-aa10-314b1d5b1cd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 May 2023 19:31:45 +0000 Received: by hermes--production-gq1-6db989bfb-ppvpv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6439c6f27407af951b0a5fb589b351b8; Sun, 14 May 2023 19:31:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current From: Mark Millard In-Reply-To: Date: Sun, 14 May 2023 12:31:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> References: To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QKCLB6x5Wz3hKr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 14, 2023, at 08:36, bob prohaska 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