On 04/04/2014 04:37 AM, Michal Kazior wrote:
Hi, After digging around I've found what seems to be the problem with WMI Tx credit starvation and inability to properly flush Tx in ath10k_flush(). Long story short: if a client that was asleep (as per what firmware thinks) goes out of range (or just stops responding) then Tx rots in FW/HW queues for a few seconds before it's discarded. For WMI Tx credits this means management frames eat up Tx credits for a few seconds (causing other WMI commands to timeout and return -EAGAIN/-11). For HTT Tx this means NullFunc frames would get stuck for a few seconds before completion was received. @Ben: Can you check if this helps you? I tested this briefly and at least [1/4] seems fixes the WMI Tx starvation. I'm hoping patches 2-4 help with your ath10k_flush() failures which I haven't been successfull in reproducing (but have observed improvement with purging some frames out of FW/HW queues).
I'm out of office for a bit, but will test this as soon as I'm back. Thanks for looking into this! In general, would it make more sense to have a few more tx credits available to mitigate the slow-to-be-processed buffers? Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
