Re: kernelci/staging-next bisection: sleep.login on rk3288-rock2-square #2286-staging

From: Mike Rapoport <rppt@linux.ibm.com>
To: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: Andrea Arcangeli <aarcange@redhat.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:47:53 +0200	[thread overview]
Message-ID: <20210103134753.GC832698@linux.ibm.com> (raw)
In-Reply-To: <0633d44a-3796-8a1b-e5dc-99fc62aa4dc7@collabora.com>

On Fri, Dec 18, 2020 at 09:59:26PM +0000, Guillaume Tucker wrote:
> On 13/12/2020 08:23, Mike Rapoport wrote:
> > Hi Guillaume,
> > 
> > On Fri, Dec 11, 2020 at 09:53:46PM +0000, Guillaume Tucker wrote:
> >> Hi Mike,
> >>
> 
> OK, sorry for the delay.  I've built a kernel and booted it as
> you requested, and also found that the issue was due to this
> memory area defined in arch/arm/boot/dts/rk3288.dtsi:
> 
>         reserved-memory {
>                 #address-cells = <2>;
>                 #size-cells = <2>;
>                 ranges;
> 
>                 /*
>                  * The rk3288 cannot use the memory area above 0xfe000000
>                  * for dma operations for some reason. While there is
>                  * probably a better solution available somewhere, we
>                  * haven't found it yet and while devices with 2GB of ram
>                  * are not affected, this issue prevents 4GB from booting.
>                  * So to make these devices at least bootable, block
>                  * this area for the time being until the real solution
>                  * is found.
>                  */
>                 dma-unusable@fe000000 {
>                         reg = <0x0 0xfe000000 0x0 0x1000000>;
>                 };
>         };
> 
> So I've put a hack[1] on top of 950c37691925 to skip adding a
> node in memblock_enforce_memory_reserved_overlap() if the base
> address is 0xfe000000, which got the kernel booting.  Here's the
> console log:
> 
>   https://people.collabora.com/~gtucker/tmp/2966825.txt
> 
> and the full test job details, if this helps:
> 
>   https://lava.collabora.co.uk/scheduler/job/2966825
> 
> 
> I haven't really looked much further than that, but I'll be
> available on Monday to help run other tests if needed.

Sorry for the delay, I was mostly offline for the last three weeks.

Thanks for the logs, it seems that implicitly adding reserved regions to
memblock.memory wasn't that bright idea :)

> Thanks,
> Guillaume
> 
> [1] https://people.collabora.com/~gtucker/tmp/2966825.patch

-- 
Sincerely yours,
Mike.