Re: Anyone recall the dreaded tstile issue?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> My take away from all the discussion was that the best way to find
> the problem was to look at all the processes that weren't in tstile
> wait and see what they're doing.

That's what I was trying to do with my looking at "X is tstiled waiting
for Y, who is tstiled waiting for Z, who is..." and looking at the
non-tstiled process(se) at the ends of those chains.

In this particular case there were two, both waiting on puffsrpl.

> It sounds like collecting stack traces on the processes that are in
> puffsrpl wait would be a good start and that might give you a clue as
> to what might be getting stuck.
> [...]
> I'm guessing there's some deadlock between puffs and some of the
> other filesystem code on the system.

My best guess at the moment is that there is a deadlock loop where
something tries to touch the puffs filesystem, the user process forks a
child as part of that operation, and the child gets locked up trying to
access the puffs filesystem.

This shouldn't happen, of course.  The children forked by the puffs
backing process should never go anywhere near the puffs mount point,
and, furthermore, even if one puffs request locks up, the rest of the
filesystem should carry on just fine.  The only way that makes any
sense is if something common to all of puffs, or some such, is locked.

But there are at least two processes waiting on puffsrpl in this latest
hang that have no business anywhere near the puffs mountpoint.  So
there is something I don't understand going on.

Stack traces are a good step, yes; thank you for suggesting them.  I'm
also considering recording (by some means that, like an in-kernel ring
buffer, is dumpable from ddb) every puffs request and response, so if
some request is being slow I can at least find out about it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B