=== DF-0834 FIXED-KERNEL RUN (single-fix kernel #1) ===
Kernel: DragonFly 6.5-DEVELOPMENT #1: Sat Jul 11 07:14:11 UTC 2026
Fix:    UFS_CHECKPATH_MAXDEPTH=64 depth cap in ufs_checkpath
        (sys/vfs/ufs/ufs_lookup.c — see fix.diff)
sha256: 5f931d6b7ec6d2265202a512280ccc89d43402a39168bf41014893dc2419849a

Run #1 (identical image + trigger as baseline):
=== DF-0834 trigger 07:20:55 ===
uname: DragonFly 6.5-DEVELOPMENT #1: Sat Jul 11 07:14:11 UTC 2026
vn device: vn4
=== mounted; ls -li ===
total 12
4 drwxr-xr-x  2 root  wheel  512 Jul 11 07:20 A
5 drwxr-xr-x  2 root  wheel  512 Jul 11 07:20 B
3 drwxr-xr-x  2 root  wheel  512 Jul 11 07:20 S
=== launching mv (background) ===
mv pid=920 at 07:20:55
--- ps @+1s ---
PID STAT        TIME UCOMM
--- ps @+2s through +5s ---
PID STAT        TIME UCOMM
--- after kill -9 ---
mv exited:
mv: rename S to A/S_moved: Not a directory
=== trigger done 07:21:01 ===

Run #2 (determinism):
=== DF-0834 trigger 07:21:20 ===
( identical result )
mv: rename S to A/S_moved: Not a directory
=== trigger done 07:21:26 ===

Regression test (normal rename on acyclic UFS tree):
NORMAL_RENAME_RC=0 (0 = success, no regression)

=== analysis ===
On the fixed kernel, ufs_checkpath's depth cap (UFS_CHECKPATH_MAXDEPTH=64)
trips after 64 iterations of the A<->B cycle and returns ENOTDIR, which
rename(2)/mv propagates as "Not a directory". The rename returns in <1 second.
The mv process is never stuck (ps at +1s already shows no matching PID — it
already exited). The guest stays fully responsive.

Before/after contrast:
  unpatched #0: rename hangs forever -> entire guest wedges (ssh dies, SIGKILL
                cannot stop the kernel thread, serial shows login prompt with
                no panic). Hard reset required.
  fixed #1:     rename returns ENOTDIR in <1s. Guest healthy. No regression
                on normal directory renames.