htt rx stopped. cannot recover

[Pushpal Sidhu]

On Tue, Nov 18, 2014 at 10:44 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> While running the extended test, at about 7 hours of continuous
>> testing with the two boards without a PCIe bridge (configured as a
>> wireless bridge e.g. 4addr=on), the STAtion has a kernel panic that
>> seems to be caused by a double free or something similar. Log is
>> located here (glad I set 'debug' in kernel cmdline):
>> http://dpaste.com/1G77X7N (most interesting info located between times
>> [25684.512971] - [25684.587585]).
>
> Is this on vanilla ath10k code or did you ignore the rx_confused flag
> during the test?

Vanilla code.

> Anyway it'd be lovely if you could get the code line for
> ath10k_htt_txrx_compl_task+0x100 (e.g. via `gdb` with `l *
> ath10k_htt_txrx_compl_task+0x100)`.

I'm on a slightly constrained system, but here's the info I could grab
(I couldn't get the exact code line):

(gdb) list *ath10k_htt_txrx_compl_task+0x100
0xca3c is in ath10k_htt_txrx_compl_task (include/linux/skbuff.h:987).
982     include/linux/skbuff.h: No such file or directory.
(gdb) list *ath10k_htt_txrx_compl_task+0x100/0x544
0xc93c is in ath10k_htt_txrx_compl_task (include/linux/spinlock.h:290).
285     include/linux/spinlock.h: No such file or directory.

However, if I were to make a guess, I would think the the oops
occurred in the rx_ring.lock when freeing.

>From your comment a few emails back, you mentioned that a possible
workaround is to "keep on syncing dma to cpu and checking the
MSDU_DONE bit for a few msecs." I tried this out and found (waited an
infinite amount of time just to verify) that it would never quit out,
meaning the memory wasn't there in the first place.

- Pushpal