From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [gfs2][RFC] readdir caused ls process into D (uninterruptible) state, under testing with Samba 3.0.25
Date: Mon, 20 Aug 2007 16:51:45 +0100 [thread overview]
Message-ID: <1187625105.8765.937.camel@quoit> (raw)
In-Reply-To: <91b13c310708200236l6089f1cdt336a3ce5072c97cf@mail.gmail.com>
Hi,
On Mon, 2007-08-20 at 17:36 +0800, rae l wrote:
> On 8/17/07, Steven Whitehouse <swhiteho@redhat.com> wrote:
> ...
> > > the stack trace of the 'D' state `ls`:
> > >
> > > =======================
> > > ls D F89B83F8 2200 12018 1 (NOTLB)
> > > f3eeadd4 00000082 f6a425c0 f89b83f8 f3eead9c f6a425d4 f6f32d80 f573a93c
> > > 00010000 f89b83f3 00000000 c40a2030 c3fa9fa0 c40aaa70 c40aab7c 00000e89
> > > b2a4b036 000002e4 c40a2030 f3eeae1c 00000000 c3f85e98 f8e11e09 f8e11e0e
> > > Call Trace:
> > > [<f89b83f8>] gdlm_bast+0x0/0x93 [lock_dlm]
> > > [<f89b83f3>] gdlm_ast+0x0/0x5 [lock_dlm]
> > > [<f8e11e09>] holder_wait+0x0/0x8 [gfs2]
> > > [<f8e11e0e>] holder_wait+0x5/0x8 [gfs2]
> > ^^^^ This function doesn't exist in recent kernels, so I
> > guess you are using an older kernel. Which version is it?
> Sorry for the late,
> The kernel I'm testing is 2.6.21.7, just because our testing cluster
> suite is from the last month when cluster-2.01 from here didn't come
> out,
> ftp://sources.redhat.com/pub/cluster/releases/
>
> So now we were keeping testing on kernel 2.6.21.y series, just for its
> stability, I don't know how about the stability of 2.6.22.y, I haven't
> tested it yet.
>
> So the problem I said has been fixed in later kernel after 2.6.22,
> please feel free to let me know.
>
I suspect that it might have been, but I can't say for certain. We've
fixed a number of things which look very similar, but not exactly like
the bug you seem to have hit. In the latest Linus' kernels there is a
fix for a problem in the DLM which it would be worth trying so if you
are in a position to test something more recent, then I would suggest
that as a first course of action.
Let me know if that doesn't solve the problem,
Steve.
WARNING: multiple messages have this Message-ID (diff)
From: Steven Whitehouse <swhiteho@redhat.com>
To: rae l <crquan@gmail.com>
Cc: cluster-devel@redhat.com,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [Cluster-devel] Re: [gfs2][RFC] readdir caused ls process into D (uninterruptible) state, under testing with Samba 3.0.25
Date: Mon, 20 Aug 2007 16:51:45 +0100 [thread overview]
Message-ID: <1187625105.8765.937.camel@quoit> (raw)
In-Reply-To: <91b13c310708200236l6089f1cdt336a3ce5072c97cf@mail.gmail.com>
Hi,
On Mon, 2007-08-20 at 17:36 +0800, rae l wrote:
> On 8/17/07, Steven Whitehouse <swhiteho@redhat.com> wrote:
> ...
> > > the stack trace of the 'D' state `ls`:
> > >
> > > =======================
> > > ls D F89B83F8 2200 12018 1 (NOTLB)
> > > f3eeadd4 00000082 f6a425c0 f89b83f8 f3eead9c f6a425d4 f6f32d80 f573a93c
> > > 00010000 f89b83f3 00000000 c40a2030 c3fa9fa0 c40aaa70 c40aab7c 00000e89
> > > b2a4b036 000002e4 c40a2030 f3eeae1c 00000000 c3f85e98 f8e11e09 f8e11e0e
> > > Call Trace:
> > > [<f89b83f8>] gdlm_bast+0x0/0x93 [lock_dlm]
> > > [<f89b83f3>] gdlm_ast+0x0/0x5 [lock_dlm]
> > > [<f8e11e09>] holder_wait+0x0/0x8 [gfs2]
> > > [<f8e11e0e>] holder_wait+0x5/0x8 [gfs2]
> > ^^^^ This function doesn't exist in recent kernels, so I
> > guess you are using an older kernel. Which version is it?
> Sorry for the late,
> The kernel I'm testing is 2.6.21.7, just because our testing cluster
> suite is from the last month when cluster-2.01 from here didn't come
> out,
> ftp://sources.redhat.com/pub/cluster/releases/
>
> So now we were keeping testing on kernel 2.6.21.y series, just for its
> stability, I don't know how about the stability of 2.6.22.y, I haven't
> tested it yet.
>
> So the problem I said has been fixed in later kernel after 2.6.22,
> please feel free to let me know.
>
I suspect that it might have been, but I can't say for certain. We've
fixed a number of things which look very similar, but not exactly like
the bug you seem to have hit. In the latest Linus' kernels there is a
fix for a problem in the DLM which it would be worth trying so if you
are in a position to test something more recent, then I would suggest
that as a first course of action.
Let me know if that doesn't solve the problem,
Steve.
next prev parent reply other threads:[~2007-08-20 15:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-16 8:20 [Cluster-devel] [gfs2][RFC] readdir caused ls process into D (uninterruptible) state, under testing with Samba 3.0.25 程任全
2007-08-16 8:20 ` 程任全
2007-08-16 8:28 ` [Cluster-devel] " Steven Whitehouse
2007-08-16 8:28 ` Steven Whitehouse
2007-08-17 7:43 ` [Cluster-devel] " rae l
2007-08-17 7:43 ` rae l
2007-08-17 15:27 ` Steven Whitehouse
2007-08-17 15:27 ` Steven Whitehouse
2007-08-20 9:36 ` rae l
2007-08-20 9:36 ` rae l
2007-08-20 15:51 ` Steven Whitehouse [this message]
2007-08-20 15:51 ` Steven Whitehouse
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=1187625105.8765.937.camel@quoit \
--to=swhiteho@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.