Sebastian Gottschall <s.gottschall@xxxxxxxxxx> writes: > Am 30.01.2018 um 19:55 schrieb Toke Høiland-Jørgensen: >> Ben Greear <greearb@xxxxxxxxxxxxxxx> writes: >> >>>> I'm actually working on reworking that whole scheduler logic, and move >>>> some of it into mac80211. Could you test this (WiP) patch and see if >>>> that has the same problem? >>> It had some serious conflicts in ath10k, due to my local changes, so >>> I did not actually test this. >> Can send you a version without the ath10k changes tomorrow if you'd like >> to test - but will try to reproduce myself as well... >> >>> But, a revert of the atf patches (a6e56d749 and 63fefa050) appear to >>> have resolved the issue. I'll test more with these reverted, and maybe >>> will have time to work more on actually fixing upstream code next time >>> I move to a newer kernel (and/or after your pending changes get in). >> Ah, that narrows it down some. Well, that is the code I'm hacking on >> currently anyway, so let's see if we can't get it fixed as part of that >> series :) > i have some addition information for you maybe. in the same timeframe i > noticed a increased memory usage for ath9k devices. > maybe that helps. so i hit memory boundaries on embedded devices with > dual interfaces and just 32 mb ram now which wasnt the case before > is this patch worth to try from my side? This is probably because of the added queue space. Which is sort of by design. In 3ff23cd5654b9c8f4d567caa73439b4c39fbeaae we lowered the default limit for non-VHT devices to 4MB. But if you have several PHYs on a very memory constrained device you could still run out I guess. `echo fq_memory_limit 2097152 > /sys/kernel/debug/ieee80211/phy0/aqm` would limit it to 2MB for that phy... -Toke
