[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227621877.9425.102.camel@zakaz.uk.xensource.com>
Date: Tue, 25 Nov 2008 14:04:37 +0000
From: Ian Campbell <ijc@...lion.org.uk>
To: Trond Myklebust <trond.myklebust@....uio.no>
Cc: linux-nfs@...r.kernel.org, Max Kellermann <mk@...all.com>,
linux-kernel@...r.kernel.org, gcosta@...hat.com,
Grant Coady <grant_lkml@...o.com.au>,
"J. Bruce Fields" <bfields@...ldses.org>,
Tom Tucker <tom@...ngridcomputing.com>
Subject: Re: [PATCH] NFS regression in 2.6.26?, "task blocked for more than
120 seconds"
On Tue, 2008-11-25 at 08:57 -0500, Trond Myklebust wrote:
> On Tue, 2008-11-25 at 13:38 +0000, Ian Campbell wrote:
> > > That would indicate that the server is failing to close the TCP
> > > connection when the client closes on its end.
> > >
> > > Could you remind me what server you are using?
> >
> > 2.6.25-2-486 which is a Debian package from backports.org, changelog
> > indicates that it contains 2.6.25.7.
>
> Hmm... It should normally close sockets when the state changes. There
> might be a race, though...
>
> > > Also, does 'netstat -t'
> > > show connections that are stuck in the CLOSE_WAIT state when you see the
> > > hang?
> >
> > I'd have to wait for it to reproduce again to be 100% sure but according
> > to http://lkml.indiana.edu/hypermail/linux/kernel/0808.3/0120.html
> > I was seeing connections in FIN_WAIT2 but not CLOSE_WAIT.
>
> That would be on the client side. I'm talking about the server.
Ah, OK. I'll abort my current test of 2.6.26+revert and wait for a repro
so I can netstat the server, give me a couple of days...
Ian.
--
Ian Campbell
It is more rational to sacrifice one life than six.
-- Spock, "The Galileo Seven", stardate 2822.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists