From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85940C282CB for ; Tue, 5 Feb 2019 23:27:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 48E0D2175B for ; Tue, 5 Feb 2019 23:27:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lgWw5V0D" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728868AbfBEX1t (ORCPT ); Tue, 5 Feb 2019 18:27:49 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:33140 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727320AbfBEX1t (ORCPT ); Tue, 5 Feb 2019 18:27:49 -0500 Received: by mail-it1-f193.google.com with SMTP id q78so667693itc.0 for ; Tue, 05 Feb 2019 15:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GLeKVjJIKgtVW/xFjuyCAq3fG6BKeem4C7RvlN9NR0Q=; b=lgWw5V0DCAg1IlFxY2xNQpyMiitv3caBQ95xcGidSD2vXzwA4q5EUdYmmc6liDJwCJ iPXBMow0Ooa4zHYzEIXP1yBkd4G5ckX5VAw/1nT8U+sl/cVJP9X83y6XGDXtQZNxo5bt apACVzroo9M3u9NajmbpSuaHsmnCNIzr7Jvgrpjwn6mH4M0jfFW30t5CLSNqL14DcO9q 5PpPn4tGVuIOX3z768y2YZCMawbKUpKBaWrLRGZqZRyBUV+uzxZFMrQnWi9QhDYyJ2qg KwT5ne7N+LHUN8CzbwD+44DWADFUY/nVcVomXos8WqIJIY/Krm4SJC532bDu9SyXqbz0 kjDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GLeKVjJIKgtVW/xFjuyCAq3fG6BKeem4C7RvlN9NR0Q=; b=d34eUBW98YuNK8V9dvsTvbrTcOXVAPngj4i0H1MNtlM4VbvpJS6nVNnCGLBW92dNLK zihMO2EgF+r3iGCYEtY+4iCzMYt2udXUSvpqWMMUtn+pWSbugsFFN+1hN8snQfSWQFZt 7VbJc5ZDQXsgqnZ/HgR0QGov3M6JE3WIL8jYtp6/9SaFWDk/RHpvOv+AtGcrQ8ZFsoTC F1z9q4E+YOH88ewj1foxk6tj0lA8pDBmKdWxro8LD19fKIzRP+3DZWo4uXv7J9TpK8Y3 y4cNlFgHYrcEGHpGnrXa4kR7t6K/k7JPaCqlRXaVtKXGdzW3IjxDnZVS83YN/kiqqwf6 FWYw== X-Gm-Message-State: AHQUAuaxym7mr9p/mzqEnr7BkXthOmEzKRbL7nqvf2h/cFJJsfXlhCao 5ST5qwpnomgofKyjCB9FQWcnzPRNk/GRmaLDzTrTQA== X-Google-Smtp-Source: AHgI3IYQp0x7WFuMGog9T0x9DXeX5b+4vit1nEufR1E5glhGgyUOKY+DvTiRsWDtIcxUR1kMFCf6xm6hT0mZypVPRvc= X-Received: by 2002:a5e:d609:: with SMTP id w9mr2317319iom.170.1549409267816; Tue, 05 Feb 2019 15:27:47 -0800 (PST) MIME-Version: 1.0 References: <20190202094119.13230-1-ard.biesheuvel@linaro.org> <20190202094119.13230-11-ard.biesheuvel@linaro.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 5 Feb 2019 23:27:41 +0000 Message-ID: Subject: Re: [PATCH 10/10] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered To: "Ghannam, Yazen" Cc: "linux-efi@vger.kernel.org" , Ingo Molnar , Thomas Gleixner , "linux-kernel@vger.kernel.org" , AKASHI Takahiro , Alexander Graf , Bjorn Andersson , Borislav Petkov , Heinrich Schuchardt , Jeffrey Hugo , Lee Jones , Leif Lindholm , Linus Torvalds , Peter Jones , Peter Zijlstra , Sai Praneeth Prakhya , "Lendacky, Thomas" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Feb 2019 at 19:07, Ghannam, Yazen wrote: > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org > owner@vger.kernel.org> On Behalf Of Ard Biesheuvel > > Sent: Saturday, February 2, 2019 3:41 AM > > To: linux-efi@vger.kernel.org; Ingo Molnar ; Thomas > > Gleixner > > Cc: Ard Biesheuvel ; linux-kernel@vger.kernel.org; > > AKASHI Takahiro ; Alexander Graf > > ; Bjorn Andersson ; Borislav > > Petkov ; Heinrich Schuchardt ; Jeffrey > > Hugo ; Lee Jones ; Leif > > Lindholm ; Linus Torvalds > foundation.org>; Peter Jones ; Peter Zijlstra > > ; Sai Praneeth Prakhya > > > > Subject: [PATCH 10/10] acpi: bgrt: parse BGRT to obtain BMP address before it > > gets clobbered > > > > The bitmap left in the framebuffer by the firmware is described by an > > ACPI table called "BGRT", which describes the size, pixel format and > > the address of a BMP image in memory. While the BGRT ACPI table is > > guaranteed to reside in a "ACPI reclaim" memory region, which is > > never touched by Linux. The BMP image, however, typically resides > > in EFI Boot Services Memory, which may have been overwritten by the > > time the BGRT discovery routine runs. > > > > So instead, drop the handling from the ACPI init code, and call the > > BGRT parsing code immediately after going over the EFI configuration > > table array, at which time no memory has been touched yet except for > > the .data/.bss regions covered by the static kernel image. > > > > Unfortunately, this involves a non-trivial amount of ACPI entry > > point and root table parsing, but we cannot rely on the normal > > ACPI infrastructure yet this early in the boot. > > > > Also note that we cannot take the 'acpi_disabled' global variable > > into account, since it may not have assumed the correct value yet > > (on arm64, the default value is '1' which is overridden to '0' if > > no DT description has been made available by the firmware) > > > > Cc: Peter Jones > > Signed-off-by: Ard Biesheuvel > > --- > > Hi Ard, et. al., > > I'm trying out tip/master and I find that my system panics early during boot. Reverting > this patch seems to resolve the issue. Please see the trace below. > > I've started debugging, but I'm not familiar with this code. Please let me know if you > have any ideas or if there's anything you'd like me to try. > Hi Yazen, Thanks for the report, you are the second person to flag this issue, so in the mean time, I have asked Ingo to drop it from the efi/core queue, and so the patch will be gone from -next as soon as it refreshes. I'll cc you on the updated version of this patch once I get around to looking into it, which will probably be around early next week. Thanks, Ard. > > [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x0000000000000b40 bytes below 0x0000000000000000. > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc5-merged-bases+ #101 > [ 0.000000] Call Trace: > [ 0.000000] dump_stack+0x63/0x85 > [ 0.000000] panic+0xfe/0x2a4 > [ 0.000000] memblock_alloc_base+0x33/0x35 > [ 0.000000] memblock_phys_alloc+0x10/0x12 > [ 0.000000] efi_memmap_alloc+0x62/0x65 > [ 0.000000] efi_arch_mem_reserve+0x10e/0x194 > [ 0.000000] efi_mem_reserve+0x31/0x36 > [ 0.000000] ? efi_mem_reserve+0x31/0x36 > [ 0.000000] efi_bgrt_init+0x2c6/0x2e0 > [ 0.000000] efi_config_parse_tables+0x1b2/0x1dd > [ 0.000000] efi_config_init+0x7b/0x9f > [ 0.000000] ? efi_config_init+0x7b/0x9f > [ 0.000000] efi_init+0x366/0x465 > [ 0.000000] ? 0xffffffff87800000 > [ 0.000000] setup_arch+0x42f/0xcc9 > [ 0.000000] ? printk+0x52/0x6e > [ 0.000000] start_kernel+0x6c/0x516 > [ 0.000000] x86_64_start_reservations+0x24/0x26 > [ 0.000000] x86_64_start_kernel+0x74/0x77 > [ 0.000000] secondary_startup_64+0xa4/0xb0 > [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x0000000000000b40 bytes below 0x0000000000000000. ]--- >