On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > 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. So far that hasn't seemed to help, although maybe you can read traces better than I can. The big problem is that the actual queue doesn't seem to have stopped; it might be an ath9k bug. >> 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. Oops, typo. The QCA9531 *is* MIPS. The one where it triggers is the dual-core ARM. >> 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 :) Aw. That would have made it a lot easier! -- 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
