:I'm not able to reproduce this at will at the moment. The PR I mention
:has a program which it claims can cause the crash, which I will try
:running. I'll also try tailing various logfiles, including the one which
:caused this crash, which is being written to on the machine that is the
:NFS serve
On Fri, Oct 19, 2001 at 09:51:10PM -0700, Matthew Dillon wrote:
>
> :
> :Unfortunately, the recent patch to vinvalbuf() hasn't solved all of
> :our problems. We had another, different panic today. The process that
> :caused it was a 'tail' of a growing logfile over NFS.
> :
> :I have actually had
:
:Unfortunately, the recent patch to vinvalbuf() hasn't solved all of
:our problems. We had another, different panic today. The process that
:caused it was a 'tail' of a growing logfile over NFS.
:
:I have actually had this problem before, with FreeBSD 3.4, and reported
:it then. I believed this
Unfortunately, the recent patch to vinvalbuf() hasn't solved all of
our problems. We had another, different panic today. The process that
caused it was a 'tail' of a growing logfile over NFS.
I have actually had this problem before, with FreeBSD 3.4, and reported
it then. I believed this PR to be
:@@ -721,9 +721,9 @@
: }
: }
:
:- while (vp->v_numoutput > 0) {
:- vp->v_flag |= VBWAIT;
:- tsleep(&vp->v_numoutput, PVM, "vnvlbv", 0);
:+ if (VOP_GETVOBJECT(vp, &object) == 0) {
:+ while (object->paging_in_progress)
:+
I totally forgot about that one. Your fix looks good, I'll start testing
it.
The bigger picture here is that vinvalbuf() is not typically called
while a vnode is still active. NFS calls it on active vnodes in order
to invalidate the cache when the client detects that the fil
On Tue, Jul 10, 2001 at 11:43:29PM -0700, Matt Dillon wrote:
>
> :Hi,
> :
> :I've just tripped over an obviously long-standing (since about
> :Jan. 1998) bug in vinvalbuf while looking into PR kern/26224. The
> :problematic code looks like (on -CURRENT):
> :
> : /*
> : * Destroy the copy
:Hi,
:
:I've just tripped over an obviously long-standing (since about
:Jan. 1998) bug in vinvalbuf while looking into PR kern/26224. The
:problematic code looks like (on -CURRENT):
:
: /*
:* Destroy the copy in the VM cache, too.
:*/
: mtx_lock(&vp->v_interlock);
:
8 matches
Mail list logo
