Re: Bug#328135: kernel-image-2.6.11-1-686-smp: nfs reading process stuck in disk wait

[Horms]

On Thu, Sep 15, 2005 at 09:32:47AM +0100, Trond Myklebust wrote:
> on den 14.09.2005 Klokka 21:10 (-0400) skreiv Marc Horowitz:
> > Trond Myklebust <trond.myklebust@xxxxxxxxxx> writes:
> > 
> > >> on den 14.09.2005 Klokka 11:51 (+0900) skreiv Horms:
> > >> > Hi Marc,
> > >> > 
> > >> > would is be possible to test linux-image-2.6.12-1-686-smp from 
> > >> > unstable to see if this problem persists? I am CCing the NFS
> > >> > maintainer and LKML as this looks reasonably nasty and they
> > >> > may be interested in looking into it.
> > >> > 
> > >> 
> > >> I doubt this has anything to do with NFS. We should no longer have a
> > >> sync_page VFS method in the 2.6 kernels. What other filesystems is the
> > >> user running?
> > 
> > In the stack trace I sent, from a running 2.6.11 kernel, vfs_read
> > appears to be the vfs method, not sync_page.  sync_page is called much
> > deeper in the stack trace.
> 
> So? It is clearly the call to sync_page that is Oopsing.
> 
> The NFS call is just trying to lock a page that appears to be owned by
> someone else. That triggers a call to that filesystem's sync_page, which
> then goes on to do a page allocation, which again Oopses.

I take it from your initial remarks that the use of sync_page()
in the VSF has changed recently. And in any case, it would
be worth testing 2.6.12 or 2.6.13 before investigating any further
as in your oppinion the problem is not NFS related, but related
to somthing that NFS coincidently triggers (but could just as
easily triggered by anything else).

-- 
Horms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/