Re: RE : ath10k: firmware crash in station mode

[Michal Kazior <michal.kazior@tieto.com>]

On 15 May 2014 15:27, Vu Hai NGUYEN <vh.nguyen@actiasodielec.fr> wrote:
>>This is NULL dereference in firmware. I suspect it's an incomplete
>>driver-firmware setup (i.e. some commands weren't issued or were
>>invalid).
>
>>Can you enable debug logs ( echo 0xffffff3f | sudo tee /sys/module/ath10k_core/parameters/debug_mask ) before you try to
>>associate and post logs, please? I'd like to see command sequence sent
>>to firmware before the crash happens.
>
> I enable directly the debug_mask when I load the module "modprobe ath10k_core.ko debug_mask=0x0xffffff3f" (I thought it is the same thing like what you do, right?).
> You can found de debug mess in the attached file (debug_10-1.txt). (line 3007: wlan0: associated and then in line 3008: ath10k: firmware crashed!)

Yeah. Loading core module with debug_mask pre-set is fine too. I just
tend to tune the debug_mask during runtime myself.

Thanks for capturing the logs!

Apparently 10.1 crashes right after ath10k tries to submit a frame tx command.

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.

Also, can you try the test without making wlan interface promiscuous
(on both firmwares, with debug_mask=0xffffffff) too, please?


>>Can you post the crash logs (as noted above) when you try the 999
>>branch too, please? It seems 999 crashes sooner than 10.1. It might be
>>helpful to see the different crash points.
>
> Yes it crashed sooner. There are no wlan0: associated in the debug message. (attached file: debug_999.txt).
>
>>I have no idea what version of kernel you're using. Perhaps you broke
>>your source tree when merging/rebasing/cherry-picking/backporting?
>>What's your git head commit?
>
>>I can associate ath10k with both firmware branches without a problem.
>
> Actually I'm compiling ath10k from backports version 3.15 for linux kernel 3.2.36 (provided for my chipset Marvell Armada 370). And I replace the folder /driver/net/wireless/ath from the one of master branch of ath10k (I can not see the information from debug file "fw_stats"  with the version ath10k of backport). I also applied the patch for get/set antennas too.

Do I understand correctly that you replace drivers/net/wireless/ath in
the *backports tree* with the drivers/net/wireless/ath found in
github.com/kvalo/ath master branch?

This is a bad idea. I'm not sure how *exactly* you replace the
directory but I hope you're aware backports rename ifdefs in the code
and Makefiles. This means Kconfig flags such as ATH10K_DFS_CERTIFIED
might not compile code you want even if you select them in `make
menuconfig`. This might explain why you're having problems with DFS.

Ideally you should generate backports tree yourself from a given
kernel tree (e.g. kvalo's ath master branch). See
https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking
for more details on this.


>>Yes, this works (or at least it should). It might be tricky to get it
>>right for someone who's not familiar with regulatory shenanigans in
>>some cases.
>
>>Recently there was a bug introduced that broke DFS (see linux-wireless
>>mailing list; it's in the process of being fixed), but since you
>>haven't provided any information what your kernel tree is I can't tell
>>if that's the actual problem or not.
>
> My kernel tree is 3.2.36 (sorry if I don't get what you mean). Please feel free to ask me more information if you need.

I'm not sure if your backports have the offending patch that breaks
DFS or not. If so you might need to cherry-pick it to your backports
tree manually or regenerate backports.

If you use backports 3.15-rc1-1 (as found on
http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/) then
there's no DFS bug there unless you tried to replace net/mac80211 and
net/wireless (as you've done with drivers/net/wireless/ath/ ...).

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


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k