From nobody Thu Nov 6 18:00:19 2025 X-Original-To: freebsd-current@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 4d2VNV5mxWz65DW9 for ; Thu, 06 Nov 2025 18:00:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4d2VNV4cFBz3bDK for ; Thu, 06 Nov 2025 18:00:42 +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=1762452036; bh=EbkyDgVmKgDCoPLIHvDdsGOI1Ksy1frMwxImvieyd6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rg3PkkZpl0xRsQDuYvNGXCNhikVwmwdoMgk87E+y2+CBFf/LnWe/Bh8Bf0/T6HUCcduXgnVKsLMpUAoJlZZ6JKGVJibeORiNS2AyaJ77E3R5PtmnsaZHiFt5ASzyynK80rT1jkY+tGR1VznTb8hc5xc6BkZHegvgewx/Ji6g1cMx5poeLCRdn6iYHTpSdeVGO24hUygWuLEwaccXQF/Eo9iNpaOx4bPkbftdVzRvtUem7QxoWMa1M4z+iH/29N2H7TIVs2wjDGIbZjo6b4wTwRx8K4DuyCUSql6f96ICSftN48JlNkJtnZ6aenuR9fMzcI+aNxmS0oYqLGQ9BRCa7g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762452036; bh=UKzB6kUBq45Mn2G5wgoSDh/IiA4UqXAsixhC/jGnfEg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VOgML2Miy/+sG+PS+shjFqp77k5pK3LJuL8Un1QX385370Hyaa5j4JQmlN5udjdN74Z+ds6rqByLUAW8pwBL5fUbmMaLgv27Pc5yu4MlioJ74MukAS5KjfEnRs84iMvdHO+0LuZkt/baFg2M2wfCwcIZVj42s5UaN0wq5fxTVTVr3CIKYKLj3wLcd5uEi3INiirYly0H3znPTTTT1iytoc0esINlKzRpWsN0U1lPS5JRBk7IrFT8nwYsn1RDSybGHnO9N6j35DNmggW2dzktWhj/jrf58JdHzLDd64D4JPUQADs37MwtQIjCGRU7RGyvX+F/0FAM8QMFJq1/5+r3fQ== X-YMail-OSG: N3kqNxMVM1kwG9Bkpl42J_1LiDIA8wTh2BKxLBdqvHu_EmSD6j8bJrRmeNisM7i 6YP_0oLuMfH_7zGf_fIaoddu4O7Iww2mqsXKkFbq_FKofiYcRLFcgDQlV3PBJnVGROCLHfJ60bjj 9uSLpgLsZ0Obs6WPrSVpNLNkiFl0mi53izybfSl6RYmm6Ck1C8yjGrPm_yPNFAZvfnQh1ypPuKkP xdVfyCWtGQTHjYfzdQZoNDTNFf0my58GK3BjD3rnF19HSu5E9PR.sfzc_KBYknMs7ImfjnZe8RMC MLjgXgOqUPCr1qFNLefqb6IgvExw4HtCQdc6d2aD5nRFDsPGSbFnZTDaRt1.6kKYINiLXPFT02T5 PT6_VLpMdlmwIwjK_OqfTAa1zPpamG1D7rHCzPPBoqXVlaRuZXW7k3fcgTIsbSesWHZrACfWowPY NAlAPaOqGwMNnXwB7xXi37_AxE_KAFPSeHDjCwAxRqQZ5bU72341MxvDZc90LVdaigZexyvDMCkI VM0hROxKybormWRpGf61.qHys3hFegqVzif8IHL26OTRbPSeMcrXUDRx8MTsifZQAm_cilixoq8p Ue.KXkq2XtT1Ldy53kQn4A8omeon4E4KP2ANvv074dfLm.dgH42a4tUJY7D4ZWkKz_FNIQCwfTes 42pkrmAptKv9vqWIOZjkO4qbwV8FK.WQiU4E4afFggUFSd5H0kwFUYzMqv3A3zt.SiAVSRjz.DBB WZ0gpXnKPyjMWSzothtwHeUnKS2pTlybAWg5KawjGNghMdDiUMe07Xyakbn_opknoM3qXdo5Mhvy Ol._6CxfsSgUitq52UpQB2Fks3FY17eszyVXrd5aDLSxgYqM7U5iCU43R.hnKsdyruveOoeXcF4u 42YSUuJeKyj02DAMM02s5h02EFL7T56iqZX0hk2r3eK8NZ1lO1FP7QtG2DJuF3mKLn2106SKeNLW kp8N9KqSrQZObL0lF7qyrGIKh0wTDbEt2MZpl1sR5DmoRN3eeqcveeKuTnN2lXNhq9T3zNlnBqzu BRqM0diZNWSlkGGOYfXal4xh21W3AlA1SIwtgL2YsUNmwvZse8uK0r4w00dWtx98q3Dt5E4JxBVY LYnlENzWw8cmy1tZk_xzlS7wRau_hbFTBP9YksSJ4nrkacnI662fjE2mhcvESIsaTgDZITT6s3ht 6Pd4G82RLzN659LUVwV.w4JQbBVvtPhTf6mWbwRdWMD0CLySTxKbb9.M2Y58EUDgrPVWNT23nFYH SmGnA6IY4wt9uuabCSypGu55uaUSdGNuYrP7Zj7qBlSzB1MTN7oL1UgdpOqbLtlf8JtWCHH_zj61 T22uVIOjvGLDyWa3DGqA7ywbz6zTTmhPXlBdT4VyDYBc9YPxUpM4gxM0RwHMKbaxzYAC9f.5C2q2 0ILdTy4qvBDeY.kuK7f4dNZzMZCFgICZlN8p3rYGOPxIrF_0oWJ.7GnGD30pbHAn0tv5sPjeXcIp _xkeDz01tG1ypjVsndI1GDU5hpwthp_nH6pQepkT763R24eo6H0jTR37a_b7e8lEjD6lxYcOVE.n msO4apYAUDlqcMYHOH1Iaj5GyrO_0FFOtiz_9i32f4.B06P3vHPoH..pXHvKLJW_u3B7.7mwLhfW 2vLujrwMXE064eCBYaVcszK2kPX8QXc8p115joHYn1PEXo1oJCEJclOsGKdP1ZsI8hz0BrsRruww InHmb6HCm1EEJW2GUT8fhSjISah23Q96MVq8PV00uIp2H4ju9Y.CxrEHJ3qzmi6gYaKda_YqNIl8 YAWI1_MEppheSeWd8pUzEtVdz9kW0keoxFgmBJtG84o_VOAOHBq5yBNaralQItjV2p5jzz74Kinr TacEWv_r_EbjemJTIYRDHwFN2OITDHXxpnqOryHeDR5poInyhpCytBN9GSax2D7vcqbBlST9dfXp AALBaQeP8eo1Bdfed3U74iBV3jub.qzBb.45kRbYotHXeyC3D87HX_A9wsNoOcx29qM5PsCEabWL mUa8Y8._5CfR5ejvuB_AX7tyqWrVg8WY2Oo_f5VwrMgUMe4mbOe8oSyBTyhELEIEKcZiG1ijIgg_ PNVh0qLY16jgA1BqTW0mqADoAF5WoAFnkWCWQvpxzmcAa5hlUqBozetaXtRjxz57GG5sdQ6oRXA1 C_SznuJ25g1O8HKn_QPU79M2pekrZUMjmKcYb1mKkJIvwg9E.JD4T9HCrWRtEJgdHY0QRFa2f..p VvQ9XnXlcPSTWpOuh3rilq.q5Rd7PSGSKD6rQ0Do2DVxwaElACEEn23npXn9Rmc1gfe.Da49cnJZ sI_riHA-- X-Sonic-MF: X-Sonic-ID: daa68a2e-b29c-4424-97c8-2e338f1febdc Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Nov 2025 18:00:36 +0000 Received: by hermes--production-gq1-86c5846576-ngzfg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b0b32acb5119c0440b86697074cafc62; Thu, 06 Nov 2025 18:00:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard In-Reply-To: Date: Thu, 6 Nov 2025 10:00:19 -0800 Cc: Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> References: <475995705.6919.1762440301455@localhost> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) 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-Rspamd-Queue-Id: 4d2VNV4cFBz3bDK On Nov 6, 2025, at 08:38, bob prohaska wrote: > On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: >> Hi, >> >> To me it sounds like your machine is overwhelmed by swapping. >> >> Try -j1 buildworld. > > In most cases of stoppage the swap use is low, 50 MB or sometimes less. > Up to about 6-700MB the machines slow their progress, but keep going and > there are no complaints on the console about swap taking too long or > insufficient. If there's a connection to swap use, it isn't obvious. > > It seems to be related more to hours of runtime than swap use. > > More to the point of my question, if the machine is swap-bound, > shouldn't the debugger escape still work? Are your descriptions of the lack of gaining control for use of the serial console? Do you also have ssh or such? Do all such see hangs as hung-up/crashed? Do you get notices about loss of network connections to the RPi2 v1.1 in question? Do any of those happen automatically? If so, the time of such a message could put a bound on when the RPi2 v1.1 hang-up/deadlocked/crashed, the message about failing communication having occurred after the problem starts on the RPi2 v1.1. I'll note that your prior reporting of the end-of-log content gives evidence of things that completed, including being flushed to the disk. But there likely was more that was not flushed to the disk, some of which may have otherwise completed. Also, what was actually active at the time of the potential deadlock (or other form of crash) is unlikely to show in the logs with such a known status. The I/O tries to keep the file system media content from being corrupted, but not necessarily that it is up to date. (Fully attempting both leads to either a contradiction or horrible performance. UFS has different tradeoffs than ZFS for such issues but the same general goal applies to both. At least that is how I'd summarize it.) Knowing where the logs stop can give some idea what might follow or have been active, but it involves other analysis. I do not know if tail -f reports buffered information vs. only data that makes it to media. It might be that tail -f in an ssh session on the/a log file might report closer to the failure time, showing information that does not make it to the media. That need not be the same as showing the actual failure time: just possibly closer. As for debugger use, there are thousands of processes. If you mean gdb or lldb, there is no uniquely relevant process to attach to and monitor that survives across all the activity. Are your kernel builds debug/invariants/witness builds? Is world a debug build? (I do not mean just having symbols and such as a debug build.) I wonder what the behavior would be for avoiding the resource overhead involved in having and using the debug code. (But, if it does fail, extracting information is normally a problem.) === Mark Millard marklmi at yahoo.com