On 25.08.2014 12:34, Matt Fleming wrote: > (Adding linux-efi to Cc) > > On Fri, 22 Aug, at 03:48:23PM, harald@redhat.com wrote: >> From: Harald Hoyer >> >> 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. yeah, I thought so, too :) > >> 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. > Here we go... dmesg attached, but uncompression failed.