On 2020-11-13 16:17, Pavel Procopiuc wrote:To guarantee ath11k doesn't get physical address below 32M, reserve some more, for
Op 12.11.2020 om 11:48 schreef David Hildenbrand:Checked some logs. Looks when the error happens, the physical address are
Trying to understand the code, it looks like there are always two rounds of reqests. The first one always fails ("requesting one big chunk of DMA memory"), the second one (providing multiple chunks of DMA memory) is supposed to work - and we do allocate memory.
In the *working* cases we have
Respond mem req failed, result: 1, err: 0
qmi failed to respond fw mem req:-22
...
chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
We don't fail in qmi_txn_wait() - second request w
In the *non-working* cases we have
Respond mem req failed, result: 1, err: 0
qmi failed to respond fw mem req:-22
...
qmi failed memory request, err = -110
qmi failed to respond fw mem req:-110
We fail in qmi_txn_wait(). We run into a timeout (ETIMEDOUT).
Can we bump up the timeout limit and see if things change? Maybe FW needs more time with other addresses.
I tried increasing ATH11K_QMI_WLANFW_TIMEOUT_MS 20 times to 100000
(i.e. 100 seconds) and it didn't have any positive effect, the second
error (-110) just came 100 seconds later and not 5.
very small. Its' between 20M - 30M.
So could you have a try to reserve the memory starting from 20M?
Add "memmap=10M\$20M" to your grub.cfg or edit in kernel parameters. so ath11k
can't allocate from these address.
Or you can try to reserve even larger memory starting from 20M.