> 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
>> [...tstile...]
> I also recall getting the situation when working on perfuse, but it
> was limited to processes operating on the puffs filesystem.
My front-runner theory at the moment is that I've got something like
that, but at some point a process holding a much more widely-used lock
joins
hello. If memory serves correct, this problem was discussed relative
to NetBSD-5 when
Andrew Doran was working on the smp improvements to the kernel. As manu
pointed out, it could
be a result of a number of scenarios. My take away from all the discussion was
that the best
way to find
On Fri, Jul 15, 2022 at 07:46:58PM -0400, Mouse wrote:
> Some time back, I recall seeing people talking on the lists about some
> sort of discouragingly common issue with processes getting stuck in
> tstile waits. (I've tried to scare up the relevant list mail on
> mail-archive.netbsd.org, so far
Some time back, I recall seeing people talking on the lists about some
sort of discouragingly common issue with processes getting stuck in
tstile waits. (I've tried to scare up the relevant list mail on
mail-archive.netbsd.org, so far to no avail.)
I can't recall how long ago that was, nor what
> On 13. Jul 2022, at 20:33, Taylor R Campbell
> wrote:
>
> Generally looks reasonable to me, assuming it passes the atf tests,
> but give hannken@ another few days to review it?
>
> Maybe instead of adding vnode_impl.h to vfs_vnops.c, we can put the
> vn_knote_* in vfs_vnode.c or create a new
