From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Marc Horowitz <marc@mit.edu>
Cc: Horms <horms@debian.org>,
328135@bugs.debian.org, linux-kernel@vger.kernel.org
Subject: Re: Bug#328135: kernel-image-2.6.11-1-686-smp: nfs reading process stuck in disk wait
Date: Thu, 15 Sep 2005 09:32:47 +0100 [thread overview]
Message-ID: <1126773168.12556.13.camel@lade.trondhjem.org> (raw)
In-Reply-To: <t533bo75e6t.fsf@central-air-conditioning.toybox.cambridge.ma.us>
on den 14.09.2005 Klokka 21:10 (-0400) skreiv Marc Horowitz:
> Trond Myklebust <trond.myklebust@fys.uio.no> 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.
Cheers,
Trond
next prev parent reply other threads:[~2005-09-15 8:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050913194707.8C8C28E6F0@ayer.connecterra.net>
2005-09-14 2:51 ` Horms
2005-09-14 23:58 ` Trond Myklebust
2005-09-15 1:10 ` Marc Horowitz
2005-09-15 8:32 ` Trond Myklebust [this message]
2005-09-15 9:22 ` Horms
2005-09-15 9:44 ` Trond Myklebust
2005-09-15 14:29 ` Marc Horowitz
[not found] <4Mpqc-7h0-23@gated-at.bofh.it>
[not found] ` <4MxnE-1Z7-5@gated-at.bofh.it>
[not found] ` <4MPuc-4iZ-1@gated-at.bofh.it>
[not found] ` <4MQzZ-5PL-9@gated-at.bofh.it>
[not found] ` <4MXrT-7xn-29@gated-at.bofh.it>
[not found] ` <4N34g-7De-15@gated-at.bofh.it>
2005-09-15 18:46 ` Nigel Kukard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1126773168.12556.13.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=328135@bugs.debian.org \
--cc=horms@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®