Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

On Wed, Jan 14, 2026 at 11:13:06AM -0800, bob prohaska wrote:
> 
> Once again a Pi2B has become unresponsive during buildworld. The top display
> reports in part:
> ....
> last pid: 73771;  load averages:    3.03,    2.90,    2.86                  up 1+22:36:46  07:53:47
> 44 processes:  4 running, 40 sleeping
> CPU: 74.9% user,  0.0% nice,  0.8% system,  0.2% interrupt, 24.1% idle
> Mem: 310M Active, 55M Inact, 7356K Laundry, 175M Wired, 98M Buf, 365M Free
> Swap: 1770M Total, 106M Used, 1664M Free, 5% Inuse
> Jan 13 20:02:04 generic syslogd: last message repeated 1 times
>   PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
> 73771 root          1 141    0   311M   229M CPU2     2   3:27  99.89% c++
> 73767 root          1 141    0   243M   160M CPU1     1   7:51  99.88% c++
> 73747 root          1 141    0   328M   180M CPU3     3  17:27  99.86% c++
> 70665 root          1   0    0  6868K  1712K CPU0     0   6:45   0.73% top
>  3995 ntpd          1   0    0    14M  1700K select   0   1:41   0.06% ntpd
>  3378 root          1   0    0    13M  3372K select   0   0:06   0.02% wpa_supplicant
> 64335 root          1  27
> ....
> There's no visible updating taking place, the timestamp is three hours slow.
> Typing in the console window isn't echoed, issuing q to quit top has no
> effect.
> 
> However, there's an oscilloscope connected to the transmit pin on the
> serial console wiring, and it's getting traffic every two seconds. The
> output is very brief, 20-50 ms.
> 
> Killing and restarting the terminal emulator, called "serial port terminal"
> on the RasPiOS host serving as console, reveals the FreeBSD buildworld is
> still running and generating output. Switching to cu as the terminal emulator
> confirms that the buildworld process is still running and making progress.
> 
> So, the Pi running FreeBSD isn't the problem, at least not now. Other
> instances that didn't involve a direct usb-serial connection from RasPiOS
> to a FreeBSD host and wouldn't respond to the debugger escape used tip to
> make the serial connection between two FreeBSD hosts. I didn't try restarting
> tip. It looks like that's the next test to try.

Another test case emerged, this time over a serial connection between
two FreeBSD hosts. The usb serial adapter was plugged into a Pi4 running
-current (aarch64), connected to the serial console of a Pi2B (armv7) 
also running buildworld on -current (armv7). 

Once again, a top display on the serial console froze and would not respond
to any keyboard input, including enter-tilda-control-B.

Restarting the tip session didn't help, nor did restarting the ssh 
session used to run tip. Finally, ping from another host (also FreeBSD
on the same subnet) reported "host is down". Finally, I power-cycled
the usb-serial adapter, seeing it disconnect and reconnect, but still
the Pi2 didn't respond.

