ath10k: firmware crash in station mode

Michal Kazior michal.kazior at
Mon May 19 05:51:08 PDT 2014

On 19 May 2014 11:47, Vu Hai NGUYEN <vh.nguyen at> 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:
>  >
>  >
>  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

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.


More information about the ath10k mailing list