[DragonFlyBSD - Bug #3421] (New) Thread stuck in vmiopg randomly.

[arcade@b1t.name]

Задача #3421 була додана arcade at b1t.name.

----------------------------------------
Bug #3421: Thread stuck in vmiopg randomly.
http://bugs.dragonflybsd.org/issues/3421

* Автор: arcade at b1t.name
* Статус: New
* Пріоритет: Normal
* Версія: 6.6
* Початок: 2026-09-15
----------------------------------------
Might be related to #3392.

I got some weird process hangs for a long time, with last crypto upgrade they became hard, and easily repeatable. Previously it was mostly Telegram doing parallel disk IO. Currently maul -j16 buildworld is a way to trigger, though sometimes any ocassional process can borg. When we have a tainted process everything else continue to work, only one process is stuck. Sometimes another process can stuck too.

I can try taking testing further, probably rebuilding kernel with KTR if that helps…

AI slop incoming (muse spark 1.3):
---
Subject: Unkillable processes stuck in vmiopg/vmpfw under parallel build on HAMMER2: leaked busy page, no I/O in flight

Environment: DragonFly 6.5-DEVELOPMENT, reproduced on 9b3eb087a6 (Apr 2026) and 4bb22ffcf2 (Sep 2026, current master). Notebook, 16 CPUs, 32 GB RAM, NVMe. Root on dm-crypt AES-XTS (AESNI) + HAMMER2, swap also encrypted. No KDB/DDB custom config at first; debugger present for later captures.

Reproducer: make -j16 buildworld-class load (buildincludes, libc). Single leaf process (observed: make, as, cc1) wedges in uninterruptible sleep; parents sit in wait; rest of the system stays alive with gigabytes free and zero swap use. kill -9 does not kill it. Sometimes recovers on its own, usually needs reboot. Lower -j reduces frequency.

DDB traces (two separate hangs):
1. sys_read → hammer2_read_file → cluster_readx → getblk → getnewbuf → vfs_vmio_release → vm_page_busy_wait → tsleep(vmiopg), faulting file read (e.g. .depend).
2. sys_write → hammer2_write_file → breadnx → getblk → getnewbuf → vfs_vmio_release → vm_page_busy_wait, writer (as writing .o).
Third hang: cc1 in vmpfw while a h2xop-ROOT worker thread sits in vmiopg permanently.

Ruled out: disk/dm-crypto layers are healthy — dd through /dev/mapper/root gives 321 MB/s during the hang, iostat shows zero activity on both rootd0 and nvme0, both mpipe_dm_crypt threads idle in wait, all h2xop threads idle, dmesg has no dm/HAMMER2 errors, show tokens shows no token deadlock. Read-flood through the same dm device does not unstick the waiter. No thread in the system holds the page: waiter waits on a PG_BUSY page with no I/O in flight and no owner — looks like a leaked busy bit in the buffer-cache page recycling path (getnewbuf reusing a buffer whose backing page never gets unbusied).

Side issue: entering DDB and running ps hard-rebooted the machine once (no dump captured). trace <thread_addr> and show tokens worked fine.

Happy to re-capture with KTR or test patches; KDB-capable kernel available.
---

---Файли--------------------------------
photo_2026-09-15_13-26-54.jpg (322 КБ)
photo_2026-09-15_13-26-49.jpg (342 КБ)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account