Go back –> ath10k

How to debug ath10k

Debug log messages

ath10k contains various debug log levels (check drivers/net/wireless/ath/ath10k/debug.h for up-to-date list):

enum ath10k_debug_mask {
        ATH10K_DBG_PCI          = 0x00000001,
        ATH10K_DBG_WMI          = 0x00000002,
        ATH10K_DBG_HTC          = 0x00000004,
        ATH10K_DBG_HTT          = 0x00000008,
        ATH10K_DBG_MAC          = 0x00000010,
        ATH10K_DBG_BOOT         = 0x00000020,
        ATH10K_DBG_PCI_DUMP     = 0x00000040,
        ATH10K_DBG_HTT_DUMP     = 0x00000080,
        ATH10K_DBG_MGMT         = 0x00000100,
        ATH10K_DBG_DATA         = 0x00000200,
        ATH10K_DBG_BMI          = 0x00000400,
        ATH10K_DBG_REGULATORY   = 0x00000800,
        ATH10K_DBG_ANY          = 0xffffffff,
};

The debug log levels can be enabled either with a module parameter named debug_mask or from sysfs. To get debug log messages enabled in the build enable CONFIG_ATH10K_DEBUG.

To enable debug logs with the module parameter:

# modprobe ath10k_core.ko debug_mask=0x16

Alternatively the debug logs can be enabled from sysfs anytime ath10k is running:

# echo 0x16 > /sys/module/ath10k_core/parameters/debug_mask

To check what is current debug_mask value:

$ cat /sys/module/ath10k_core/parameters/debug_mask
22

Note that the returned value is in decimal format, not hexadecimal.

debug_mask value is a bitwise OR operation of enum ath10k_debug_mask values above. For example, to enable HTC, WMI and MAC debug levels use python to calculate the value:

$ python -c "print '0x%x' % (0x2 | 0x4 | 0x10)"
0x16

Useful debug masks

Example values for debug_mask to help started with debugging:

Tracing

Enable tracing support with CONFIG_ATH10K_TRACING. If you want to get debug logs included the trace (most of the time you do) also enable CONFIG_ATH10K_DEBUG.

To trace all log messages, including debug logs, into trace.dat file:

trace-cmd record -e ath10k_log*

To trace everything possible from ath10k, mac80211 and cfg80211:

trace-cmd record -e mac80211 -e cfg80211 -e ath10k

To include hostapd (or wpa_supplicant) to the trace add -T switch to hostapd command line.

To read the trace.dat file:

trace-cmd report

See mac80211 tracing for more information.

HTT statistics

The firmware provides various statistics for HTT (the data path in ath10k). There are different types of statistics available:

enum htt_dbg_stats_type {
        HTT_DBG_STATS_WAL_PDEV_TXRX = 0x01,
        HTT_DBG_STATS_RX_REORDER    = 0x02,
        HTT_DBG_STATS_RX_RATE_INFO  = 0x04,
        HTT_DBG_STATS_TX_PPDU_LOG   = 0x08,
        HTT_DBG_STATS_TX_RATE_INFO  = 0x10,
};

To enable statistics use bitwise OR operation to combine the values and write it htt_stats_mask. Here's an example which enables TX PPDU logs:

# echo 0x8 > /sys/kernel/debug/ieee80211/phy0/ath10k/htt_stats_mask

Not ath10k will query for those HTT statistics for every second. The stats are delivered to user space through trace events and trace-cmd is used to store the statistics:

sudo trace-cmd record -e ath10k_htt_stats

Firmware version

Firmware version can be retrieved with ethtool:

$ sudo ethtool -i wlan1
driver: ath10k_pci
version: 3.12.0-rc3-wl+
firmware-version: 1.0.0.636
bus-info: 0000:02:00.0

Alternatively they are visible from kernel logs:

$ dmesg | grep ath10k
[11748.124678] ath10k_pci 0000:02:00.0: irq 33 for MSI/MSI-X
[11748.125047] ath10k_pci 0000:02:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
[11749.393511] ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 3 htt 2.1
[11749.393576] ath10k_pci 0000:02:00.0: debug 1 debugfs 1 tracing 1 dfs 1 testmode 1

DFS

Radar can be simulated by debugfs entry:

echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/dfs_simulate_radar

This will trigger radar event to mac80211.

To prevent changing a channel after radar is detected, only for testing purposes:

echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/dfs_block_radar_events

Use 0 to unblock it.

Be aware that currently ath10k pattern detector supports only ETSI master region. For other regulatory domains single phyerr will trigger radar event.

Manual bitrates configuration

In order to setup bitrates latest version of iw is required.

Just type iw to get short hint how to use it.

iw
.
.
dev <devname> set bitrates [legacy-<2.4|5> <legacy rate in Mbps>*]
[ht-mcs-<2.4|5> <MCS index>*] [vht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*]
.
.

Currently ath10k HW is limited to handle only single fixed rate setting or limit number of used spatial streams.

Not passing any arguments would clear the existing mask (if any).

Some examples:

iw wlanX set bitrates legacy-5 ht-mcs-5 vht-mcs-5 2:9

will setup VHT, nss=2, mcs=9

iw wlanX set bitrates legacy-5 18 ht-mcs-5 vht-mcs-5

will setup legacy, 18Mbps

iw wlanX set bitrates legacy-5 ht-mcs-5 3 vht-mcs-5

will setup HT, nss=1, mcs=3

iw wlanX set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-9

will setup nss=1

iw wlanX set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-9 2:0-9

will setup nss=2

It is possible to force SGI by adding force-sgi at the end of command:

iw wlanX set bitrates legacy-5 ht-mcs-5 vht-mcs-5 2:9 force-sgi

Simulating firmware crashes

It's possible to manually trigger a firmware crash using simulate_fw_crash debugfs file:

echo hard > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash

There are different ways to crash the firmware, simulate_fw_crash file has a help text:

# cat simulate_fw_crash 
To simulate firmware crash write one of the keywords to this file:
`soft` - this will send WMI_FORCE_FW_HANG_ASSERT to firmware if FW supports that command.
`hard` - this will send to firmware command with illegal parameters causing firmware crash.
`assert` - this will send special illegal parameter to firmware to cause assert failure and crash.
`hw-restart` - this will simply queue hw restart without fw/hw actually crashing.