On Mon, 29 Jun, at 01:10:52AM, Tom Yan wrote: > My motherboard is ASUS H87-PRO which has UEFI BIOS. The kernel gives > the following error on every boot: > > Ignoring BGRT: invalid status 0 (expected 1) > > This happens when the "Boot Logo" BIOS option is set to "Auto" (AND > using a PCI-E display card, IIRC). According to the mobo's manual, > "Auto" means: > > "Automatically adjust the boot logo size according to Windows requirements." > > while the error will be gone if I set it to "Full Screen" (which makes > the boot logo look huge and ugly) or "Disabled" instead. > > The thing is nothing really goes wrong when I choose "Auto" except > from keep seeing that error. So could you make it accept/handle status > 0, or at least lower the log level of messages in efi-bgrt? I can see > that all of them make use of pr_err() and I wonder how important is > this BGRT thing. The rest of the error messages are quite important because they signal that the BGRT is somehow invalid, even though the firmware thinks it *is* valid. They are intended to catch buggy firmware and aid kernel developers in debugging. However, it probably does make sense to drop the pr_err() for ->status being zero though, because the firmware is explicitly telling us "The BGRT image is not being displayed". Josh, Matthew? Can you think of a reason that something like this wouldn't make sense? --- diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c index d7f997f7c26d..480f3911228e 100644 --- a/arch/x86/platform/efi/efi-bgrt.c +++ b/arch/x86/platform/efi/efi-bgrt.c @@ -51,8 +51,8 @@ void __init efi_bgrt_init(void) return; } if (bgrt_tab->status != 1) { - pr_err("Ignoring BGRT: invalid status %u (expected 1)\n", - bgrt_tab->status); + pr_debug("Ignoring BGRT: invalid status %u (expected 1)\n", + bgrt_tab->status); return; } if (bgrt_tab->image_type != 0) { -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html