https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292543
Bug ID: 292543
Summary: Arm v7 RPi2 -current unresponsive to debugger escape
during buildworld
Product: Base System
Version: 16.0-CURRENT
Hardware: arm
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: arm
Assignee: [email protected]
Reporter: [email protected]
From time to time buildworld on Raspberry Pi2 (armv7) hosts stops silently with
no response to serial console input, including tilda-enter-control-B. The only
resolution has been to power cycle the Pi2, which seems to recover without
trouble.
In the most recent case the host was running
FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #14
n282273-8d9a5d44b155: Thu Jan 15 01:24:35 PST 2026
[email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600004
1600004
It was possible to rule out failures in the serial console hookup, consisting
of ssh to a freebsd host holding an FT232 usb-serial bridge wired to the
internal
serial console pins (GPIO 8 and 10) of the failing Pi2 by first restarting tip,
then the ssh session used to launch tip and power-cycling the FT232 bridge.
A ping of the stuck Pi2 reported "host is down".
After power cycling the Pi2 came back up and buildworld was restarted. After
some
minutes a tail on /var/log messages reported:
....
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 %
Might anything in this message give a hint about why the machine locked up?
Note that background fsck was running and the warning completed in that time.
Also note that the very first timestamp is _later_ than the next timestamp,
which seems odd.
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.