[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1197989826.4885.169.camel@johannes.berg>
Date: Tue, 18 Dec 2007 15:57:06 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Miles Lane <miles.lane@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
ipw3945-devel@...ts.sourceforge.net,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@...e.cz>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.24-rc5-mm1 -- INFO: possible circular locking dependency
detected -- pm-suspend/5800 is trying to acquire lock
> Sorry. GMail doesn't support sending unwrapped text, as far as I can
> tell. I will send the log segment to you as an attachment. Also,
> when I sent my .config inline to Andrew recently, it tripped his spam
> filter. I'll attach it as well.
Thanks. This is a bug in iwlwifi.
The problem is actually another case where my workqueue debugging with
lockdep is triggering a warning :))
Here's the thing:
iwl3945_cancel_deferred_work does
cancel_delayed_work_sync(&priv->init_alive_start);
(which is the "(&(&priv->init_alive_start)->work)" lock)
but it is called from within a locked section of
mutex_lock(&priv->mutex); (locked from iwl3945_pci_suspend)
On the other hand, the task that runs from the init_alive_start
workqueue is iwl3945_bg_init_alive_start() which will lock the same
mutex.
So the deadlock condition is that you can be in
cancel_delayed_work_sync() above while the mutex is locked, and be
waiting for iwl_3945_bg_init_alive_start() which tries to lock the
mutex.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists