When firmware crashes it's possible to create a coredump for later analysis,
add support to collect the register and memory info from SDIO devices.
The coredump configuration is different between QCA6174 PCI and QCA6174 SDIO,
so add specific registers and memory regions for the latter.
QCA6174 SDIO has two methods to dump the firmware: fastdump and slowdump.
Fastdump is not supported in olded versions of firmware, and for these ath10k
will automatically select slowdump. If firmware supports fastdump, ath10k will
automatically select it. QCA6174 SDIO firmware version
WLAN.RMH.4.4.1-00017-QCARMSWPZ-2 is the first version supporting fastdump.
For slowdump, ath10k_sdio_hif_diag_read() can not be used as the diag
window has a limit value, it is 4 bytes and the dump's buffer length is larger
than it, it will trigger error. So this patch adds ath10k_sdio_read_mem() to
read 4 bytes for each time.
Example output of a firmware crash:
ath10k_sdio mmc1:0001:1: simulating soft firmware crash
ath10k_sdio mmc1:0001:1: firmware crashed! (guid 413d98b1-84c0-4298-b605-2b10ec0c54a5)
ath10k_sdio mmc1:0001:1: qca6174 hw3.2 sdio target 0x05030000 chip_id 0x00000000 sub 0000:0000
ath10k_sdio mmc1:0001:1: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1
ath10k_sdio mmc1:0001:1: firmware ver WLAN.RMH4.4.1-00126-QCARMSWP-1 api 6 features wowlan,ignore-otp,raw-mode crc32 b84317cf
ath10k_sdio mmc1:0001:1: board_file api 2 bmi_id 0:4 crc32 6364cfcc
ath10k_sdio mmc1:0001:1: htt-ver 3.69 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
ath10k_sdio mmc1:0001:1: firmware register dump:
ath10k_sdio mmc1:0001:1: [00]: 0x05030000 0x000015B3 0x0099908D 0x00955B31
ath10k_sdio mmc1:0001:1: [04]: 0x0099908D 0x00060730 0x00000018 0x004641A0
ath10k_sdio mmc1:0001:1: [08]: 0x0041FAA4 0x0041FA9C 0x00999070 0x00404490
ath10k_sdio mmc1:0001:1: [12]: 0x00000009 0xFFFFFFFF 0x00952CD0 0x00952CE6
ath10k_sdio mmc1:0001:1: [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
ath10k_sdio mmc1:0001:1: [20]: 0x4099908D 0x0040E9E8 0x00000001 0x00423AC0
ath10k_sdio mmc1:0001:1: [24]: 0x809F3189 0x0040EA48 0x00426240 0xC099908D
ath10k_sdio mmc1:0001:1: [28]: 0x809143A7 0x0040EA68 0x0041FAA4 0x00423A80
ath10k_sdio mmc1:0001:1: [32]: 0x809F1193 0x0040EA88 0x00411770 0x004117E0
ath10k_sdio mmc1:0001:1: [36]: 0x809F0EEE 0x0040EAA8 0x00000000 0x00000000
ath10k_sdio mmc1:0001:1: [40]: 0x80911210 0x0040EAC8 0x00000008 0x00404130
ath10k_sdio mmc1:0001:1: [44]: 0x80911154 0x0040EB28 0x00400000 0x00000000
ath10k_sdio mmc1:0001:1: [48]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
ath10k_sdio mmc1:0001:1: [52]: 0x40910024 0x0040EB78 0x0040AB98 0x0040AB98
ath10k_sdio mmc1:0001:1: [56]: 0x00000000 0x0040EB98 0x009BB001 0x00040020
Tested-on: QCA6174 SDIO WLAN.RMH.4.4.1-00018-QCARMSWP-1
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1569310030-834-3-git-send-email-wgong@codeaurora.org
For some hw version, it has more than one bus type, it need to add bus
type to distinguish different chip.
Tested-on: QCA6174 SDIO WLAN.RMH.4.4.1-00018-QCARMSWP-1
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1569310030-834-2-git-send-email-wgong@codeaurora.org
In a multiradio board with one QCA9984 and one AR9987
after enabling the crashdump with module parameter
coredump_mask=7, below backtrace is seen.
vmalloc: allocation failure: 0 bytes
kworker/u4:0: page allocation failure: order:0, mode:0x80d2
CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.77 #130
Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
(unwind_backtrace) from [<c021abf8>] (show_stack+0x10/0x14)
(dump_stack+0x80/0xa0)
(warn_alloc_failed+0xd0/0xfc)
(__vmalloc_node_range+0x1b4/0x1d8)
(__vmalloc_node+0x34/0x40)
(vzalloc+0x24/0x30)
(ath10k_coredump_register+0x6c/0x88 [ath10k_core])
(ath10k_core_register_work+0x350/0xb34 [ath10k_core])
(process_one_work+0x20c/0x32c)
(worker_thread+0x228/0x360)
This is due to ath10k_hw_mem_layout is not defined for AR9987.
For coredump undefined hw ramdump_size is 0.
Check for the ramdump_size before allocation memory.
Tested on: AR9987, QCA9984
FW version: 10.4-3.9.0.2-00044
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The IRAM start address in coredump was wrong for QCA9984, QCA4019, QCA9888 and
QCA99x0.
Tested on: QCA9984, QCA4019
FW version: 10.4-3.9.0.2-00044
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
MSA memory region caries the hw descriptors information.
Dump MSA region in core dump as this is very helpful in debugging
hw issues.
Testing: Tested on WCN3990 HW
Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace code of the following form:
sizeof(*ce_hdr) + CE_COUNT * sizeof(ce_hdr->entries[0])
with:
struct_size(ce_hdr, entries, CE_COUNT)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Commit 25733c4e67 ("ath10k: pci: use mutex for diagnostic window CE
polling") introduced a regression where we try to sleep (grab a mutex)
in an atomic context:
[ 233.602619] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
[ 233.602626] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[ 233.602636] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc2 #4
[ 233.602642] Hardware name: Google Scarlet (DT)
[ 233.602647] Call trace:
[ 233.602663] dump_backtrace+0x0/0x11c
[ 233.602672] show_stack+0x20/0x28
[ 233.602681] dump_stack+0x98/0xbc
[ 233.602690] ___might_sleep+0x154/0x16c
[ 233.602696] __might_sleep+0x78/0x88
[ 233.602704] mutex_lock+0x2c/0x5c
[ 233.602717] ath10k_pci_diag_read_mem+0x68/0x21c [ath10k_pci]
[ 233.602725] ath10k_pci_diag_read32+0x48/0x74 [ath10k_pci]
[ 233.602733] ath10k_pci_dump_registers+0x5c/0x16c [ath10k_pci]
[ 233.602741] ath10k_pci_fw_crashed_dump+0xb8/0x548 [ath10k_pci]
[ 233.602749] ath10k_pci_napi_poll+0x60/0x128 [ath10k_pci]
[ 233.602757] net_rx_action+0x140/0x388
[ 233.602766] __do_softirq+0x1b0/0x35c
[...]
ath10k_pci_fw_crashed_dump() is called from NAPI contexts, and firmware
memory dumps are retrieved using the diag memory interface.
A simple reproduction case is to run this on QCA6174A /
WLAN.RM.4.4.1-00132-QCARMSWP-1, which happens to be a way to b0rk the
firmware:
dd if=/sys/kernel/debug/ieee80211/phy0/ath10k/mem_value bs=4K count=1
of=/dev/null
(NB: simulated firmware crashes, via debugfs, don't trigger firmware
dumps.)
The fix is to move the crash-dump into a workqueue context, and avoid
relying on 'data_lock' for most mutual exclusion. We only keep using it
here for protecting 'fw_crash_counter', while the rest of the coredump
buffers are protected by a new 'dump_mutex'.
I've tested the above with simulated firmware crashes (debugfs 'reset'
file), real firmware crashes (the 'dd' command above), and a variety of
reboot and suspend/resume configurations on QCA6174A.
Reported here:
http://lkml.kernel.org/linux-wireless/20190325202706.GA68720@google.com
Fixes: 25733c4e67 ("ath10k: pci: use mutex for diagnostic window CE polling")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use SPDX identifiers everywhere in ath10k.
Makefile was incorrectly marked in commit b24413180f ("License cleanup: add
SPDX GPL-2.0 license identifier to files with no license"), fix that as well.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wow pause iface config controls the PCI D0/D3-WOW cases for pcie
bus state. Firmware does not expects WOW_IFACE_PAUSE_ENABLED config
for bus/link that cannot be suspended ex:snoc and does not trigger
common subsystem shutdown.
Disable interface pause wow config for integrated chipset(WCN3990)
for correct WOW configuration in the firmware.
Testing:
Tested on WCN3990 HW.
Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ar->target_version is same for QCA99x0, QCA4019, QCA9888
and QCA9984, this ended up in assigning the wrong hw_mem_layouts.
This patch adds additional hw_rev check to assign correct
hw_mem_layouts.
Tested on:
QCA4019 firmware 10.4-3.2.1.1-00017
QCA9984 firmware 10.4-3.5.3-00057
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch adds firmware crash memory dump support for QCA4019.
Tested on:
QCA4019 firmware 10.4-3.2.1.1-00017
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch adds firmware crash memory dump support for QCA9888 and QCA99X0.
Tested on:
QCA9888 firmware 10.4-3.5.3-00053
QCA99X0 firmware 10.4.1.00030-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
QCA9984/QCA99X0/QCA4019 chipsets have 8 memory regions, dump all of them to the
firmware coredump file. Some of the regions need to be read using ioread() so
add new region types for them.
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
[kvalo: refactoring etc]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1
are less than the actual value, some coredump contents are missed.
To fix it, change the length from 0x90000 to 0xa8000.
Fixes: 703f261dd7 ("ath10k: add memory dump support for QCA6174/QCA9377")
Signed-off-by: Yu Wang <yyuwang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Add memory dump to the firmware crash data file which is provided to user space
via devcoredump interface. This makes it easier for firmware engineers to debug
firmware crashes.
Due to increased memory consumption the memory dump is disabled by default. To
enable it make sure that bit 3 is set in coredump_mask module parameter:
modprobe ath10k_core coredump_mask=0xffffffff
When RAMDUMP is enabled a buffer for the dump is allocated with vmalloc during
device probe. The actual memory layout is different in hardware versions and
the layouts are defined in coredump.c. The memory is split to regions and, to
get even finegrained control of what to copy, the region can split to smaller
sections as not all registers are readable (which could cause the whole system
to stall).
Signed-off-by: Alan Liu <alanliu@qca.qualcomm.com>
[kvalo@qca.qualcomm.com: refactoring and cleanup]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
For memory dump support (it consumes quite a lot of memory) we need to control
what is exactly stored to the crash dump. Add a module parameter call
coredump_mask to do that. It's a bit mask of these values:
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_CE_DATA = 1,
ATH10K_FW_CRASH_DUMP_MAX,
};
For example, if we only want to store CE_DATA we would enable bit 2:
modprobe ath10k_core coredump_mask=0x2
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Now coredump is totally separate from debug.c and doesn't depend on
CONFIG_ATH10K_DEBUGFS anymore, only on CONFIG_DEV_COREDUMP. Also remove
leftovers from the removed debugfs file support.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In preparation to add RAM dump support. No functional changes, only moving code
and renaming function names.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
