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

On 1/16/26 13:19, bob prohaska wrote:
> 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 % 

Nothing about the lock order reversal back-traces looks likely to be
amrv7 specific to me. You might want to post a report to freebsd-current@ .

> 
> 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....
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com