search

greearb / ath10k-ct

Stand-alone ath10k driver based on Candela Technologies Linux kernel.
111 stars 40 forks source link

Issue #4 is still seems to exist #87

Closed tanak3n closed 5 years ago

tanak3n commented 5 years ago

HW: I-O DATA WN-AC1167DGR with OpenWrt SNAPSHOT r10128-ef7aa03

I have a same probrem on this hardware and some people say that they still have the problem at #4 . Would you consider re-opening the issue?

klukonin commented 5 years ago

Hello

Please put this patches in package/kernel/ath10k-ct/patches/

Then build openwrt for your device and try the builded firmware.

patches.zip

tanak3n commented 5 years ago

I tried the patched firmware for few days and the issue is not appearing at this point.

Thanks.

greearb commented 5 years ago

So, did it happen often enough before than you are fairly confident those patches fixed it? klukonin, do you see those patches as a fix for this or some other specific issue, or just generally it seems to help?

klukonin commented 5 years ago

Well, I can say that this patches help to make things better on weak devices with one CPU and QCA988x. I tested it on UNBT UNiFI AP AC Lite/Mesh. The main approach was to fix possible credit starvation (I suppose to happen sometimes, according to my limited understanding) and heavy management traffic load when there are a lot of stations connected.

If you remember a case about 10 ms beacon interval, which was also reported by @socketpair (that's because we worked at the same company together when I found this case. So it's the same issue), it is fair to say that it's a corner case which triggers SWBA overrun without this patchset. Especially when we create a lot of virtual interfaces. Management traffic such as beacons, probe requests, e.t.c sometimes can be dropped due to the queue limit. But beacons looks like are not affected by management queue size so much (please say if I wrong). So SWBA overruns was fixed for me only through bigger tx-credits parameter. I also noticed a firmware "stuck" state after a lot of SWBA overruns and even after restart issue can be triggered again.

Such little enlargement of default values help not only in this case, but as I said above it help to make system more stable and handle high traffic load. So may be It's a good chance to change driver defaults a little bit.

greearb commented 5 years ago

I've added these patches to my tree, but I already did a request to pull in latest to openwrt, so it will have to be in the next update.

klukonin commented 5 years ago

Thank you. Hope this will help to many people =)

tanak3n commented 5 years ago

So, did it happen often enough before than you are fairly confident those patches fixed it? klukonin, do you see those patches as a fix for this or some other specific issue, or just generally it seems to help?

without the patches, I got SWBA overrun error per less than an hour. However, I never encounter the error with the patches.

Thank you, @greearb and @klukonin .

Catfriend1 commented 5 years ago

@greearb I'm new reading within the openwrt project. Could you please give me a link where I can check when your changes are merged and released?