All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Tucker <guillaume.tucker@collabora.com>
To: Mike Rapoport <rppt@linux.ibm.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: Fri, 18 Dec 2020 21:59:26 +0000	[thread overview]
Message-ID: <0633d44a-3796-8a1b-e5dc-99fc62aa4dc7@collabora.com> (raw)
In-Reply-To: <20201213082314.GA198221@linux.ibm.com>

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,
>>
>> Please see the bisection report below about a boot failure on
>> rk3288 with next-20201210.
>>
>> Reports aren't automatically sent to the public while we're
>> trialing new bisection features on kernelci.org but this one
>> looks valid.
>>
>> There's nothing in the serial console log, probably because it's
>> crashing too early during boot.  This was confirmed on two rk3288
>> platforms on kernelci.org: rk3288-veyron-jaq and
>> rk3288-rock2-square.  There's no clear sign about other platforms
>> being impacted.
>>
>> If this looks like something you want to investigate but you
>> don't have a platform at hand to reproduce it, please let us know
>> if you would like the test to be re-run on kernelci.org with some
>> debug config turned on, or if you have a fix to try.
> 
> I'd apprciate if you can build a working kernel with
> CONFIG_DEBUG_MEMORY_INIT=y and run it with 
> 
> 	memblock=debug mminit_loglevel=4
> 
> in the command line.
> 
> If I understand correctly, DEBUG_LL is not an option for these platforms
> so if earlyprintk didn't display the log there is not much to do about
> it.

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.

Thanks,
Guillaume

[1] https://people.collabora.com/~gtucker/tmp/2966825.patch

  reply	other threads:[~2020-12-18 22:01 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 [this message]
2021-01-03 13:47       ` Mike Rapoport
2021-01-03 20:09         ` Andrea Arcangeli
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=0633d44a-3796-8a1b-e5dc-99fc62aa4dc7@collabora.com \
    --to=guillaume.tucker@collabora.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.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 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.