Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Nov 2025 15:45:01 +0100 (CET)
From:      Ronald Klop <ronald-lists@klop.ws>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Subject:   Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld
Message-ID:  <475995705.6919.1762440301455@localhost>
In-Reply-To: <aQyrBArxXq-JSaqu@www.zefox.net>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
Hi,

To me it sounds like your machine is overwhelmed by swapping.

Try -j1 buildworld.

Regards,
Ronald.

 
Van: bob prohaska <fbsd@www.zefox.net>
Datum: donderdag, 6 november 2025 15:04
Aan: freebsd-arm@freebsd.org
CC: freebsd-current@freebsd.org
Onderwerp: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld
> 
> For roughly the past year I've been seeing buildworld become unresponsive
> compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes
> with no visible memory pressure, other times while swapping. The machine
> uses a USB mechanican hard drive for root and swap.
> 
> Numerous attemps to use enter-tilda-control-B to get into the debugger
> have failed, with absolutely no response. In the most recent case the
> disk activity light was flashing rapidly, a relatively uncommon event.
> The frozen top window showed ~312 MB swap in use, less than half of
> the maximum commonly seen for a -j3 buildworld.
> 
> Looking at the log file after power-cycling it appeared to have last
> updated the previous evening, so it seems unlikely it got stuck on
> a core dump. Reboot was uneventful, with fsck completing successfully.
> Buildworld has been restarted, it'll pick up where it left off.
> 
> The last entries in the buildworld log file were:
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico
> Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico
> 
> No warnings or errors of any kind appear on the serial console, ever.
> 
> Is there some other way to get at debugger services in a case like this?
> I understand it's possible to run programs under debugger "supervision"
> at the time of invocation, but would that provide any extra avenues to
> find out what's going wrong? I think not, but I'd like very much to gather
> some useful information toward a fix.
> 
> Thanks for reading,
> 
> bob prohaska
> 
> 
> 
> 
> 
> 
>  
>  
> 
> 
> 

 
[-- Attachment #2 --]
<html><head></head><body>Hi,<br>
<br>
To me it sounds like your machine is overwhelmed by swapping.<br>
<br>
Try -j1 buildworld.<br>
<br>
Regards,<br>
Ronald.<br>
<br>
&nbsp;
<p><strong>Van:</strong> bob prohaska &lt;fbsd@www.zefox.net&gt;<br>
<strong>Datum:</strong> donderdag, 6 november 2025 15:04<br>
<strong>Aan:</strong> freebsd-arm@freebsd.org<br>
<strong>CC:</strong> freebsd-current@freebsd.org<br>
<strong>Onderwerp:</strong> Arm v7 RPi2 -current unresponsive to debugger escape during buildworld</p>

<blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px">
<div class="MessageRFC822Viewer" id="P">
<div class="TextPlainViewer" id="P.P">For roughly the past year I've been seeing buildworld become unresponsive<br>
compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes<br>
with no visible memory pressure, other times while swapping. The machine<br>
uses a USB mechanican hard drive for root and swap.<br>
<br>
Numerous attemps to use enter-tilda-control-B to get into the debugger<br>
have failed, with absolutely no response. In the most recent case the<br>
disk activity light was flashing rapidly, a relatively uncommon event.<br>
The frozen top window showed ~312 MB swap in use, less than half of<br>
the maximum commonly seen for a -j3 buildworld.<br>
<br>
Looking at the log file after power-cycling it appeared to have last<br>
updated the previous evening, so it seems unlikely it got stuck on<br>
a core dump. Reboot was uneventful, with fsck completing successfully.<br>
Buildworld has been restarted, it'll pick up where it left off.<br>
<br>
The last entries in the buildworld log file were:<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico<br>
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico<br>
<br>
No warnings or errors of any kind appear on the serial console, ever.<br>
<br>
Is there some other way to get at debugger services in a case like this?<br>
I understand it's possible to run programs under debugger "supervision"<br>
at the time of invocation, but would that provide any extra avenues to<br>
find out what's going wrong? I think not, but I'd like very much to gather<br>
some useful information toward a fix.<br>
<br>
Thanks for reading,<br>
<br>
bob prohaska<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
&nbsp;</div>

<hr></div>
</blockquote>
<br>
&nbsp;</body></html>
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?475995705.6919.1762440301455>