Re: Anyone seeing tx-credits 'hang'?

From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: Anyone seeing tx-credits 'hang'?
Date: Wed, 14 Jan 2015 09:57:50 -0800	[thread overview]
Message-ID: <54B6AE1E.3020900@candelatech.com> (raw)
In-Reply-To: <CA+BoTQ=7BDPUs+B4-wBp5RRhKpvjHcTtbo=CFqj6e62rA+HnGA@mail.gmail.com>

On 01/14/2015 01:45 AM, Michal Kazior wrote:
> On 13 January 2015 at 20:07, Ben Greear <greearb@candelatech.com> wrote:
> [...]
>>
>> I managed to get some better debug out of the firmware.
>>
>> I am having a hell of a time figuring out how the code flows through all
>> of the callbacks (in both firmware and driver), but it appears this is what happened:
>>
>> (I have instrumented transfer-id in both firmware and driver)
>>
>> firmware sent wmi message with transfer-id of 72.
>> kernel received this transfer-id
>> firmware's last send-callback transfer ID is 71.
>>
>> So, it seems that either ath10k did not do the transfer-complete logic,
>> did it incorrectly, or the firmware did not notice it was done.
>>
>> I cannot find where the transfer complete code that should be updating
>> firmware is at.  If you know, can you point me to it?
> 
> I think the send-callback should be called when CE is simply done
> doing it's stuff. There's no need for the other side to ack anything
> explicitly (it just needs to have a free buffer on it's side so CE can
> copy it over).
> 
> Or maybe it is the HOST_IS_COPY_COMPLETE_MASK? Not really sure.

I am now guessing that some magic IRQ happens when ath10k_ce_src_ring_write_index_set()
is called.

I may have narrowed down the problem a bit further now.

I printed out the ring indexes in firmware and driver when lockup
occured.  The target -> host ring ids match fine, but I notice that
it appears the firmware has pending entries in it's host -> target wmi
ring that it has not consumed.

Maybe it missed an irq or has some related race.

I'm going to try forcing a poll of the host -> target wmi queue in the
firmware when it detects no wmi keep-alive messages and see if that kicks
things back into action, and maybe see if I can find any reason for it
to not properly handle the ring in the first place.

If this works, perhaps there is a way to kick the ring from the driver
side...maybe send a wmi command (ignoring quota) that has no affect,
or something like that?

Thanks,
Ben

> 
> 
> Michał
> 

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