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
On Fri, 01 Aug, at 09:11:54AM, Josh Triplett wrote:
The original bug report was about an allocation failure for a fairly
reasonable BGRT size. We can certainly prohibit absurdly huge ones (for
instance, bigger than the maximum likely screen resolution times 4 bytes
per pixel), but
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.
On Fri, 11 Jul, at 09:09:16AM, Ard Biesheuvel wrote:
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized. Use a spinlock to serialize all Runtime Services with respect
to all others, even
Hi Matt,
On Mon, 4 Aug 2014 13:27:28 +0100 Matt Fleming wrote:
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).
On 4 August 2014 15:00, Matt Fleming m...@console-pimps.org wrote:
On Fri, 11 Jul, at 09:09:16AM, Ard Biesheuvel wrote:
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized. Use a spinlock
On Mon, 04 Aug, at 03:06:27PM, Bruno Prémont wrote:
Yes, I did as I have seen that patch flying by, but it did not help
(I tried at 3.16-rc7).
:-( Thanks for testing.
On 3.16-rc7 I even tried adding earlyprintk=efi,keep, console=efi,
ignore_loglevel and added some efi_printk() in EFI stub
On Mon, 04 Aug, at 03:13:28PM, Ard Biesheuvel wrote:
Well, again, the spec allows it. But I am happy to remove it as it
does not affect ARM anyway
Right, I understand why you added these now.
My personal opinion is that we shouldn't do the NMI dancing unless
absolutely necessary, e.g.
On 4 August 2014 16:49, Matt Fleming m...@console-pimps.org wrote:
On Mon, 04 Aug, at 03:13:28PM, Ard Biesheuvel wrote:
Well, again, the spec allows it. But I am happy to remove it as it
does not affect ARM anyway
Right, I understand why you added these now.
My personal opinion is that we
On Mon, 04 Aug, at 05:05:53PM, Ard Biesheuvel wrote:
I think that makes sense. As I said, I don't have a strong preference
either way regarding the NMI handling, as it does not affect the
systems I am primarily concerned with (and it sounds like a big hack
anyway). What I /am/ concerned with
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized. Use a spinlock to serialize all Runtime Services with respect
to all others, even if this is more than strictly needed.
Signed-off-by:
From: Matt Fleming matt.flem...@intel.com
Building a 32-bit kernel with CONFIG_X86_USE_3DNOW and CONFIG_EFI_STUB
leads to the following build error,
drivers/firmware/efi/libstub/lib.a(efi-stub-helper.o): In function
`efi_relocate_kernel':
efi-stub-helper.c:(.text+0xda5): undefined reference
On 08/04/2014 03:52 PM, Matt Fleming wrote:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 801ed36c2e49..fcad2e15e92a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1520,7 +1520,7 @@ config X86_SMAP
config EFI
bool EFI runtime service support
- depends on
From: Matt Fleming matt.flem...@intel.com
Building a 32-bit kernel with CONFIG_X86_USE_3DNOW and CONFIG_EFI_STUB
leads to the following build error,
drivers/firmware/efi/libstub/lib.a(efi-stub-helper.o): In function
`efi_relocate_kernel':
efi-stub-helper.c:(.text+0xda5): undefined reference
14 matches
Mail list logo
