Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935063AbcJUSUR (ORCPT ); Fri, 21 Oct 2016 14:20:17 -0400 Received: from mail-yw0-f176.google.com ([209.85.161.176]:33331 "EHLO mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934172AbcJUSUO (ORCPT ); Fri, 21 Oct 2016 14:20:14 -0400 MIME-Version: 1.0 In-Reply-To: <20161021070054.GA6301@gmail.com> References: <20161020122931.GD19876@codeblueprint.co.uk> <20161021070054.GA6301@gmail.com> From: Dan Williams Date: Fri, 21 Oct 2016 11:20:12 -0700 Message-ID: Subject: Re: 4.9-rc1 boot regression, ambiguous bisect result To: Ingo Molnar Cc: Matt Fleming , LKML , linux-efi@vger.kernel.org, Peter Jones , Ard Biesheuvel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2801 Lines: 64 On Fri, Oct 21, 2016 at 12:00 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Thu, Oct 20, 2016 at 8:22 AM, Dan Williams wrote: >> > On Thu, Oct 20, 2016 at 5:29 AM, Matt Fleming wrote: >> >> On Wed, 19 Oct, at 09:04:29PM, Dan Williams wrote: >> >>> Hi, >> >>> >> >>> I am currently unable to boot a Yoga 900 with latest mainline, but 4.8 boots. >> >>> >> >>> The symptom is a reboot before the video console is available. >> >>> >> >>> I bisected to commit 816e76129ed5 "efi: Allow drivers to reserve boot >> >>> services forever". However, that commit is known to be broken. The >> >>> proposed fix, commit 92dc33501bfb "x86/efi: Round EFI memmap >> >>> reservations to EFI_PAGE_SIZE", also exhibits the reboot problem. >> >>> >> >>> During the bisect some of the stopping points landed on commits that >> >>> caused the boot process to hang rather than cause a reboot. The >> >>> commits that resulted in a hang are marked "git bisect skip" in this >> >>> log: https://gist.github.com/djbw/1b501daa98192a42ae848f03bb59c30e >> >>> >> >>> I'll try treating those hangs as bad bisect results and re-run the >> >>> full bisect tomorrow. In the meantime I wonder if the bisect log >> >>> implicates a better regression candidate? >> >> >> >> Could you mail the dmesg output when booting a known working kernel >> >> with efi=debug ? >> > >> > Here it is: >> > >> > https://gist.github.com/djbw/cae05e721b159d5ad7b146d7a93f5fa2 >> >> I am able to build a kernel and boot the platform with the following >> set of reverts: >> >> Revert "x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE" >> Revert "x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data" >> Revert "efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()" >> Revert "efi: Allow drivers to reserve boot services forever" > > Could you please describe the bootup behavior after each revert? I.e. wild guess: > > vanilla kernel: > # spontaneous reboot > + Revert "x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE": > # spontaneous reboot > + Revert "x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data": > # hang > + Revert "efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()": > # hang > + Revert "efi: Allow drivers to reserve boot services forever": > == works > > ? In this case all but the last revert produce the same result, instant reboot after loading the kernel. I have not been able to pinpoint what changes that behavior to the hang conditions I saw mid-bisect. The first three reverts are just there to get the kernel to build again after reverting "efi: Allow drivers to reserve boot services forever"