public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox