All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Jörg Otte" <jrg.otte@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: 5.6-### doesn't boot
Date: Fri, 31 Jan 2020 07:43:27 +0100	[thread overview]
Message-ID: <20200131064327.GB130017@gmail.com> (raw)
In-Reply-To: <CAHk-=wjOXE4cqFOdtSymYnMMayZq8Lv7qDy-6BzCs=2=8HcoBA@mail.gmail.com>


* 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.

Thanks,

	Ingo

  parent reply	other threads:[~2020-01-31  6:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 17:32 5.6-### doesn't boot Jörg Otte
2020-01-30 18:07 ` Linus Torvalds
2020-01-30 18:22   ` Andy Lutomirski
2020-01-31  6:43   ` Ingo Molnar [this message]
2020-01-31 10:35     ` Jörg Otte
2020-01-31 18:36       ` EFI boot crash regression (was: Re: 5.6-### doesn't boot) Ingo Molnar
2020-01-31 18:48         ` Dan Williams
2020-02-01 15:35           ` Jörg Otte
2020-02-01 16:02             ` Ard Biesheuvel
2020-02-02  9:22               ` Ingo Molnar
2020-02-02  9:32                 ` Ard Biesheuvel
2020-02-02 11:07                 ` Jörg Otte
2020-02-03  7:45                   ` Ingo Molnar
2020-02-01 21:29             ` Dan Williams
2020-02-01  9:45         ` [TEST PATCH RFC] Revert the EFI leak fixes for now (was: Re: EFI boot crash regression (was: Re: 5.6-### doesn't boot)) Ingo Molnar
2020-02-01 16:23           ` Dan Williams
     [not found]         ` <CAKv+Gu-oPrM7oh-oTbpQsUmXcYvp9KxjXFb3DUGk__qu59rdBQ@mail.gmail.com>
2020-02-01 21:44           ` EFI boot crash regression (was: Re: 5.6-### doesn't boot) Dan Williams
2020-02-01 21:49             ` Ard Biesheuvel
2020-02-01 22:31               ` Dan Williams
2020-02-01 22:36                 ` Ard Biesheuvel

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=20200131064327.GB130017@gmail.com \
    --to=mingo@kernel.org \
    --cc=jrg.otte@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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.