lkml.org 
[lkml]   [2021]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Panic on ppc64le using kernel 5.13.0-rc3
    From
    Date
    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

    \
     
     \ /
      Last update: 2021-06-11 23:51    [W:3.078 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site