On 11/14/2012 09:28 AM, Johannes Berg wrote:
On Wed, 2012-11-14 at 09:13 -0800, Ben Greear wrote:
I'm guessing that the other interfaces are actually re-scheduling work
items while this is trying to flush ... I'm not really sure how to
improve this behaviour though.
That seems very likely, as other stations would be trying to associate
in this scenario....
Can we just purge all of this interface's work items from the list w/out flushing
everyone else's work?
Actually, what I said doesn't quite make sense. We evidently use
flush_work() which doesn't care about *new* items, so I suppose it just
has to wait so long because there are other items already that are
taking a long time.
However, it seems that doing flush_work() is completely pointless,
cancel_work_sync() would be just as effective -- the work exits right
away if the interface is no longer marked running, and it is marked
not-running before we even do the flush_work(). So using
cancel_work_sync() should be safe here and would avoid the long delay
you're seeing.
Could you try this? The flush_work() is in iface.c:ieee80211_do_stop()
I will try this, but it will be a few days before I can get to it
most likely.
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
