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.
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.
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.
Thanks,
Daniel
