More issues with ath10k_flush

[Ben Greear]

On 06/05/2014 11:47 AM, Ben Greear wrote:
> 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.

After poking around, it seems there is no wmi command to tell
the firmware to just flush everything, so I hacked one into
my firmware, called it before ath10k_flush starts waiting,
and after several reboots, I do not see any timeouts trying
to flush.

So, maybe that will do the trick...other suggestions are
still welcome :)

Ben

> 
> 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 at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com