Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755217AbYGVXEY (ORCPT ); Tue, 22 Jul 2008 19:04:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753260AbYGVXEK (ORCPT ); Tue, 22 Jul 2008 19:04:10 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:60027 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753196AbYGVXEJ (ORCPT ); Tue, 22 Jul 2008 19:04:09 -0400 Date: Tue, 22 Jul 2008 16:04:09 -0700 (PDT) Message-Id: <20080722.160409.216536011.davem@davemloft.net> To: Larry.Finger@lwfinger.net Cc: kaber@trash.net, torvalds@linux-foundation.org, akpm@linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org Subject: Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98() From: David Miller In-Reply-To: <4886294C.4060905@lwfinger.net> References: <48860D4B.8070003@lwfinger.net> <488616C0.8070505@trash.net> <4886294C.4060905@lwfinger.net> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2418 Lines: 55 From: Larry Finger Date: Tue, 22 Jul 2008 13:39:08 -0500 > ============================================= > [ INFO: possible recursive locking detected ] > 2.6.26-Linus-05752-g93ded9b-dirty #53 > --------------------------------------------- > b43/1997 is trying to acquire lock: > (_xmit_IEEE80211#2){-...}, at: [] > ieee80211_scan_completed+0x130/0x2e1 [mac80211] > > but task is already holding lock: > (_xmit_IEEE80211#2){-...}, at: [] > ieee80211_scan_completed+0x130/0x2e1 [mac80211] > > other info that might help us debug this: > 3 locks held by b43/1997: > #0: ((name)){--..}, at: [] run_workqueue+0xa7/0x1f2 > #1: (&(&local->scan_work)->work){--..}, at: [] > run_workqueue+0xa7/0x1f2 > #2: (_xmit_IEEE80211#2){-...}, at: [] > ieee80211_scan_completed+0x130/0x2e1 [mac80211] > > stack backtrace: > Pid: 1997, comm: b43 Not tainted 2.6.26-Linus-05752-g93ded9b-dirty #53 > > Call Trace: > [] __lock_acquire+0xb7b/0xecc > [] __mutex_unlock_slowpath+0x100/0x10b > [] lock_acquire+0x51/0x6a > [] ieee80211_scan_completed+0x130/0x2e1 [mac80211] > [] _spin_lock+0x1e/0x27 > [] ieee80211_scan_completed+0x130/0x2e1 [mac80211] > [] ieee80211_sta_scan_work+0x0/0x1b8 [mac80211] > [] run_workqueue+0xf0/0x1f2 > [] worker_thread+0xdb/0xea > [] autoremove_wake_function+0x0/0x2e > [] worker_thread+0x0/0xea > [] kthread+0x47/0x73 > [] trace_hardirqs_on_thunk+0x3a/0x3f > [] child_rip+0xa/0x11 > [] restore_args+0x0/0x30 > [] kthreadd+0x19a/0x1bf > [] kthread+0x0/0x73 > [] child_rip+0x0/0x11 Lockdep doesn't like that we have an array of objects (the TX queues) and we're iterating over them grabbing all of their locks. Does anyone know how to teach lockdep that this is OK? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/