On 05/10/2013 02:25 PM, Johannes Berg wrote:
On Fri, 2013-05-10 at 14:21 -0700, Ben Greear wrote:void cfg80211_mlme_down(struct cfg80211_registered_device *rdev, struct net_device *dev) { struct wireless_dev *wdev = dev->ieee80211_ptr; struct cfg80211_deauth_request req; u8 bssid[ETH_ALEN]; ASSERT_WDEV_LOCK(wdev); printk("mlme_down: %s: type: %i sme_state: %i current-bss: %p\n", dev->name, (int)(wdev->iftype), (int)(wdev->sme_state), wdev->current_bss); I see this printout for the stuck station (this is dmesg | grep sta74, so it skips errors about other interfaces that are also hung). I am guessing we should never be calling mlme_down with state of CFG80211_SME_CONNECTED when bss is NULL?We should _never_ be in a state where current_bss is NULL but the state is != IDLE. The question I can't seem to find an answer for is how we got into that state, that we're in the state in down() is really less interesting. Since you seem to be able to reproduce this, maybe it'd help to mark all state transitions and current_bss assignments, and then backtrack them after the fact.
I'll work on instrumenting all of those assignments. I plan to use a helper macro to assign them and print out call sites.. Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
