stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: David Hildenbrand <david@redhat.com>, arm-soc <arm@kernel.org>,
	SoC Team <soc@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	stable <stable@vger.kernel.org>,
	Pavel Procopiuc <pavel.procopiuc@gmail.com>,
	Vlastimil Babka <vbabka@suse.cz>, wi nk <wink@technolu.st>
Subject: Re: [PATCH] ARM: dts: ux500: Reserve memory carveouts
Date: Mon, 14 Dec 2020 12:02:23 +0200	[thread overview]
Message-ID: <877dpk3du8.fsf@codeaurora.org> (raw)
In-Reply-To: <CACRpkdZp+gnJAo02OJkiN_KUX3bOPc2vzQGWHLZF2hQHvuQQkw@mail.gmail.com> (Linus Walleij's message of "Mon, 14 Dec 2020 10:27:28 +0100")

Linus Walleij <linus.walleij@linaro.org> writes:

> On Mon, Dec 14, 2020 at 10:21 AM David Hildenbrand <david@redhat.com> wrote:
>
>> > ARM SoC folks: please apply this directly for fixes.
>>
>> Can we come up with a Fixes: tag or has this been broken forever?
>> (assuming modern boot loaders)
>
> It's been broken forever :/
>
>> > David: just FYI if you run into more of these type of
>> > regressions. Actually the patch is unintentionally good
>> > at smoking out other bugs :D
>>
>> Thanks for CCing - I'm adding some people that ran into similar issues,
>> but not sure if the other bugreports are related (or have similar root
>> causes).
>
> Yeah we first were convinced there was something wrong with
> the patch you made but I read it over and over again and there
> is nothing wrong with it at all. It just alters the behaviour pattern of
> memory management in some apparently drastic ways.
>
> After a lot of silent crashes I finally got an external abort with
> a reasonable backtrace showing the PTE pointing to this
> modem memory and then we figured it out.

We had similar experiences with ath11k (Wi-Fi 6) and QCA6390 firmware.
So indeed commit 7fef431be9c9 ("mm/page_alloc: place pages to tail in
__free_pages_core()") is a great way to catch odd firmware or hardware
problems, which most likely would have gone unnoticed otherwise and
users would have end up experiencing random crashes.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2020-12-14 10:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-13 22:55 [PATCH] ARM: dts: ux500: Reserve memory carveouts Linus Walleij
2020-12-14  9:21 ` David Hildenbrand
2020-12-14  9:27   ` Linus Walleij
2020-12-14 10:02     ` Kalle Valo [this message]
     [not found] ` <161073123818.625238.784153877114947970.b4-ty@arndb.de>
2021-01-15 22:21   ` Linus Walleij

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=877dpk3du8.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=arm@kernel.org \
    --cc=david@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pavel.procopiuc@gmail.com \
    --cc=soc@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --cc=wink@technolu.st \
    /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).