On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote: > > Changing default_agg_timeout to zero (as it is on most non-ath9k > drivers) makes the problem pretty much go away. However, I think > it's because I'm just dodging the code path that triggers a race > condition.
That does seem likely. Perhaps you could reproduce it while running mac80211 tracing? There should be a fair amount of information about aggregation and queue stops in there, though as you note queue stops aren't really happening, only aggregation related things. Perhaps the tracepoints for that aren't quite sufficient. > Notes: > > - I'm using exactly the same ath9k driver (currently 20150525, but > we've tried newer ones with no difference) on two totally different > platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate > ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k. > > - I've been unable to trigger the problem on the QCA9531, but I have > on MIPS. That's ... not what I would have expected, especially since the MIPS is single core. That makes the races stranger than expected. > The aggregation code is... a little hairy. Does anyone have any > guesses where I might look for the race condition? Or better still, > a patch I can try? I'm not aware of any race conditions in the code right now :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
