From nobody Fri Nov 07 04:15:49 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 4d2m2d20hTz6GKhd for ; Fri, 07 Nov 2025 04:16:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4d2m2c63C0z3KV0 for ; Fri, 07 Nov 2025 04:16:08 +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=1762488962; bh=Wn4Q8VzepRBxVtUpQuu6lxI0+k5BBGkNfS14Z178FfA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Vm3HANt3gFNkahWjJA2UJ8ztzwifkl62CwS6OJgXJpD3nu3+K2Ox6fnD69paLGO1MLtrASjCYFmTIfDVvL/sNk337wUCFznheRQLkLyHnk4dSyt0JdZw/QjJXVjFMZmQ84Ihvzm6HDZTB2a8dyKVeteOeu/vZlNP3+2UtPXO7obD2HXbcEhMrZ4XYqaddiL6hqXnG5hvulhnEsMFPe/KaqhuzJl6cjl49wRWfJZqE9AagDAxi8rniPAZ72+uqtP5D96F+6lPso6+Ul4ISo6Fq2suv0mA4MnRmj4nIaXBr+xM4taw9s4aYj4QiZdg7aSYJh9p0FQfAqa8uGGtHbpwAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762488962; bh=x+HdkL9mkDO8bTRnzsLLbPYYHrklTUEKOPJZEorH4dB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EDga9UZ+4olu21OMFxntE5dkKIpkGVO83QmhhMCpahFkXDK7y1Zd5bUGfmKsaDLUww+fT7FjoB9jhsGBF0Db+IfsXVWU0Yhh++R3sPdBIpWbbebjs1I5iJNFaa43OK02iKP5+wDYWLGxzYF+6ilLnkCt/kOtxbp6DBa8tj3Bu9+Ssg9FrCE1y/Cb8VbxpBTPHHUSr5aQMWWz32FFu+eCYIC2bTdFHkOnSZpFGfgQAJx+TL4No04W5tiiy9OPzLJ//++0kCEqi9mr5vRUlMEjQjCcPuRRj63RegcE+kYQ43c0xBk/mPcOJkIFT3J56Os7eyTNkAkzss46Z4n0kuyP8A== X-YMail-OSG: xmKlmrMVM1kv520QtDz5KDMOvw6JSB4H044RUkVYJ_uFn6FGzWo71YUmareQajc ANupoqku2rg5yQgZPIVfbBVZ5iu7FWQyxpp2yKxOwJNbNlaIhlilcaONW1zR4pCjRziMTbhkKnU9 Myu7TZsf4AKvTAba1524YCsuk8TY2lms1Zn9LIDa_xXb96lSB2gv4W7HYeGgIlT34QyyAYcsMGS. _Hc22IciofggUe_GOrM8qpWrAhPm1kJObqWET7NT_YvbcdZk5Vd2ypaDJsgVleCrls7q5E0pRQlR xTjnd.5jJe.HjcNdBc1NoiDZVdHZlkqzMBIPUjA1qXcJAvuGXxUjXu1TC7VN6H5K1dkpmivzR6UE 3cmgBu7x_XmCXc1zoAiBL6UHhXdA8D0LAzAXoZof1Et9SY43zZu0ZmQ_FC1gE_.QM21FYAMbI6bV Nq8aJYP6ktQizd.y_rACS_9.EZmDqLEdvvcCbo_U6861BA.c44bt3oFPUThMD123tdB7eBYa7Kah _hN3Gqk8f5EQD8VABTdYVBWx.184ioqYHo5iTtmXdCLXuGV3BcYdNbH_WrfoukhLOwX5UAWGYSQC sTiGvhyQd7mr1Ke87MJhe95TFRrkDtmzgkVLo8_d5hw8.2gRafP6Czk56MfJ12Eu1mssuOv85QKd fbuQspl1pINubx1ZEpS1xFgL48j4I21gl431TNcY6_yKMc5C9iQIZVqnNkkYTSVEGSYqYbHtsQHn WwQuUz59DQJu6TTYWdnhghMtAaopyQsbtC6hCrQ9vXYf4p59yAIZ7e.N9IrgK3oSXYqpFTpjVT_N wv1mZzlE2UT_k7u2qF35jLsA4xmWf.Xm0ya7EAW_nAT5sp0TCUyO3WR9WcXUq_L3f9PIkbhRZDZe _g6fWclWMvIYxNW72NykQ_AOgjpNily8VjjZtMcaRUwme3rxwEp63fVmriOprpRO46UaPE3Jlhda RnG9DidC7diOJry6C0S5NcrWQwX7p318gnCzMdGd6Kz0tzCHn_waOTOjxyDVYI1ts8678NL0Ce7d zJ.ABndRnBDP5okU0_De.PMWjn5bZrB1OfEBKZeqmtNFVat6C1H4WuyAGFoe0UE6kv5JhRrVnypq 9WizKKkOsuesNnVMge0tOh0Ltez.r2yNGzY2PdywlBXLxMw7LXJEEFmrlZomkSwqeI6E8S2J_LvE CvgAedAb0NNJufURrcOgDZXBNrtj4WSd_YJm4DfQtAZyE4KMcvhW5W1cvIx9WFw_Npmg9aXwhQfg RrOdhNR6EHz9196.9hS5WCZy_N0qdwCO6ny._qV9MgfWq6NHceFoQZnPtvRBc9iryQH.YB0CLMC8 of3HjfiqJlwVrBSUF0JrCqAPy.mJczOb22ev9Gt_8bZ17Aze.RiZ7P9izUIu5YeMgHAWHhfRc6jA GbwvRWBE4.b2Kc2li661i6SEYp6H62SJ8xnTAXabNjczxb2AiGsR_BA8I0LfeaQG.CwsUDko3Q3N pMSXK6_BrhqIRTsCrWOLQeR6CFgQXjiZzyBoKqnJ7lXEPw787N3Rbe709flBQXDg.G_QA3GBXLrz kQqJ2qPTAJWFp1u3a.UPwEp7iDozBqRmBjnJAO8T3fOtj.ZNFx.t7CJ7KWNzwUw.cDvYFX1doBuX hg65Nd1PdMbcG1T021l.f8cTkfbgX3enhaL2AzXI29NwwC5W4zoG49KLrQpKbK2OGIzGmY2Qw.yY w0.ahmNZZCgSsIA1X37gvUljY3K9RgVZjyTXBC6sP_Ud257NoJ7wT.N8qBDGSMFhKhW61qtLMZz4 IkoadSAFxOObIbiPnOvidQL5qNA4kJLmCMi4LzADApgY1lb_Y4gbrCoD2oJHhYraPnV8PfMgj5qh am7U_ssL6OUusKXOd04SESEif9iih6o5IIhTR1fgG6Zt_YLKxDj3w8elYTb1nq_OJccB1HmlWLbN DXqbJDe4hw3NcVk0gtPNDC_8UtDA1nto7siSHU.r6GQZGY.CupV5NV42APcr9.UUtkfpOArrFGxN iEAhdvWUEsiZ32tSrPt_7cXes4QzYrmrrmjIQDyt4uNrbHlHYf7SwBb6_SPrwvPSx7tjiMUd1gR5 xMxWr8YjPj._QFLi9dII4AKUP1NnTdBqrY_Wrke_ziRNV6vpur_Rw9uUt7.Fkpm7a83qEK5v7Vt6 W3A65Mh_WnwVD1ujwIuFc67Fo_PhnhWcsW5kYVs_OelxO16tDvxXtE3ca6HUEifVRtElpmqS9pB2 ZLOCD8SJmOiTn57yy.XtFXdX5AX9xnfp57QnlCL8zbnSMnUSdQE2Sbp6b.xJPIOm4x0xWUiK.OMl XgTeIThYRTg-- X-Sonic-MF: X-Sonic-ID: 14b3a0dd-74f1-439a-8425-bbfddfee899a Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Nov 2025 04:16:02 +0000 Received: by hermes--production-gq1-86c5846576-4bc8b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1c300fcd9bf83b07cf887c93ff2e2f7f; Fri, 07 Nov 2025 04:15:59 +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 20:15:49 -0800 Cc: Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.com> References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> 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: 4d2m2c63C0z3KV0 On Nov 6, 2025, at 18:22, bob prohaska wrote: > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: >> 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. > Maybe a -j1 buildworld could be at least somewhat informative. > Lately none of my Pi2's has made it through buildworld > without hanging silently. If -j1 buildworld completes, > that would be a significant change. The test will take a > week, but the problem has been going on for a year. > >>> >>> 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? > All comms become unresponsive, serial console or ssh. > >> Do you get notices about >> loss of network connections to the RPi2 v1.1 in question? > Sometimes, but not always. Occasionally an ssh session will > become unresponsive and only later report a disconnection. > >> 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. > In some cases the stuck ssh sessions are disconnected only > after reboot completes. In others, it appears to be a matter > of time. Overnight is usually sufficient. > >> 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. >> > In a lot of cases there's been a top session with a timestamp > and swap usage running at the time of the crash. I've not > made careful comparisions. That's the only timestamping at hand. > >> 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. > > Would running the buildworld command under a debugger's control > give any better access to the enter-tilda-control-B sequence on > the serial console? Usually buildworld runs from an ssh session > in the background with top display over it. The enter-tilda-control-B sequence is via the tty driver and kernel. It is not tied to a specific process. > I could run buildworld > under the debugger from the serial console if it makes any difference. > >> >> 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.) > > Sources are all unmodified, so it's whatever -current offers. > I'd expect that to include all three; there's explicit warning > that the witness option is enabled. === Mark Millard marklmi at yahoo.com