#19316: ath10k_pci 0000:01:00.0: failed to process fft report: -22
----------------------+------------------------
Reporter: kevindb | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: kernel | Version: Trunk
Resolution: | Keywords: ath10k fft
----------------------+------------------------
Comment (by michal.kazior@…):
Replying to [comment:1 anonymous]:
> Same issue here on an Archer C5 v1.20 (build r44918 with DFS enabled
like explained here:
http://wiki.openwrt.org/doc/uci/wireless#dfsradar_detection) when setting
channel to "auto" or to a channel requiring DFS.
> After a while, it seems the wlan interface can't execute a scan
operation (error with {{{iw phy0 scan}}}).
> After a while too (couldn't see if these 2 facts are related), the
channel is changed to "36" forcefully with:
> {{{
> daemon.info hostapd: wlan0: IEEE 802.11 driver had channel switch:
freq=5180, ht=1, offset=1, width=3, cf1=5210, cf2=0
> }}}
>
> When using a channel not requiring DFS, the log in the ticket is not
visible.
DFS channels require APs to listen for radar pulses. If it does detect one
it is required to stop RF radiation and run away to a different channel.
It does this by quickly announcing that to connected stations and then
switching. This is regulated by ETSI and FCC regulatory bodies in Europe
and US respectively.
There's also a requirement for AP to assess if a channel is usable prior
to initiating RF radiation on it.
It might be that your scan request was rejected due to CAC being under way
or channel switch was being scheduled at the time. Hence this is normal
operation and nothing to worry about.
Regarding the original ticket complaint:
DFS and spectral scan share underlying HW mechanisms and enabling one
enables the other (as far as event reporting from firmware to driver is
concerned). Spectral scan isn't fully understood and I suspect it hits a
certain condition in the driver `if (bin_len == 64) return -EINVAL`.
Spectral scan events take no part in processing of DFS radar pulses (they
are delivered as distinct events) so the warning you're seeing is
harmless.
Ideally spectral scan code needs to be revisited and improved. I don't
like the idea of putting a special condition to filter out spectral scan
events because useful to see more as it may reveal real bugs.
--
Ticket URL: <https://dev.openwrt.org/ticket/19316#comment:3>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
