On 07/18/2017 09:47 AM, Ryan Hsu wrote:

On 07/11/2017 06:19 PM, Igor Mitsyanko wrote:

quoted

On 07/11/2017 10:28 AM, Andrey Ryabinin wrote:

quoted

It gave me this:

[118648.825347] #1 quota too big 72 64 16
[118648.825351] #2 quota too big 72 64 16
[118648.825471] ------------[ cut here ]------------
[118648.825484] WARNING: CPU: 0 PID: 0 at ../net/core/dev.c:5274 net_rx_action+0x258/0x360

So this means that we didn't met the condition bellow, i.e. skb_queue_empty() returned true.

         ath10k_htt_txrx_compl_task():

                 if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
                     !skb_queue_empty(&htt->rx_in_ord_compl_q)) {
                         resched_napi = true;
                         goto exit;
                 }

quoted

Also WLAN.RM.2.0-00180-QCARMSWPZ-1 firmware is a bit old, could you also update firmware to give it a try?
https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4

Will try.

Maybe ath10k_htt_rx_in_ord_ind() has to accept "budget_left" parameter and use it to limit number of processed MSDUs in queued AMSDU and saving rest for later (NAPI has to be rescheduled in this case).
It seems natural that this problem happens with current logic, in case AMSDU in Rx queue has more elements then left in budget.

Thanks, likely in current logic, it does have chance to exceed the budget while dequeuing from the last list.

Can you give it a try this one? for QCA6174 reorder is offload, so this should be good enough for your case to test, will have to check non-offload reorder case... but let me know if you're seeing something different....

I've been running with this patch almost a week and haven't seen the WARNING. One week is usually enough to trigger it several times.
I guess we can assume that the patch fixed the problem.