Thread (182 messages) 182 messages, 27 authors, 2008-08-01

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

From: David Miller <davem@davemloft.net>
Date: 2008-07-22 23:04:24
Also in: linux-wireless, lkml

From: Larry Finger <redacted>
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: [<ffffffffa028f322>] 
ieee80211_scan_completed+0x130/0x2e1 [mac80211]

but task is already holding lock:
  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa028f322>] 
ieee80211_scan_completed+0x130/0x2e1 [mac80211]

other info that might help us debug this:
3 locks held by b43/1997:
  #0:  ((name)){--..}, at: [<ffffffff80245185>] run_workqueue+0xa7/0x1f2
  #1:  (&(&local->scan_work)->work){--..}, at: [<ffffffff80245185>] 
run_workqueue+0xa7/0x1f2
  #2:  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa028f322>] 
ieee80211_scan_completed+0x130/0x2e1 [mac80211]

stack backtrace:
Pid: 1997, comm: b43 Not tainted 2.6.26-Linus-05752-g93ded9b-dirty #53

Call Trace:
  [<ffffffff80255616>] __lock_acquire+0xb7b/0xecc
  [<ffffffff8040c9a0>] __mutex_unlock_slowpath+0x100/0x10b
  [<ffffffff802559b8>] lock_acquire+0x51/0x6a
  [<ffffffffa028f322>] ieee80211_scan_completed+0x130/0x2e1 [mac80211]
  [<ffffffff8040dc08>] _spin_lock+0x1e/0x27
  [<ffffffffa028f322>] ieee80211_scan_completed+0x130/0x2e1 [mac80211]
  [<ffffffffa028f6ce>] ieee80211_sta_scan_work+0x0/0x1b8 [mac80211]
  [<ffffffff802451ce>] run_workqueue+0xf0/0x1f2
  [<ffffffff802453ab>] worker_thread+0xdb/0xea
  [<ffffffff80248a5f>] autoremove_wake_function+0x0/0x2e
  [<ffffffff802452d0>] worker_thread+0x0/0xea
  [<ffffffff80248731>] kthread+0x47/0x73
  [<ffffffff8040d7b1>] trace_hardirqs_on_thunk+0x3a/0x3f
  [<ffffffff8020ceb9>] child_rip+0xa/0x11
  [<ffffffff8020c4ef>] restore_args+0x0/0x30
  [<ffffffff802486c5>] kthreadd+0x19a/0x1bf
  [<ffffffff802486ea>] kthread+0x0/0x73
  [<ffffffff8020ceaf>] 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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help