From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Sven Eckelmann <sven.eckelmann@openmesh.com>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
Adrian Chadd <adrian@freebsd.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"simon.wunderlich@openmesh.com" <simon.wunderlich@openmesh.com>
Subject: Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.
Date: Fri, 19 May 2017 09:02:08 +0000 [thread overview]
Message-ID: <8760gxw776.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <2107639.cIofNFgAHq@bentobox> (Sven Eckelmann's message of "Wed, 17 May 2017 12:06:01 +0200")
Sven Eckelmann <sven.eckelmann@openmesh.com> writes:
> On Montag, 1. Mai 2017 14:43:27 CEST Adrian Chadd wrote:
>> This reverts b057886524be060021e3cfad0ba8458c850330cd in 2015
>> which converted this allocation from dma_map_coherent() to
>> kzalloc() / dma_map_single().
>>=20
>> The current problem manifests when using later model NICs with larger
>> (>700KiB) scratch spaces in memory. Although the kzalloc call
>> succeeds, the software IOMMU TLB code (via dma_map_single()) panics
>> because it can't find 700KiB of linear physmem bounce buffers for DMA.
>> Now, this is a bit of a silly failure mode for the dma map API,
>> but it's what we currently have to play with.
> [....]
>>=20
>> Signed-off-by: Adrian Chadd <adrian@FreeBSD.org>
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 35 ++++++++++------------------=
-------
>> 1 file changed, 10 insertions(+), 25 deletions(-)
>
> Thanks for investigating this. This partial revert fixes following crash =
for
> me with QCA99X0 on amd64 with SWIOMMU:
>
> [ 9.167281] DMA: Out of SW-IOMMU space for 689816 bytes at device =
0000:02:00.0
> [ 9.174719] Kernel panic - not syncing: DMA: Random memory could b=
e DMA read
I recently got a Compex WLE1216V5-20 board and this patch also fixed a
similar crash for me on my HP x86_64 test laptop:
[ 840.491019] do_IRQ: 3.82 No irq handler for vector
[ 840.965049] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mod=
e 0 reset_mode 0
[ 841.094985] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x0100=
0000 chip_id 0x00000000 sub 168c:cafe
[ 841.095096] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1=
dfs 1 testmode 1
[ 841.095603] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.4-00082 api 5 f=
eatures no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 f301=
de65
[ 842.518071] ath10k_pci 0000:02:00.0: board_file api 2 bmi_id 0:1 crc32 7=
51efba1
[ 845.220186] ath10k_pci 0000:02:00.0: swiotlb buffer is full (sz: 1172264=
bytes)
[ 845.220478] ath10k_pci 0000:02:00.0: DMA: Out of SW-IOMMU space for 1172=
264 bytes
[ 845.220506] Kernel panic - not syncing: DMA: Random memory could be DMA =
accessed#012[ 845.220506]=20
[ 845.220532] CPU: 0 PID: 116 Comm: kworker/u16:4 Tainted: G E =
4.11.0-wt-ath+ #336
[ 845.220554] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 6=
8CDD Ver. F.04 01/27/2010
[ 845.220600] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work=
[ath10k_core]
[ 845.220626] Call Trace:
[ 845.220656] dump_stack+0x85/0xc2
[ 845.220684] panic+0xda/0x228
[ 845.220719] swiotlb_full+0x88/0xa0
[ 845.220746] swiotlb_map_page+0x214/0x280
[ 845.220785] ath10k_wmi_event_service_ready_work+0x3f2/0x7d0 [ath10k_cor=
e]
[ 845.220812] ? swiotlb_map_sg_attrs+0x140/0x140
[ 845.220858] process_one_work+0x23b/0x7d0
[ 845.221093] worker_thread+0x4e/0x4a0
[ 845.221126] kthread+0x117/0x150
[ 845.221149] ? process_one_work+0x7d0/0x7d0
[ 845.221175] ? kthread_create_on_node+0x40/0x40
[ 845.221205] ret_from_fork+0x31/0x40
[ 845.221314] Kernel Offset: 0xb000000 from 0xffffffff81000000 (relocation=
range: 0xffffffff80000000-0xffffffffbfffffff)
--=20
Kalle Valo=
next prev parent reply other threads:[~2017-05-19 9:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-01 21:43 [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory Adrian Chadd
[not found] ` <CAHjFwoAr6Tjh=Zpr_JhEp_-g_0XJ+LDUagsfJh=vqseqzBC1Pw@mail.gmail.com>
2017-05-11 3:55 ` Kalle Valo
2017-05-11 4:02 ` Su Kang Yin
2017-05-11 4:10 ` Kalle Valo
2017-05-17 10:06 ` Sven Eckelmann
2017-05-19 9:02 ` Kalle Valo [this message]
2017-05-19 9:10 ` Kalle Valo
2017-05-31 11:15 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760gxw776.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=adrian@freebsd.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=simon.wunderlich@openmesh.com \
--cc=sven.eckelmann@openmesh.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).