On 2020-11-13 19:08, Carl Huang wrote:
On 2020-11-13 16:17, Pavel Procopiuc wrote:
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
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.
Checked some logs. Looks when the error happens, the physical address
are
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.
To guarantee ath11k doesn't get physical address below 32M, reserve some
more, for
example "memmap=12M\$20M".
