Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16

[Matt Fleming <matt@console-pimps.org>]

On Mon, 04 Aug, at 11:34:35AM, Bruno Prémont wrote:
> Hi,
> 
> Since 3.13 kernels with built-in initrd fail to boot on Fujitsu hardware
> in EFI mode (efi stub) though the exact same kernel binary does boot in
> BIOS mode (grub).
> Interestingly EFI kernels with different config do boot under VMWare.
> 
> Your patch "initramfs: read CONFIG_RD_ variables for initramfs
> compression" is the trigger.
> 
> 
> Is something missing in EFI stub or why do things behave differently?
 
Nuts. I suspect it's an EFI boot stub bug. Have you definitely tried out
3.16? In particular the following commit might make a difference,

  commit c7fb93ec51d4
  Author: Michael Brown <mbrown@fensystems.co.uk>
  Date:   Thu Jul 10 12:26:20 2014 +0100

      x86/efi: Include a .bss section within the PE/COFF headers
    
      The PE/COFF headers currently describe only the initialised-data
      portions of the image, and result in no space being allocated for the
      uninitialised-data portions.  Consequently, the EFI boot stub will end
      up overwriting unexpected areas of memory, with unpredictable results.
    
      Fix by including a .bss section in the PE/COFF headers (functionally
      equivalent to the init_size field in the bzImage header).
    
      Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
      Cc: Thomas Bächler <thomas@archlinux.org>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Matt Fleming <matt.fleming@intel.com>


> Looking at compiled kernel with and without this patch the resulting
> bzImage is similar in size but in build directory I get:

Could you send me the initrd image? I'd like to try and reproduce this
on my end, even though I regularly boot with a built-in initrd.

-- 
Matt Fleming, Intel Open Source Technology Center