[rt2x00-users] rt73usb cause system to crash after resuming from suspend

Johannes Stezenbach js at sig21.net
Fri Feb 4 02:06:02 AEDT 2011


On Wed, Feb 02, 2011 at 11:42:34PM +0100, Johannes Stezenbach wrote:
> On Wed, Feb 02, 2011 at 02:55:53PM -0200, Leonardo Luiz Padovani da Mata wrote:
> > 
> > After that, the system still crashes on resuming from suspend, but
> > now, when i try to rmmod the rt73usb, the kernel output this dump:
> 
> the dump shows tasks waiting for rtnl_lock
> 
> > [  360.312474]  [<c1045441>] flush_workqueue+0xfb/0x24f
> > [  360.312485]  [<c13ce964>] ? skb_queue_purge+0xd/0x1b
> > [  360.312497]  [<c14ac112>] ieee80211_stop_device+0x23/0x65
> > [  360.312509]  [<c14a1528>] ieee80211_do_stop+0x352/0x3e9
> > [  360.312519]  [<c14d8a28>] ? _raw_spin_unlock_bh+0x17/0x19
> > [  360.312530]  [<c13e6548>] ? dev_deactivate+0x139/0x15a
> > [  360.312542]  [<c14a15d1>] ieee80211_stop+0x12/0x16
> > [  360.312552]  [<c13d66f3>] __dev_close+0x66/0x76
> > [  360.312563]  [<c13d6717>] dev_close+0x14/0x36
> > [  360.312574]  [<c1480ff6>] cfg80211_rfkill_set_block+0x2e/0x55
> > [  360.312585]  [<c1481036>] cfg80211_rfkill_sync_work+0x19/0x1c
> 
> cfg80211_rfkill_set_block() holds the rtnl_lock
> 
> Which explains why I don't see the issue because I have
> rfkill disabled in my embedded board kernel config.
> 
> cfg80211_rfkill_set_block() then waits for flush_workqueue()
> on the mac80211 workqueue 
> 
> > [  360.313551]  [<c1045185>] cancel_work_sync+0xa/0xc
> > [  360.313568]  [<f88757de>] rt2x00lib_remove_dev+0x29/0xcc [rt2x00lib]
> > [  360.313581]  [<f896e08b>] rt2x00usb_disconnect+0x25/0x88 [rt2x00usb]
> 
> and this maybe too
> 
> Does someone know which of the kworker threads is servicing
> the mac80211 workqueue?  It might be that this is an rfkill
> issue and not rooted in rt2x00 code.  Or maybe it is due to
> rt2x00's use of workqueues?

Thinking a bit more about it I think indeed that rfkill deadlocks,
maybe due to changes in workqueue code.  I guess one of the work items
on the mac80211 queue waits for the rtnl_lock which
cfg80211_rfkill_set_block() hold.

If you have time to test, maybe enabling CONFIG_PROVE_LOCKING (aka LOCKDEP)
and CONFIG_DEBUG_LOCK_ALLOC would turn something up.

But I think the rfkill invocation on rmmod is in error and is
caused by the clearing of DEVICE_STATE_PRESENT at the
start of rt2x00lib_remove_dev().  This will cause
rt2x00usb_register_read() to bail out and return stale data,
and thus rt73usb_rfkill_poll() to detect a false event.
Maybe you can try if the patch below helps
(patch is against 2.6.37).


Signed-off-by: Johannes Stezenbach <js at sig21.net>

diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index c3c206a..48800ee 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -716,6 +716,7 @@ void rt2x00mac_rfkill_poll(struct ieee80211_hw *hw)
 	struct rt2x00_dev *rt2x00dev = hw->priv;
 	bool active = !!rt2x00dev->ops->lib->rfkill_poll(rt2x00dev);
 
-	wiphy_rfkill_set_hw_state(hw->wiphy, !active);
+	if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+		wiphy_rfkill_set_hw_state(hw->wiphy, !active);
 }
 EXPORT_SYMBOL_GPL(rt2x00mac_rfkill_poll);




More information about the users mailing list