After power-cycling the machine and restarting buildworld a crop of 
what look like errors appeared in /var/log/messages:
....
Jan 16 19:32:07 pelorus kernel: uftdi0: <FTDI USB - Serial, class 0/0, rev 1.10/4.00, addr 4> on usbus0
Jan 16 12:19:35 pelorus su[2207]: bob to root on /dev/pts/0
Jan 16 12:21:53 pelorus kernel: lock order reversal:
Jan 16 12:21:53 pelorus kernel:  1st 0xd733b05c snaplk (snaplk, lockmgr) @ /usr/src/sys/kern/vfs_vnops.c:1244
Jan 16 12:21:53 pelorus kernel:  2nd 0xc5135d40 bufwait (bufwait, lockmgr) @ /usr/src/sys/kern/vfs_bio.c:4071
Jan 16 12:21:53 pelorus kernel: lock order bufwait -> snaplk established at:
Jan 16 12:21:53 pelorus kernel: #0 0xc037fe04 at witness_checkorder+0x320
Jan 16 12:21:53 pelorus kernel: #1 0xc02d7dd8 at lockmgr_xlock_hard+0x68
Jan 16 12:21:53 pelorus kernel: #2 0xc02d884c at __lockmgr_args+0x25c
Jan 16 12:21:53 pelorus kernel: #3 0xc059604c at ffs_copyonwrite+0x1f8
Jan 16 12:21:53 pelorus kernel: #4 0xc05c03bc at ffs_geom_strategy+0x20c
Jan 16 12:21:53 pelorus kernel: #5 0xc05d44dc at ufs_strategy+0xc0
Jan 16 12:21:53 pelorus kernel: #6 0xc06fc550 at VOP_STRATEGY_APV+0x68
Jan 16 12:21:53 pelorus kernel: #7 0xc03d2c14 at bufstrategy+0x4c
Jan 16 12:21:53 pelorus kernel: #8 0xc03d2a10 at bufwrite+0x1f8
Jan 16 12:21:53 pelorus kernel: #9 0xc05c2be8 at ffs_syncvnode+0x4b0
Jan 16 12:21:53 pelorus kernel: #10 0xc05c157c at ffs_fsync+0x20
Jan 16 12:21:53 pelorus kernel: #11 0xc06fab7c at VOP_FSYNC_APV+0x48
Jan 16 12:21:53 pelorus kernel: #12 0xc05d202c at ufs_remove+0x118
Jan 16 12:21:53 pelorus kernel: #13 0xc06fad1c at VOP_REMOVE_APV+0x88
Jan 16 12:21:53 pelorus kernel: #14 0xc04196a8 at kern_funlinkat+0x364
Jan 16 12:21:53 pelorus kernel: #15 0xc041933c at sys_unlink+0x30
Jan 16 12:21:53 pelorus kernel: #16 0xc0e299a4 at $a+0x10
Jan 16 12:21:53 pelorus kernel: #17 0xc064ba08 at swi_handler+0x170
Jan 16 12:21:53 pelorus kernel: lock order snaplk -> bufwait attempted at:
Jan 16 12:21:53 pelorus kernel: #0 0xc03806ac at witness_checkorder+0xbc8
Jan 16 12:21:53 pelorus kernel: #1 0xc02d7dd8 at lockmgr_xlock_hard+0x68
Jan 16 12:21:53 pelorus kernel: #2 0xc02d884c at __lockmgr_args+0x25c
Jan 16 12:21:53 pelorus kernel: #3 0xc03d4c18 at getblkx+0x270
Jan 16 12:21:53 pelorus kernel: #4 0xc03d7c64 at getblk+0x3c
Jan 16 12:21:53 pelorus kernel: #5 0xc05c61f8 at readindir+0x2c
Jan 16 12:21:53 pelorus kernel: #6 0xc05c57e4 at ufs_bmaparray+0x558
Jan 16 12:21:53 pelorus kernel: #7 0xc05c5274 at ufs_bmap+0x6c
Jan 16 12:21:53 pelorus kernel: #8 0xc06fc3b0 at VOP_BMAP_APV+0x60
Jan 16 12:21:53 pelorus kernel: #9 0xc03d515c at getblkx+0x7b4
Jan 16 12:21:53 pelorus kernel: #10 0xc03eb04c at cluster_read+0x128
Jan 16 12:21:53 pelorus kernel: #11 0xc05c09dc at ffs_read+0x2f4
Jan 16 12:21:53 pelorus kernel: #12 0xc06f9f98 at VOP_READ_APV+0x60
Jan 16 12:21:53 pelorus kernel: #13 0xc0428a20 at vn_read+0x2dc
Jan 16 12:21:53 pelorus kernel: #14 0xc04286a4 at vn_io_fault_doio+0x4c
Jan 16 12:21:53 pelorus kernel: #15 0xc0423438 at vn_io_fault1+0x14c
Jan 16 12:21:53 pelorus kernel: #16 0xc0420a10 at vn_io_fault+0x180
Jan 16 12:21:53 pelorus kernel: #17 0xc0385848 at kern_preadv+0xac
Jan 16 12:42:20 pelorus fsck[2165]: /dev/da0s2d: 552172 files, 5213597 used, 229049011 free (203067 frags, 28605743 blocks, 0.1% fragmentation)
bob@pelorus:/usr/src % 

Note that the background fsck process closed out the list, so maybe
the messages were some interaction between make buildworld and background
fsck. I've never seen this before, but neither have I looked.

Buildworld is still running as of 13:06

Thanks for reading,

bob prohaska
ps, the timestamp on the first log message looks impossible....