Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 31 Jan 2020 19:36:58 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     =?iso-8859-1?Q?J=F6rg?= Otte <jrg.otte@gmail.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Ard Biesheuvel <ardb@kernel.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
Subject: EFI boot crash regression (was: Re: 5.6-### doesn't boot)
Message-ID: <20200131183658.GA71555@gmail.com>
References: <CADDKRnANovPM5Xvme7Ywg8KEMUyP-gB0M-ufxKD8pw0gNwtFag@mail.gmail.com>
 <CAHk-=wjOXE4cqFOdtSymYnMMayZq8Lv7qDy-6BzCs=2=8HcoBA@mail.gmail.com>
 <20200131064327.GB130017@gmail.com>
 <CADDKRnATVt9JjgV+dAZDH9C3=goJ5=TzdZ8EJMjT8tKP+Uhezw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADDKRnATVt9JjgV+dAZDH9C3=goJ5=TzdZ8EJMjT8tKP+Uhezw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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

Thanks,

	Ingo