More issues with ath10k_flush
michal.kazior at tieto.com
Thu Jun 5 22:16:23 PDT 2014
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.
> 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.
More information about the ath10k