Re: [PATCH] efi_high_alloc: use EFI_ALLOCATE_MAX_ADDRESS

[Matt Fleming]

(Adding linux-efi to Cc)

On Fri, 22 Aug, at 03:48:23PM, harald@xxxxxxxxxx wrote:
> From: Harald Hoyer <harald@xxxxxxxxxx>
> 
> On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
> following memory regions:
> 
> 0x0000000000100000 - 0x0000000020000000
> 0x0000000020200000 - 0x0000000040000000
> 0x0000000040200000 - 0x00000000d2c02000
> 0x00000000d6e9f000 - 0x000000011e600000
> 
> and decided to allocate 2649 pages at address 0x11dba7000.
> As I understand this is the physical address and this machine only
> has 4GB mem!!
 
Yeah, but RAM doesn't necessarily start at the physical address
0x000000000000. Nor is it necessarily contiguous.

In other words, it's perfectly legitimate to allocate at physical
addresses above 0x10000000 if the above memory map tells us RAM lives
there.

> Nevertheless, unpacking of the initramfs later on failed.
> This was mainly caused by commit 4bf7111f50167133a71c23530ca852a41355e739,
> which enables loading the initramfs above 4G addresses.
> 
> With this patch efi_high_alloc() now uses EFI_ALLOCATE_MAX_ADDRESS.
> This returns 0x00000000d2c02000 on my machine and the resulting
> address at which the initramfs is loaded is then 0x00000000d21a9000,
> which seems to work fine.

Well yeah, that makes sense because you've obviously got a buggy EFI
firmware that doesn't load things correctly above 4GB. It turns out that
this is a common bug.

Can you try the following patch and see whether booting with
efi=nochunk results in a functioning initramfs? I've had some success
with disabling the chunking workaround when reading files in the EFI
boot stub. Also, including a copy of a dmesg would be helpful.

---