ath10k driver crashes whenever firmware crashes on ARM SoC

[Janusz Dziedzic]

2014-01-28 Avery Pennarun <apenwarr at gmail.com>:
> On Tue, Jan 28, 2014 at 1:20 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 01/28/2014 09:18 AM, Avery Pennarun wrote:
>>> When the ath10k firmware crashes on my device (let's not worry about
>>> why the firmware crashes right now; one problem at a time), my host
>>> CPU (ARMv7 based) can't recover.  I get some variant of this error:
>>
>> I don't know about your pci bus problem, but I'm interested in knowing
>> about firmware crashes (if you are at liberty to share the details).
>
> Well, since you asked... :)
>
> I'm trying to build an especially robust system here, so when I
> noticed that the driver will bring the entire system crashing down
> upon a firmware crash, I've actually gone out of my way to make more
> firmware crashes.  So I'm using the ath10k (not ap) firmware from a
> month or so ago, in AP mode.  It's pretty easy to crash the firmware
> with a sequence something like this:
>
> - start hostapd (I'm using channel 36, HT20, no encryption)
> # note that hostapd already adds a mon.wlan0 monitor interface
> - iw wlan0 interface add mon0 type monitor
> - ip link set mon0 up
> - tcpdump -ni mon0 | head
>
FW636 have problems with monitor iface:
iw wlan0 set type monitor
ifconfig wlan0 up
tcpdump -i wlan0
Will always crash firmware after "entered promiscuous mode"

Generally in case you will have/left only one monitor interface and
active tcpdump (in your case after hostapd kill), you will always get
this crash. So using monitor interface with FW636 is not good idea.

BTW monitor works fine with 10.x FW.

BR
Janusz