More issues with ath10k_flush

[Ben Greear <greearb@candelatech.com>]

I'm back to debugging this charmer.

Currently I see the flush fail (and take 5 seconds doing so)
fairly often when creating lots of station vifs against my firmware.

Once stations are connected, there are usually no more timeouts,
even though I might be sending/receiving 100+Mbps of traffic for hours at
a time.

By printing out the firmware stats, I see that much of the time
the hardware has accepted X packets for transmission, but has completed
X-1.  It is possible the firmware's counters are screwed up some how
or that it lost a packet, but I think it may also be possible that
the firmware is just being really slow about completing a packet
every now and then.  I have looked at the firmware in detail and
have found no way that it could actually leak tx descriptors.

So, I was thinking about changing the flush logic to try
the current flush (that just waits) for up to 1/5 of the
flush timeout, and if that fails, try telling the firmware to purge
it's tx buffers, and then wait up to 4/5ths more of the
flush timeout.

Does that sound like a reasonable approach?

Currently, my work-around is just to restart firmware
after it fails to flush for 2 tries in a row, seems
like there could be something better!

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k