ath10k: firmware crash in station mode

[Michal Kazior]

On 19 May 2014 11:47, Vu Hai NGUYEN <vh.nguyen at actiasodielec.fr> wrote:
>>The 636 crashes because the interface is in promiscuous mode (it's
>>either put in a bridge or you have tcpdump running on it?). This won't
>>work with 636. See mailing list archives. 636 has broken monitor mode
>>and it crashes often.
>
>>Can you please retry with debug_mask=0xffffffff to get full dumps and
>>see what kind of frame is being sent? I guess it's an ipv6 neighbour
>>solicitation but the request itself might be malformed for some reason
>>causing firmware to crash unexpectedly.

Actually I'm able to reproduce this locally. The frame is a NullFunc
frame. However from what I'm seeing firmware 10.1 crashes in response
to wmi vdev up command. There's no firmware crash if I associate
before adding then wlan interface to a bridge though. Perhaps there's
something ath10k is doing but shouldn't or should be but isn't - I
have no idea what that could be now.

I'm a bit surprised since I thought this worked with 10.1. I think
I've even had tested 4addr this way before so there's a chance this is
a regression in ath10k.

Thanks for the logs anyway. I was able to reproduce this quickly since
it narrowed my search for the crash trigger.


>>Also, can you try the test without making wlan interface promiscuous
>>(on both firmwares, with debug_mask=0xffffffff) too, please?
>
> Yes I used promiscuous to set up my station in bridge mode, the firmware crashed
> but If don't use promiscuous (put my station in router mode), the firmware didn't crash and
> I can associate with the access point without problem.
> You can found in the attached file 4 dmesg file (with/without promicuous) for both version of firmware.
> (If I set debug mask=0xffffffff there are many lines "htt rx pop" and I can not see all the dmesg, so I
> only set the mask=0xffffff3f).

> But I wonder if there will be any progress of the firmware in the future for promiscuous so that I can
> set up bridge mode?

Beats me. You should ask QCA about the future of ath10k firmware.


>>If you generate backports with kvalo/ath master branch then DFS won't
>>work as it is now (due to the bug I've mentioned earlier). Kalle
>>doesn't have the patch that deals with it, yet. You'll need to
>>cherry-pick the following 2 patches before generating backports from kvalo/ath:
>
>  > https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211-next.git/commit/?id=67ae07a109f3d518085e3b81aa48740e8c5cc3f7
>  >https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211-next.git/commit/?id=00ec75fc5a6499d8fdeb6ec9f8f5df68b9291c74
>
>  I did not get your suggest here, How can I "cherry-pick" thoses 2 patch before generating backports? I think that I sould generate the backport first and then apply these 2 patchs later?

You should probably get yourself familiar with git
(http://git-scm.com/book/en/Getting-Started-Git-Basics,
http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html).

Patching a generated backports tree is a mess. Generally you should
apply fixes to your source kernel tree that your backports are being
derived from.


Michał