QCA6174 firmware crash

[Michael Ney]

I did a few more tests, including trying Backports 4.4.2-1 with no difference. Everything's pointing to a firmware issue not related specifically to the monitor VDEV. It seems to me that the Contention Free logic in the firmware doesn't handle Contention Free null frames addressed to other MAC addresses in any mode. As soon as the firmware is set to hear data frames not addresses to the hardware's MAC the firmware will crash on the first Null Data CF frame received.

In order to see if this was related to the monitor VDEV or something else, I configured the hardware to run in promiscuous mode with the managed VDEV. To do this I configured the RX filter (register 0x1803c) manually, turning on the promiscuous bit (0x20).


Reproduction:

1. Stay in managed mode (don't enter monitor mode)

2. echo 0x1803c > /sys/kern/debug/ieee80211/phy0/reg_addr

3. cat /sys/kernel/debug/ieee80211/phy0/reg_val

4. Change bit 0x20 to on (enable promiscuous mode)

5. echo (result of step 4) > /sys/kernel/debug/ieee80211/phy0/reg_val

6. Configure another card (ath9k, etc) to a target frequency (I used 5300 since it was fairly quiet). Transmit type 0x2 subtype 0x5 (Null data + CF ACK) on a loop.

7. iw wlan0 scan freq 5300

Immediately crashes.


If I run the scan without setting the rx_filter register, there is no crash.

If I run the scan without sending the Null Data + CF ACK frames from the other card, there is no crash.


--

I also configured ath10k_core with debug mask 0x5F (PCI, WMI, HTC, HTT, MAC, and PCI dump). When the firmware crashed, there was nothing unhandled nor unusual that came across the PCI bus.

--

Finally, in the crash's firmware register dump in my original email, I typoed the 2nd entry on line 20. it should be 0x004018F0 not 0x004019F0.



> On Apr 27, 2016, at 2:42 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> 
> On 26 April 2016 at 21:52, Michael Ney <neym at vorklift.com> wrote:
> 
> Firmware can get confused sometimes, especially when it comes to monitor vdev.
> 
> Perhaps you should try latest backports or generate one yourself from
> Kalle's ath.git? The problem may have been already fixed in upstream.
> 
> 
> Michał