More issues with ath10k_flush

[Michal Kazior]

On 6 June 2014 01:37, Ben Greear <greearb at candelatech.com> wrote:
> 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.

Interesting. This reminds me the lazy wmi-htc tx credit replenishment
after wmi mgmt tx is completed. Maybe it's a similar sort of thing?
Maybe it's actually completed but for some reason the completion
hasn't been fully processed yet..


>> 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.

Sounds reasonable.


> 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.

I thought WMI_PEER_FLUSH_TIDS_CMDID is for that. It didn't work for
you? If so I would assume it's a firmware bug..


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

Did you try to find out what kind of frame is supposedly held? I
recall you've posted a NullFunc hexdump once pointing that it's one of
the offending frames that didn't complete.

So.. maybe just not sending NullFunc frames (hell, they don't get a
proper ack status anyway..) or somehow altering how they are sent is
another way to work this around.


Michał