Bug#815125: Boot failure with Debian linux 4.4.2 package

[Alexis Murzeau <amurzeau@gmail.com>]

2016-03-04 14:07 GMT+01:00 Matt Fleming <matt@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