From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Bruno Goncalves <bgoncalv@redhat.com>
Cc: linux-kernel@vger.kernel.org, CKI Project <cki-project@redhat.com>
Subject: Re: Panic on ppc64le using kernel 5.13.0-rc3
Date: Fri, 11 Jun 2021 23:49:06 +0200 [thread overview]
Message-ID: <4434f245-db3b-c02a-36c4-0111a0dfb78d@rasmusvillemoes.dk> (raw)
In-Reply-To: <CA+QYu4rF6Bx5OwLzBSam_VXJ6gWqSjTocxTNxanfHuV5nZuzrA@mail.gmail.com>
On 11/06/2021 17.06, Bruno Goncalves wrote:
> On Fri, Jun 11, 2021 at 9:13 AM Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>>
>> On 10/06/2021 17.14, Bruno Goncalves wrote:
>>> On Thu, Jun 10, 2021 at 3:02 PM Rasmus Villemoes
>>> <linux@rasmusvillemoes.dk> wrote:
>>>>
>>>> On 10/06/2021 13.47, Bruno Goncalves wrote:
>>>>> Hello,
>>>>>
>>>>> We've observed in some cases kernel panic when trying to boot on
>>>>> ppc64le using a kernel based on 5.13.0-rc3. We are not sure if it
>>>>> could be related to patch
>>>>> https://lore.kernel.org/lkml/20210313212528.2956377-2-linux@rasmusvillemoes.dk/
>>>>>
>>>>
>>>> Thanks for the report. It's possible, but I'll need some help from you
>>>> to get more info.
>>>>
>>>> First, can you send me the .config?
>>>
>>> The .config is on
>>> https://s3.us-east-1.amazonaws.com/arr-cki-prod-datawarehouse-public/datawarehouse-public/2021/06/09/317881801/build_ppc64le_redhat:1332368174/kernel-block-ppc64le-d3f02e52f5548006f04358d407bbb7fe51255c41.config
>>
>> Thanks.
>>
>>>>
>>>>>
>>>>> [ 1.516075] wait_for_initramfs() called before rootfs_initcalls
>>>>
>>>> This is likely because you have CONFIG_UEVENT_HELPER_PATH set to some
>>>> non-empty path (/sbin/hotplug perhaps). This did get reported once before:
>>>>
>>>
>>> CONFIG_UEVENT_HELPER_PATH is not set. In the .config we have "#
>>> CONFIG_UEVENT_HELPER is not set"
>>
>> OK. Then I assume some quite early initcall does a request_module() or
>> request_firmware() (or similar). I don't think this matters - that call
>> would be done before the initramfs was unpacked with or without my
>> patch, so it won't find anything in the empty rootfs. It's just my patch
>> added a note. But just to figure out where that triggers, can you do
>>
>> - pr_warn_once("wait_for_initramfs() called before
>> rootfs_initcalls\n");
>> + WARN_ONCE(1, "wait_for_initramfs() called before
>> rootfs_initcalls\n");
>>
>> in init/initramfs.c.
>>
>
> I've managed to reproduce the panic with the patch.
>
> [ 1.498654] NIP [c0000000000137d4] wait_for_initramfs+0x94/0xa4
> [ 1.498661] LR [c0000000000137d0] wait_for_initramfs+0x90/0xa4
> [ 1.498668] Call Trace:
> [ 1.498671] [c000000027debd60] [c0000000000137d0]
> wait_for_initramfs+0x90/0xa4 (unreliable)
> [ 1.498680] [c000000027debdc0] [c000000000172fc8]
> call_usermodehelper_exec_async+0x178/0x2c0
> [ 1.498691] [c000000027debe10] [c00000000000d6ec]
> ret_from_kernel_thread+0x5c/0x70
Thanks, but unfortunately (and I should have known better) that doesn't
tell us who actually initated that call_usermodehelper - it's most
likely some request_module() call. But again, I don't think this is
related to the later crash.
>>>>> [ 1.764430] Initramfs unpacking failed: no cpio magic
>>>>
>>>> Whoa, that's not good. Did something scramble over the initramfs memory
>>>> while it was being unpacked? It's been .2 seconds since the start of the
>>>> unpacking, so it's unlikely the very beginning of the initramfs is corrupt.
>>>>
>>>> Can you try booting with initramfs_async=0 on the command line and see
>>>> if the kernel still crashes?
>
> Using initramfs_async=0 I was also able to reproduce the panic.
Hm, that's very interesting. Can you share the log for that as well?
And, perhaps asking a silly question, does the crash go away if you
revert e7cb072eb988e46295512617c39d004f9e1c26f8 ?
Thanks,
Rasmus
next prev parent reply other threads:[~2021-06-11 21:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 11:47 Panic on ppc64le using kernel 5.13.0-rc3 Bruno Goncalves
2021-06-10 13:02 ` Rasmus Villemoes
2021-06-10 15:14 ` Bruno Goncalves
2021-06-11 7:13 ` Rasmus Villemoes
2021-06-11 15:06 ` Bruno Goncalves
2021-06-11 21:49 ` Rasmus Villemoes [this message]
2021-06-14 5:47 ` Bruno Goncalves
2021-06-14 8:03 ` Bruno Goncalves
2021-06-14 8:11 ` Rasmus Villemoes
2021-06-15 3:20 ` Dave Young
2021-06-15 5:13 ` Dave Young
2021-06-15 5:13 ` Dave Young
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=4434f245-db3b-c02a-36c4-0111a0dfb78d@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=bgoncalv@redhat.com \
--cc=cki-project@redhat.com \
--cc=linux-kernel@vger.kernel.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 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.