From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761430AbXHCLBu (ORCPT ); Fri, 3 Aug 2007 07:01:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760400AbXHCLBn (ORCPT ); Fri, 3 Aug 2007 07:01:43 -0400 Received: from merkurneu.hrz.uni-giessen.de ([134.176.2.3]:43218 "EHLO merkurneu.hrz.uni-giessen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760367AbXHCLBm (ORCPT ); Fri, 3 Aug 2007 07:01:42 -0400 From: Marc Dietrich To: Andrew Morton Subject: Re: 2.6.23-rc1-mm2 Date: Fri, 3 Aug 2007 13:00:46 +0200 User-Agent: KMail/1.9.5 Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net, Neil Brown References: <20070731230932.a9459617.akpm@linux-foundation.org> In-Reply-To: <20070731230932.a9459617.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708031301.01569.marc.dietrich@ap.physik.uni-giessen.de> X-HRZ-JLUG-MailScanner-Information: Passed JLUG virus check X-HRZ-JLUG-MailScanner: No virus found X-MailScanner-From: marc.dietrich@ap.physik.uni-giessen.de Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, Am Wednesday 01 August 2007 08:09 schrieb Andrew Morton: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2. >6.23-rc1-mm2/ > > > - the git-block tree remains dropped due to disageement with the Vaio > > - git-e1000new was withdrawn by the authors > > - git-wireless is back. It is still a >3MB diff, and appears to compile. > > - Is anyone testing the kgdb code in here? I still get some nfs related locking bug. I applied linux-2.6.23-001-fix_rpciod_down_race.dif linux-2.6.23-003-fix_locking_regression.dif linux-2.6.23-004-fix_stateid_regression.dif ============================================= [ INFO: possible recursive locking detected ] 2.6.23-rc1-mm2 #3 --------------------------------------------- events/0/5 is trying to acquire lock: (events){--..}, at: [] flush_workqueue+0x0/0x70 but task is already holding lock: (events){--..}, at: [] run_workqueue+0xd4/0x1e0 other info that might help us debug this: 2 locks held by events/0/5: #0: (events){--..}, at: [] run_workqueue+0xd4/0x1e0 #1: ((nfs_automount_task).work){--..}, at: [] run_workqueue+0xd4/0x1e0 stack backtrace: [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x15/0x20 [] __lock_acquire+0xc22/0x1030 [] lock_acquire+0x61/0x80 [] flush_workqueue+0x49/0x70 [] flush_scheduled_work+0xd/0x10 [] nfs_release_automount_timer+0x2c/0x30 [nfs] [] nfs_free_server+0x9e/0xd0 [nfs] [] nfs_kill_super+0x16/0x20 [nfs] [] deactivate_super+0x7d/0xa0 [] mntput_no_expire+0x4b/0x80 [] expire_mount_list+0xe4/0x140 [] mark_mounts_for_expiry+0x99/0xb0 [] nfs_expire_automounts+0xd/0x40 [nfs] [] run_workqueue+0x12b/0x1e0 [] worker_thread+0x9b/0x100 [] kthread+0x42/0x70 [] kernel_thread_helper+0x7/0x18 ======================= thanks Marc -- "The enemy uses unauthorized weapons." Lord Arthur Ponsonby, "Falsehood in Wartime: Propaganda Lies of the First World War", 1928