2016-03-04 14:07 GMT+01:00 Matt Fleming <m...@codeblueprint.co.uk>:
>
> It must have been a herculean effort to take photos of the screen
> while the buggy kernel booted. Thank you!
>
> I'm not really seeing anything jumping out as obviously wrong apart
> from the fact that we don't have all of EFI_CONVENTIONAL_MEMORY mapped
> in the buggy kernel.
>
> Could you try this patch?
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 49e4dd4a1f58..f5e77d240ff1 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -241,15 +241,6 @@ int __init efi_setup_page_tables(unsigned long
> pa_memmap, unsigned num_pages)
> efi_scratch.use_pgd = true;
>
> /*
> - * When making calls to the firmware everything needs to be 1:1
> - * mapped and addressable with 32-bit pointers. Map the kernel
> - * text and allocate a new stack because we can't rely on the
> - * stack pointer being < 4GB.
> - */
> - if (!IS_ENABLED(CONFIG_EFI_MIXED))
> - return 0;
> -
> - /*
> * Map all of RAM so that we can access arguments in the 1:1
> * mapping when making EFI runtime calls.
> */
> @@ -268,6 +259,15 @@ int __init efi_setup_page_tables(unsigned long
> pa_memmap, unsigned num_pages)
> }
> }
>
> + /*
> + * When making calls to the firmware everything needs to be 1:1
> + * mapped and addressable with 32-bit pointers. Map the kernel
> + * text and allocate a new stack because we can't rely on the
> + * stack pointer being < 4GB.
> + */
> + if (!IS_ENABLED(CONFIG_EFI_MIXED))
> + return 0;
> +
> page = alloc_page(GFP_KERNEL|__GFP_DMA32);
> if (!page)
> panic("Unable to allocate EFI runtime stack < 4GB\n");
Thanks for you suggestion.
Unfortunately, this patch doesn't make it works, the crash still
occurs (at the same RIP and traceback).
Using /dev/mem on a running system (with kernel 4.3), the memory
around RIP (0xaa9462ee) is :
aa9462d0 sub rsp,0x28
aa9462d4 lea rdx,[rip+0x2445] # 0xaa948720
aa9462db mov ecx,0x4
aa9462e0 call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
aa9462e5 mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
aa9462ec xor eax,eax
aa9462ee mov BYTE PTR [r11+0x1],0x1
aa9462f3 add rsp,0x28
aa9462f7 ret
The QWORD at address 0xaa948720 is 0 though on the running system.
I will try to investigate more but I'm open to any printk / patch tests.
Alexis Murzeau
