ATH10K Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: Failure to allocate large memory blocks upon firmware crash
Date: Fri, 21 Mar 2014 10:54:28 +0200	[thread overview]
Message-ID: <87pplgaq4b.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAHqTa-3=VZr2-S63HXEX++Y5BvPRuUTKgB_nKhpCCUYD-nGe+A@mail.gmail.com> (Avery Pennarun's message of "Wed, 19 Mar 2014 22:42:06 -0400")

Hi Avery,

thanks again for the excellent analysis!

Avery Pennarun <apenwarr@gmail.com> writes:

> However, when the firmware crashes, I'm sometimes seeing a followup
> memory allocation failure like this:
>
> ath10k: could not suspend target (-11)
> <6>[30094.735100] : ieee80211 phy1: Hardware restart was requested
> <4>[30094.995413] : kworker/0:1: page allocation failure: order:4, mode:0x20
> <4>[30094.995427] : Backtrace:

[...]

> <3>[30095.077634] : ath10k: Failed to initialize CE src ring for ID: 4 (-12)
> <3>[30095.077646] : ath10k: failed to initialize CE for pipe: 4
> <3>[30095.077678] : ath10k: failed to initialize CE: -1
> <4>[30095.077692] : ath10k: failed to power up target using warm reset
> (-1), trying cold reset
> <7>[30095.165692] z: 03/19/14 09:18:24.116 cap(1):Warning-Unexpected
> packet[297]-pld:{843f6a2191e10147 aa294ff5363573ea 86e610a162a190b4
> 13c096a8349fe599}
> <1>[30095.305945] : Unable to handle kernel NULL pointer dereference
> at virtual address 00000139
> <1>[30095.312742] : pgd = 84004000
> <1>[30095.312755] : [00000139] *pgd=00000000

Ouch!

> Someone at work helpfully diagnosed it as follows.  Is there a plan to
> update to the new DMA API

Does this refer to using dma_alloc_coherent() & co? Yes, we should do
that.

> and/or use smaller block allocations

For this I'm not that sure. I guess it would be nice to have, but not so
important? Maybe for hotplugging this would be important?

> and/or allocate the memory areas at startup time and never free them?

Well, we should free them during remove ;) But yeah, we really should do
that as well.

> The secondary issue here (and what is causing the kernel panic)
> is that a tasklet is still running & referencing memory that
> was torn down when the reset failed.  My sources don't match
> yours, so I can't see what is exactly happening.

This is also a problem we need to investigate. Do you have any more info
where the null pointer dereference happened?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

      parent reply	other threads:[~2014-03-21  8:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20  2:42 Failure to allocate large memory blocks upon firmware crash Avery Pennarun
2014-03-21  8:39 ` Kalle Valo
2014-03-21  8:54 ` Kalle Valo [this message]

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=87pplgaq4b.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=apenwarr@gmail.com \
    --cc=ath10k@lists.infradead.org \
    /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