From: Andrea Arcangeli <aarcange@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Guillaume Tucker <guillaume.tucker@collabora.com>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernelci-results-staging@groups.io,
"kernelci-results@groups.io" <kernelci-results@groups.io>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mike Rapoport <rppt@kernel.org>, Baoquan He <bhe@redhat.com>
Subject: Re: kernelci/staging-next bisection: sleep.login on rk3288-rock2-square #2286-staging
Date: Sun, 3 Jan 2021 15:09:14 -0500 [thread overview]
Message-ID: <X/Ikalm2CLln2alz@redhat.com> (raw)
In-Reply-To: <20210103134753.GC832698@linux.ibm.com>
Hello Mike,
On Sun, Jan 03, 2021 at 03:47:53PM +0200, Mike Rapoport wrote:
> Thanks for the logs, it seems that implicitly adding reserved regions to
> memblock.memory wasn't that bright idea :)
Would it be possible to somehow clean up the hack then?
The only difference between the clean solution and the hack is that
the hack intended to achieved the exact same, but without adding the
reserved regions to memblock.memory.
The comment on that problematic area says the reserved area cannot be
used for DMA because of some unexplained hw issue, and that doing so
prevents booting, but since the area got reserved, even with the clean
solution, it shouldn't have never been used for DMA?
So I can only imagine that the physical memory region is way more
problematic than just for DMA. It sounds like that anything that
touches it, including the CPU, will hang the system, not just DMA. It
sounds somewhat similar to the other e820 direct mapping issue on x86?
If you want to test the hack on the arm board to check if it boots you
can use the below commit:
https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/commit/?id=c3ea2633015104ce0df33dcddbc36f57de1392bc
Thanks,
Andrea
next prev parent reply other threads:[~2021-01-03 20:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5fd3e5d9.1c69fb81.f9e69.5028@mx.google.com>
2020-12-11 21:53 ` kernelci/staging-next bisection: sleep.login on rk3288-rock2-square #2286-staging Guillaume Tucker
2020-12-13 8:23 ` Mike Rapoport
2020-12-18 21:59 ` Guillaume Tucker
2021-01-03 13:47 ` Mike Rapoport
2021-01-03 20:09 ` Andrea Arcangeli [this message]
2021-01-05 9:13 ` Mike Rapoport
2021-01-12 10:53 ` Guillaume Tucker
2021-01-12 11:10 ` Guillaume Tucker
2021-01-12 12:06 ` Mike Rapoport
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=X/Ikalm2CLln2alz@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=guillaume.tucker@collabora.com \
--cc=kernelci-results-staging@groups.io \
--cc=kernelci-results@groups.io \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=sfr@canb.auug.org.au \
/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).