On Wed, Aug 20, 2025 at 11:22:59AM +0200, Michael van Elst wrote: > On Wed, Aug 20, 2025 at 09:26:38AM +0200, Christof Meerwald wrote: > > 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): > > > Does that help? What should I be looking for? > > > In ddb the command "show all tstiles" reports all lwps waiting for locks > and what lwp is holding the lock. It should tell you the process > that causes this (unless its a longer chain of dependencies...).
So the lighttpd process (that was the first one that got into tstiles) is waiting for ffffdadd0c6dc500 and that's ioflush waiting in biowait: db(0)> bt/a ffffdadd0c6dc500 trace: pid 0 lid 195 at 0xffff8981544e0d60 sleepq_block() at netbsd:sleepq_block+0x13a cv_wait() at netbsd:cv_wait+0xb7 biowait() at netbsd:biowait+0x42 wapbl_buffered_flush() at netbsd:wapbl_buffered_flush+0xa2 wapbl_write_commit() at netbsd:wapbl_write_commit+0x28 wapbl_flush() at netbsd:wapbl_flush+0x552 ffs_sync() at netbsd:ffs_sync+0x176 VFS_SYNC() at netbsd:VFS_SYNC+0x22 sched_sync() at netbsd:sched_sync+0x90 db(0)> Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
