lkml.org 
[lkml]   [2020]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Date
    SubjectRe: EFI boot crash regression (was: Re: 5.6-### doesn't boot)
    On Sat, 1 Feb 2020 at 16:35, Jörg Otte <jrg.otte@gmail.com> wrote:
    >
    > Am Fr., 31. Jan. 2020 um 19:48 Uhr schrieb Dan Williams
    > <dan.j.williams@intel.com>:
    > >
    > > On Fri, Jan 31, 2020 at 10:37 AM Ingo Molnar <mingo@kernel.org> wrote:
    > > >
    > > >
    > > > (Cc:ed Dan and Ard)
    > > >
    > > > * Jörg Otte <jrg.otte@gmail.com> wrote:
    > > >
    > > > > Am Fr., 31. Jan. 2020 um 07:43 Uhr schrieb Ingo Molnar <mingo@kernel.org>:
    > > > > >
    > > > > >
    > > > > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
    > > > > >
    > > > > > > On Thu, Jan 30, 2020 at 9:32 AM Jörg Otte <jrg.otte@gmail.com> wrote:
    > > > > > > >
    > > > > > > > my notebook doesn't boot with current kernel. Booting stops right after
    > > > > > > > displaying "loading initial ramdisk..". No further displays.
    > > > > > > > Also nothing is wriiten to the logs.
    > > > > > > >
    > > > > > > > last known good kernel is : vmlinuz-5.5.0-00849-gb0be0eff1a5a
    > > > > > > > first known bad kernel is : vmlinuz-5.5.0-01154-gc677124e631d
    > > > > > >
    > > > > > > It would be lovely if you can bisect a bit. But my merges in that
    > > > > > > range are all from Ingo:
    > > > > > >
    > > > > > > Ingo Molnar (7):
    > > > > > > header cleanup
    > > > > > > objtool updates
    > > > > > > RCU updates
    > > > > > > EFI updates
    > > > > > > locking updates
    > > > > > > perf updates
    > > > > > > scheduler updates
    > > > > >
    > > > > > If I had to guess then perhaps the EFI changes look the most dangerous
    > > > > > ones from these trees - but in principle most of these trees could
    > > > > > contain a boot crasher/hang bug.
    > > > > >
    > > > > > > but not having any messages at all makes it hard to guess where it
    > > > > > > would be.
    > > > > >
    > > > > > To improve debug output:
    > > > > >
    > > > > > Removing any 'fbcon' options in /boot/grub/grub.cfg and adding this to
    > > > > > the boot options might improve the debug output:
    > > > > >
    > > > > > earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn
    > > > > >
    > > > > > So for example if the relevant kernel boot entry in grub.cfg looks like
    > > > > > this:
    > > > > >
    > > > > > linux /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro splash $vt_handoff
    > > > > >
    > > > > > Then editing it to the following could in principle produce (much) more
    > > > > > verbose boot output:
    > > > > >
    > > > > > linux /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn $vt_handoff
    > > > > >
    > > > > > If this produces more output than just "loading initial ramdisk..' then a
    > > > > > photo of the hung screen would be sufficient, no need to transcribe it.
    > > > > >
    > > > > > > A few bisect runs would narrow it down a fair amount. Bisecting all the
    > > > > > > way would be even better, of course,
    > > > > >
    > > > > > Agreed!
    > > > > >
    > > > > > If compiling full kernels for bisections takes too long (for example
    > > > > > because the .config is from a distro kernel) then running "make
    > > > > > localmodconfig" to create a config tailored to the currently active
    > > > > > modules will cut down significantly on build time.
    > > > > >
    > > > > > Also, a warning: if the normal boot log contains spurious warnings then
    > > > > > the new 'panic_on_warn' option will cause additional trouble on good
    > > > > > kernels.
    > > > >
    > > > > It's bisected.
    > > > > The first bad commit is :
    > > > > 1db91035d01aa8bfa2350c00ccb63d629b4041ad
    > > > > efi: Add tracking for dynamically allocated memmaps
    > > >
    > > > Thanks a ton, that's very useful!
    > > >
    > > > I've Cc:-ed the EFI gents who are developing this code, maybe they'll
    > > > spot the bug.
    > >
    > > I'll take a look. Jörg, can you paste a full dmesg from a good boot?
    >
    > Here it is.
    >

    Hello Jörg,

    Could you please try whether the change below fixes the issue?

    diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
    index 59f7f6d60cf6..ae923ee8e2b4 100644
    --- a/arch/x86/platform/efi/efi.c
    +++ b/arch/x86/platform/efi/efi.c
    @@ -308,7 +308,7 @@ static void __init efi_clean_memmap(void)
    .phys_map = efi.memmap.phys_map,
    .desc_version = efi.memmap.desc_version,
    .desc_size = efi.memmap.desc_size,
    - .size = data.desc_size * (efi.memmap.nr_map -
    n_removal),
    + .size = efi.memmap.desc_size *
    (efi.memmap.nr_map - n_removal),
    .flags = 0,
    };
    \
     
     \ /
      Last update: 2020-02-01 17:03    [W:2.339 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site