All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carl Huang <cjhuang@codeaurora.org>
To: Pavel Procopiuc <pavel.procopiuc@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Kalle Valo <kvalo@codeaurora.org>,
	akpm@linux-foundation.org, ath11k@lists.infradead.org,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: Regression: QCA6390 fails with "mm/page_alloc: place pages to tail in __free_pages_core()"
Date: Fri, 13 Nov 2020 19:44:11 +0800	[thread overview]
Message-ID: <056b74d48fb735c69a6268b18184d7e8@codeaurora.org> (raw)
In-Reply-To: <f1f471905ea99ad9b9c8a8eeae616ff9@codeaurora.org>

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".

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Carl Huang <cjhuang@codeaurora.org>
To: Pavel Procopiuc <pavel.procopiuc@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
	akpm@linux-foundation.org, ath11k@lists.infradead.org,
	Kalle Valo <kvalo@codeaurora.org>
Subject: Re: Regression: QCA6390 fails with "mm/page_alloc: place pages to tail in __free_pages_core()"
Date: Fri, 13 Nov 2020 19:44:11 +0800	[thread overview]
Message-ID: <056b74d48fb735c69a6268b18184d7e8@codeaurora.org> (raw)
In-Reply-To: <f1f471905ea99ad9b9c8a8eeae616ff9@codeaurora.org>

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".

  reply	other threads:[~2020-11-13 11:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 10:32 PROBLEM: unable to get QCA6390 to work Pavel Procopiuc
2020-11-02 17:42 ` Kalle Valo
2020-11-02 18:21   ` Pavel Procopiuc
2020-11-02 21:14     ` Pavel Procopiuc
2020-11-03  6:56       ` Kalle Valo
2020-11-03 13:12         ` Pavel Procopiuc
2020-11-04  9:32           ` Pavel Procopiuc
2020-11-03 14:23         ` Kalle Valo
2020-11-03 21:01           ` Pavel Procopiuc
2020-11-04  9:12             ` Kalle Valo
2020-11-04 22:15               ` Pavel Procopiuc
2020-11-05  9:04                 ` Regression: QCA6390 fails with "mm/page_alloc: place pages to tail in __free_pages_core()" Kalle Valo
2020-11-05  9:04                   ` Kalle Valo
2020-11-05  9:47                   ` Pavel Procopiuc
2020-11-05  9:47                     ` Pavel Procopiuc
2020-11-05 10:42                   ` Vlastimil Babka
2020-11-05 10:42                     ` Vlastimil Babka
2020-11-05 10:45                     ` Pavel Procopiuc
2020-11-05 10:45                       ` Pavel Procopiuc
2020-11-05 11:13                     ` David Hildenbrand
2020-11-05 11:13                       ` David Hildenbrand
2020-11-05 12:55                       ` Pavel Procopiuc
2020-11-05 12:55                         ` Pavel Procopiuc
2020-11-05 20:23                         ` David Hildenbrand
2020-11-05 20:23                           ` David Hildenbrand
2020-11-06 17:32                           ` Pavel Procopiuc
2020-11-06 17:32                             ` Pavel Procopiuc
2020-11-06 20:41                             ` David Hildenbrand
2020-11-06 20:41                               ` David Hildenbrand
2020-11-11 19:23                       ` Kalle Valo
2020-11-11 19:23                         ` Kalle Valo
2020-11-11 20:41                         ` Pavel Procopiuc
2020-11-11 20:41                           ` Pavel Procopiuc
2020-11-12 10:48                           ` David Hildenbrand
2020-11-12 10:48                             ` David Hildenbrand
2020-11-13  8:17                             ` Pavel Procopiuc
2020-11-13  8:17                               ` Pavel Procopiuc
2020-11-13 11:08                               ` Carl Huang
2020-11-13 11:08                                 ` Carl Huang
2020-11-13 11:44                                 ` Carl Huang [this message]
2020-11-13 11:44                                   ` Carl Huang
2020-11-13 12:52                                 ` Pavel Procopiuc
2020-11-13 12:52                                   ` Pavel Procopiuc
2020-11-13 13:36                                   ` wi nk
2020-11-13 13:36                                     ` wi nk
2020-11-13 13:56                                     ` David Hildenbrand
2020-11-13 13:56                                       ` David Hildenbrand
2020-11-13 15:49                                       ` wi nk
2020-11-13 15:49                                         ` wi nk
2020-11-03  8:42       ` PROBLEM: unable to get QCA6390 to work Carl Huang
2020-11-03 14:12         ` Pavel Procopiuc

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=056b74d48fb735c69a6268b18184d7e8@codeaurora.org \
    --to=cjhuang@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=ath11k@lists.infradead.org \
    --cc=david@redhat.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pavel.procopiuc@gmail.com \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.