Hi,
Fedora received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1384238
of a bootup failure with stable 4.7.6. efi=noruntime fixed the bootup problem.
1297667083d5442aafe3e337b9413bf02b114edb was linked as the cause
of the problem.
x86/efi: Only map RAM into EFI page tables if in mixed-mode
Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
multi-terabyte HP machine results in boot crashes, because the EFI
region mapping functions loop forever while trying to map those
regions describing RAM.
While this patch doesn't fix the underlying hang, there's really no
reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
when mixed-mode is not in use at runtime.
Reported-by: Waiman Long <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
CC: Theodore Ts'o <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Scott J Norton <[email protected]>
Cc: Douglas Hatch <[email protected]>
Cc: <[email protected]> # v4.6+
Signed-off-by: Matt Fleming <[email protected]>
I made a request in the bugzilla for the reporter to
give a bootlog with efi=debug which I'm still waiting on.
Any ideas?
Thanks,
Laura
On 10/19/2016 01:04 PM, Laura Abbott wrote:
> Hi,
>
> Fedora received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1384238
> of a bootup failure with stable 4.7.6. efi=noruntime fixed the bootup problem.
> 1297667083d5442aafe3e337b9413bf02b114edb was linked as the cause
> of the problem.
>
>
> x86/efi: Only map RAM into EFI page tables if in mixed-mode
>
> Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
> multi-terabyte HP machine results in boot crashes, because the EFI
> region mapping functions loop forever while trying to map those
> regions describing RAM.
>
> While this patch doesn't fix the underlying hang, there's really no
> reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
> when mixed-mode is not in use at runtime.
>
> Reported-by: Waiman Long <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> CC: Theodore Ts'o <[email protected]>
> Cc: Arnd Bergmann <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Scott J Norton <[email protected]>
> Cc: Douglas Hatch <[email protected]>
> Cc: <[email protected]> # v4.6+
> Signed-off-by: Matt Fleming <[email protected]>
>
> I made a request in the bugzilla for the reporter to
> give a bootlog with efi=debug which I'm still waiting on.
>
> Any ideas?
>
> Thanks,
> Laura
dmesg with efi=debug from the reporter is attached
On Wed, 19 Oct, at 02:13:00PM, Laura Abbott wrote:
> On 10/19/2016 01:04 PM, Laura Abbott wrote:
> >Hi,
> >
> >Fedora received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1384238
> >of a bootup failure with stable 4.7.6. efi=noruntime fixed the bootup problem.
> >1297667083d5442aafe3e337b9413bf02b114edb was linked as the cause
> >of the problem.
> >
> >
> >x86/efi: Only map RAM into EFI page tables if in mixed-mode
> >
> >Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
> >multi-terabyte HP machine results in boot crashes, because the EFI
> >region mapping functions loop forever while trying to map those
> >regions describing RAM.
> >
> >While this patch doesn't fix the underlying hang, there's really no
> >reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
> >when mixed-mode is not in use at runtime.
> >
> >Reported-by: Waiman Long <[email protected]>
> >Cc: Ard Biesheuvel <[email protected]>
> >Cc: Borislav Petkov <[email protected]>
> >Cc: Linus Torvalds <[email protected]>
> >CC: Theodore Ts'o <[email protected]>
> >Cc: Arnd Bergmann <[email protected]>
> >Cc: Greg Kroah-Hartman <[email protected]>
> >Cc: Scott J Norton <[email protected]>
> >Cc: Douglas Hatch <[email protected]>
> >Cc: <[email protected]> # v4.6+
> >Signed-off-by: Matt Fleming <[email protected]>
> >
> >I made a request in the bugzilla for the reporter to
> >give a bootlog with efi=debug which I'm still waiting on.
> >
> >Any ideas?
> >
> >Thanks,
> >Laura
>
> dmesg with efi=debug from the reporter is attached
> [ 0.000000] DMI: Hewlett-Packard Compaq CQ58 Notebook PC/188B, BIOS F.36 06/07/2013
Hmm.. this is a fairly old machine, what kernel versions has the
reporter successfully run on it? The code that was nop'd out in the
above commit for the native case only came into existence in v4.6.
The fact that booting with efi=old_map does *not* seem to result in a
booting kernel is very suspicious. Could you ask them to double-check?
Maybe try this patch too on v4.7.6.
---
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 964c7022d31d..b07183c6b470 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -244,9 +244,12 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
* text and allocate a new stack because we can't rely on the
* stack pointer being < 4GB.
*/
- if (!IS_ENABLED(CONFIG_EFI_MIXED) || efi_is_native())
+ if (!IS_ENABLED(CONFIG_EFI_MIXED))
return 0;
+ if (efi_is_native())
+ goto map_text;
+
/*
* Map all of RAM so that we can access arguments in the 1:1
* mapping when making EFI runtime calls.
@@ -273,6 +276,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
efi_scratch.phys_stack = virt_to_phys(page_address(page));
efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
+map_text:
npages = (_etext - _text) >> PAGE_SHIFT;
text = __pa(_text);
pfn = text >> PAGE_SHIFT;
On 10/20/2016 05:03 AM, Matt Fleming wrote:
> On Wed, 19 Oct, at 02:13:00PM, Laura Abbott wrote:
>> On 10/19/2016 01:04 PM, Laura Abbott wrote:
>>> Hi,
>>>
>>> Fedora received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1384238
>>> of a bootup failure with stable 4.7.6. efi=noruntime fixed the bootup problem.
>>> 1297667083d5442aafe3e337b9413bf02b114edb was linked as the cause
>>> of the problem.
>>>
>>>
>>> x86/efi: Only map RAM into EFI page tables if in mixed-mode
>>>
>>> Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
>>> multi-terabyte HP machine results in boot crashes, because the EFI
>>> region mapping functions loop forever while trying to map those
>>> regions describing RAM.
>>>
>>> While this patch doesn't fix the underlying hang, there's really no
>>> reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
>>> when mixed-mode is not in use at runtime.
>>>
>>> Reported-by: Waiman Long <[email protected]>
>>> Cc: Ard Biesheuvel <[email protected]>
>>> Cc: Borislav Petkov <[email protected]>
>>> Cc: Linus Torvalds <[email protected]>
>>> CC: Theodore Ts'o <[email protected]>
>>> Cc: Arnd Bergmann <[email protected]>
>>> Cc: Greg Kroah-Hartman <[email protected]>
>>> Cc: Scott J Norton <[email protected]>
>>> Cc: Douglas Hatch <[email protected]>
>>> Cc: <[email protected]> # v4.6+
>>> Signed-off-by: Matt Fleming <[email protected]>
>>>
>>> I made a request in the bugzilla for the reporter to
>>> give a bootlog with efi=debug which I'm still waiting on.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Laura
>>
>> dmesg with efi=debug from the reporter is attached
>
>> [ 0.000000] DMI: Hewlett-Packard Compaq CQ58 Notebook PC/188B, BIOS F.36 06/07/2013
>
> Hmm.. this is a fairly old machine, what kernel versions has the
> reporter successfully run on it? The code that was nop'd out in the
> above commit for the native case only came into existence in v4.6.
>
> The fact that booting with efi=old_map does *not* seem to result in a
> booting kernel is very suspicious. Could you ask them to double-check?
>
> Maybe try this patch too on v4.7.6.
Was out for a few days, reporter says the below patch does not work.
There was some confusion with secure boot so I've asked them to re-test
with efi=old_map and secure boot off.
Thanks,
Laura
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 964c7022d31d..b07183c6b470 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -244,9 +244,12 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
> * text and allocate a new stack because we can't rely on the
> * stack pointer being < 4GB.
> */
> - if (!IS_ENABLED(CONFIG_EFI_MIXED) || efi_is_native())
> + if (!IS_ENABLED(CONFIG_EFI_MIXED))
> return 0;
>
> + if (efi_is_native())
> + goto map_text;
> +
> /*
> * Map all of RAM so that we can access arguments in the 1:1
> * mapping when making EFI runtime calls.
> @@ -273,6 +276,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
> efi_scratch.phys_stack = virt_to_phys(page_address(page));
> efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
>
> +map_text:
> npages = (_etext - _text) >> PAGE_SHIFT;
> text = __pa(_text);
> pfn = text >> PAGE_SHIFT;
>