I'll try- lots on plate to do.
There's a lot of iffy stuff with ithreads on alpha. But this theory of yours
doesn't match the situation where I can then still log in and ping, but that
the NFS loopback mount is still hosed.
I went back to building across NFS and that worked mucho better.
>
> :
> :I'm getting these on NFS for loopback.
>
> Can you verify that it's the same as Poul's by breaking into DDB
> and doing a trace ?
>
> I have very little time, but what I think may be going on is that
> current may be exposing a bug in the specfs fsync code related to
> flushing dirty buffers which already have a background bitmap write
> in progress.
>
> I think what is going on is that interrupt threads are not able to
> run in -current, whereas interrupts do run in -stable, and an interrupt
> completing the write on a buffer is what breaks us out of the
> infinite loop. I noticed in Poul's 'ps' output that a number of
> interrupt threads were runnable, but not getting any cpu to run.
>
> The way to test this hypothesis is to give up the cpu for a tick in the
> specfs fsync loop, allowing interrupt threads to run. Maybe do a
> tsleep for hz/10 every 500 iterations or something like that.
> If this fixes the problem, then we have confirmation.
>
> Alternatively someone can work up a simple MARK/SCAN for specfs's fsync,
> ala what we do in FFS's fsync, and try that. I think MARK/SCAN may
> be the ultimate solution but we should home in on the problem before
> tring it out.
>
> -Matt
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
