From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755369Ab0ECGLY (ORCPT ); Mon, 3 May 2010 02:11:24 -0400 Received: from tauceti.net ([62.245.250.166]:50767 "EHLO www.tauceti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753211Ab0ECGLW (ORCPT ); Mon, 3 May 2010 02:11:22 -0400 MIME-Version: 1.0 Date: Mon, 03 May 2010 10:11:18 +0200 From: kernel To: Trond Myklebust Cc: "Michael S. Tsirkin\" , Avi Kivity , Andrew Morton , linux-mm@kvack.org, bugzilla-daemon@bugzilla.kernel.org, Rusty Russell , Mel Gorman , linux-nfs@vger.kernel.org,", Subject: Re: [Bugme-new] [Bug 15709] New: swapper page allocation failure In-Reply-To: <4BD76B81.2070606@tauceti.net> References: <4BC43097.3060000@tauceti.net> <4BCC52B9.8070200@tauceti.net> <20100419131718.GB16918@redhat.com> <20100421094249.GC30855@redhat.com> <20100422100304.GC30532@redhat.com> <4BD12F9C.30802@tauceti.net> <20100425091759.GA9993@redhat.com> <4BD4A917.70702@tauceti.net> <20100425204916.GA12686@redhat.com> <1272284154.4252.34.camel@localhost.localdomain> <4BD5F6C5.8080605@tauceti.net> <1272315854.8984.125.camel@localhost.localdomain> <4BD61147.40709@tauceti.net> <1272324536.16814.45.camel@localhost.localdomain> <4BD76B81.2070606@tauceti.net> Message-ID: User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Anything we can do to investigate this further? Thanks! Robert On Wed, 28 Apr 2010 00:56:01 +0200, Robert Wimmer wrote: > I've applied the patch against the kernel which I got > from "git clone ...." resulted in a kernel 2.6.34-rc5. > > The stack trace after mounting NFS is here: > https://bugzilla.kernel.org/attachment.cgi?id=26166 > /var/log/messages after soft lockup: > https://bugzilla.kernel.org/attachment.cgi?id=26167 > > I hope that there is any usefull information in there. > > Thanks! > Robert > > On 04/27/10 01:28, Trond Myklebust wrote: >> On Tue, 2010-04-27 at 00:18 +0200, Robert Wimmer wrote: >> >>>> Sure. In addition to what you did above, please do >>>> >>>> mount -t debugfs none /sys/kernel/debug >>>> >>>> and then cat the contents of the pseudofile at >>>> >>>> /sys/kernel/debug/tracing/stack_trace >>>> >>>> Please do this more or less immediately after you've finished mounting >>>> the NFSv4 client. >>>> >>>> >>> I've uploaded the stack trace. It was generated >>> directly after mounting. Here are the stacks: >>> >>> After mounting: >>> https://bugzilla.kernel.org/attachment.cgi?id=26153 >>> After the soft lockup: >>> https://bugzilla.kernel.org/attachment.cgi?id=26154 >>> The dmesg output of the soft lockup: >>> https://bugzilla.kernel.org/attachment.cgi?id=26155 >>> >>> >>>> Does your server have the 'crossmnt' or 'nohide' flags set, or does it >>>> use the 'refer' export option anywhere? If so, then we might have to >>>> test further, since those may trigger the NFSv4 submount feature. >>>> >>>> >>> The server has the following settings: >>> rw,nohide,insecure,async,no_subtree_check,no_root_squash >>> >>> Thanks! >>> Robert >>> >>> >>> >> That second trace is more than 5.5K deep, more than half of which is >> socket overhead :-(((. >> >> The process stack does not appear to have overflowed, however that trace >> doesn't include any IRQ stack overhead. >> >> OK... So what happens if we get rid of half of that trace by forcing >> asynchronous tasks such as this to run entirely in rpciod instead of >> first trying to run in the process context? >> >> See the attachment... >>