Created attachment 281663 [details] hostapd output when failing with ACS enabled I am using a wireless card based on the chip QCA9882 (SparkLan WPEQ-257ACN). I have been using this card for about 1 year as an access point using `hostapd`. However, since linux-5.0, `hostapd` fails to start if ACS is enabled. (`hostapd` output is attached as `hostapd_output.txt`) In order to have working wifi again, I can work around the problem in two ways: * Disable ACS in `hostapd` by setting a fixed wifi channel; * Reverting back to linux-4.19.x When using linux-5.0 and I attempt to start `hostapd` with ACS enabled, I get the following in `dmesg`: `ath10k_pci 0000:02:00.0: failed to parse chan info event: -71` The full `dmesg |grep ath10k` is attached as `dmesg_ath10k.txt`. Please let me know if any further info is necessary.
Created attachment 281665 [details] dmesg output when trying to start `hostapd` with ACS enabled
I've the same (almost) even without using hostapd (with "usual" laptop usage (as client)): ``` ath10k_pci 0000:03:00.0: failed to parse tlv: -22 ath10k_pci 0000:03:00.0: failed to parse chan info event: -22 ``` And it spams dmesg alot: ``` $ dmesg | grep -c ath10k_pci 272151 ```
Oh, and, yes, my board details: ``` ath10k_pci 0000:03:00.0: qca6174 hw2.1 target 0x05010000 chip_id 0x003405ff sub 1a56:1525 ath10k_pci 0000:03:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 ath10k_pci 0000:03:00.0: firmware ver SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 10bf8e08 ath10k_pci 0000:03:00.0: board_file api 2 bmi_id N/A crc32 ae2e275a ```
The bug persists with 5.1.14 kernel journalctl |rg failed |rg ath10k |wc -l 94976
I am hitting this too. 4.19 works perfectly. How can this be moved forward? It's a show stopper on a very popular piece of hardware!
No more spam-message since 5.3.4 kernel. Fixed ?
I no longer see the messages in dmesg (using linux-5.3.5), but I still cannot use ACS. I will further look into it this weekend to make sure it's not some misconfiguration on my part.
Scratch the above. Seems to be working as of linux-5.3.5. This kernel version makes the card painfully slow, but that is an issue for another bug. I think this one can be safely closed.