On Wed, Aug 20, 2025 at 06:30:27AM -0000, Michael van Elst wrote:
> cme...@cmeerw.org (Christof Meerwald) writes:
>
> >What I am seeing is that processes end up waiting in "tstile" (just
> >showing those).
> Unfortunately "tstile" doesn't tell much. The process is waiting
> on some mutex that is held by some other process. The process
> holding the mutex is either busy or waits itself for something
> else. You need find this process that stalls all the others.
BTW, got some backtraces:
This is the lighttpd process (the first one that got stuck in tstile):
db{0}> trace/t Ot1066
trace: pid 1066 lid 1066 at 0xffff89815475bbe0
sleepq_block() at netbsd:sleepq_block+0x13a
turnstile_block() at netbsd: turnstile_block+0x2bf
rw_vector_enter() at netbsd:rw_vector_enter+0x14b
wapbl_begin() at netbsd:wapbl_begin+0x6a
ffs write() at netbsd:ffs_write+0xf4
VOP_WRITE() at netbsd: VOP_WRITE+0xаб
vn_write() at netbsd:vn_write+0x10e
dof i lewrite() at netbsd:dof i lewrite+0x80
sys_write() at netbsd:sys_write+0x49
syscall() at netbsd:syscall+0x1fc
--- syscall (number 4)
netbsd:syscall+0x1fc:
Others like newsyslog are stuck here:
db{0}> trace/t 0t16069
trace: pid 16069 lid 16069 at 0xffff898154cdaa90
sleepq_block() at netbsd:sleepq_block+0x13a
turnstile block() at netbsd: turnstile_block+0x2bf
rw_vector_enter() at netbsd:rw_vector_enter+0x14b
genfs_lock() at netbsd:genfs_lock+0x80
VOP_LOCK() at netbsd:VOP_LOCK+0xb3
vn_lock() at netbsd:vn_lock+0x22
namei_tryemulroot.constprop.0() at
netbsd:namei_tryemulroot.constprop.0+0xc5d
namei() at netbsd:name i +0x43
do_sys_statat() at netbsd:do_sys_statat+0x102
sys_stat50() at netbsd:sys__stat50+0x28
syscall() at netbsd:syscall+0x1fc
--- syscall (number 439) ---
netbsd:syscall+0x1fc:
Does that help? What should I be looking for?
Christof
--
https://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
