On Thu, May 24, 2018 at 3:39 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: > Daniel Mack <daniel@xxxxxxxxxx> writes: > >> On Thursday, May 24, 2018 01:48 PM, Kalle Valo wrote: >>> Daniel Mack <daniel@xxxxxxxxxx> writes: >>>> On Thursday, May 24, 2018 10:44 AM, Kalle Valo wrote: >>>>> Daniel Mack <daniel@xxxxxxxxxx> writes: >> >>>> It seems that once a network is successfully joined, the network >>>> stability is fine. I haven't seen any starvation of streams lately, at >>>> least not with the the patches in this series which I'm running since >>>> a while. That is, until a disconnect/reconnect attempt is made, and at >>>> this point, only management frames are involved. >>> >>> Ah, maybe originally you were seeing different issues with similar >>> symptoms? But now you have fixed the other bugsand now the stuck >>> transmitted management frame issue is left? Just guessing... >> >> Yeah, I wish I had a clearer picture on all this myself :( >> >> My patches definitely address some of the issues I have seen before, >> also the fixes for potential race conditions are likely to have a >> positive effect. But as you guessed yourself, I'm afraid that there's >> a multitude of possible sources for bugs, so it's hard to tell. > > Sure, but things seem to going be forward in steady state. Thanks for > your hard work! > >>> It would be great to have wcn36xx logging via tracing, just like ath10k >>> and iwlwifi does. This way logging shouldn't slow down the system too >>> much and with wpasupplicant's -T switch you can even get wpasupplicant's >>> debug messages to the same log with proper timestamps! And almost >>> forgot, you can also include mac80211 tracing logs as well: >>> >>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/tracing >>> >>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing >>> >>> See ath10k_dbg() and trace_ath10k_log_dbg() for ideas how to implement >>> this, and you can also take a look at iwlwifi. Should be pretty easy. >>> Patches more than welcome :) >> >> Okay, I'll see if I can find some time to look into this. >> >> The reason why I didn't focus the logging possibilities is that I >> looked at the SMD messages that are flying around which result from >> ieee80211 API calls into the driver, and I can't seem to find anything >> that's wrong, especially not before the timeouts occur. Hence, I don't >> actually expect any oddness on the ieee80211 layer. >> >> But I agree that in general, better logging is certainly helpful. > > Yeah, I'm not expecting tracing logs to solve this case either but maybe > we could find some hints. And it just makes it so much easier to see > what's really happening from tracing logs instead trying to guess from > the bug description. "a tracing log is worth a thousand words" ;) > > But if you don't have time to implement tracing support to wcn36xx > hopefully someone else has, all one needs is a DragonBoard 410c. A > simple project for a student or someone who wants to contribute > something to the kernel. I have time to do it. If nobody else started yet... Thanks. > >>>> It seems it does, yes. Tests at night seem to take a bit more time to >>>> make the effect happen. But then again, it could also be unrelated. I >>>> can't be certain at this point. >>> >>> Can you describe what kind of radio environment you have, is it a busy >>> office complex? How many APs around etc? >> >> I've tried different environments. In the office with 15-20 >> laptops/mobiles in the room I see about 10-15 APs. At home, where I >> did long-term nightly test, there's maybe a higher number of APs, but >> fewer devices on the channel of the AP that I used for tests. >> >> I haven't used any more sophisticated environments like a sealed >> reverberation chamber yet though. > > Ok, but please let me know if you see any differences caused by the > environment. > > -- > Kalle Valo > > _______________________________________________ > wcn36xx mailing list > wcn36xx@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/wcn36xx
