Compex WLE900N5-23

[Yeoh Chun-Yeow]

Yes, this is the latest firmware that I have tried:

ath10k_pci 0000:00:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
10.2.4.48 api 4 htt 2.1 wmi 5 cal otp max_sta 128

But still the same, firmware crashed:
[  154.920000] ath10k_pci 0000:00:00.0: failed to to request monitor
vdev 1 stop: -11
[  159.920000] ath10k_pci 0000:00:00.0: failed to synchronize monitor
vdev 1 stop: -145
[  159.920000] ath10k_pci 0000:00:00.0: failed to stop monitor vdev: -145
[  159.930000] ath10k_pci 0000:00:00.0: failed to recalc montior: -145
[  162.940000] ath10k_pci 0000:00:00.0: failed to stop WMI vdev 0: -11
[  165.940000] ath10k_pci 0000:00:00.0: failed to put down monitor vdev 1: -11
[  168.940000] ath10k_pci 0000:00:00.0: failed to to request monitor
vdev 1 stop: -11
[  173.940000] ath10k_pci 0000:00:00.0: failed to synchronize monitor
vdev 1 stop: -145
[  173.940000] ath10k_pci 0000:00:00.0: failed to stop monitor vdev: -145
[  176.950000] ath10k_pci 0000:00:00.0: failed to put down monitor vdev 1: -11
[  179.950000] ath10k_pci 0000:00:00.0: failed to to request monitor
vdev 1 stop: -11
[  184.950000] ath10k_pci 0000:00:00.0: failed to synchronize monitor
vdev 1 stop: -145
[  184.950000] ath10k_pci 0000:00:00.0: failed to stop monitor vdev: -145
[  187.960000] ath10k_pci 0000:00:00.0: failed to submit AP self-peer
removal on vdev 0: -11
[  190.960000] ath10k_pci 0000:00:00.0: failed to delete WMI vdev 0: -11
[  193.960000] ath10k_pci 0000:00:00.0: failed to remove AP self-peer
on vdev 0: -145
[  193.960000] ath10k_pci 0000:00:00.0: removing stale peer
04:f0:21:0c:a5:17 from vdev_id 0
[  196.970000] ath10k_pci 0000:00:00.0: failed to put down monitor vdev 1: -11

---
Chun-Yeow

On Tue, May 5, 2015 at 1:47 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 5 May 2015 at 07:40, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> Hi, Michal
>>
>> Any idea on this issue?
>
> Did you try more recent 10.2.4 firmware revisions?
>
> My guess is that 10.2-00082 introduced some kind of regression and
> doesn't reset the entire HW MAC state. I'd bet on Rx ring (there's a
> few of them and host can only use one of them) since from the logs
> you've provided it looks like after starting up interface there's no
> single Rx event to be seen and it is very likely that Rx triggers the
> hard crash due to invalid/stale memory pointer.
>
>
> Michał