Hi,
After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
Failed to get file info size
Failed to alloc highmem for files
After a morning of running git bisect and rebooting, the bad commit seems to be:
54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
It doesn't revert cleanly, so I can't test current git without it to see if that fixes it or not. I'm using gummiboot as bootloader:
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
File: └─/EFI/gummiboot/gummibootx64.efi (gummiboot 44)
File: └─/EFI/Boot/BOOTX64.EFI (gummiboot 44)
Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
ID: 0x0016
Status: active, boot-order
Partition: /dev/disk/by-partuuid/b7b4fad3-3d19-40fd-b341-0ec7f2152b81
File: └─/EFI/gummiboot/gummibootx64.efi
Title: Linux Boot Manager
ID: 0x0015
Status: active, boot-order
Partition: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
File: └─/EFI/gummiboot/gummibootx64.efi
Title: Fedora
ID: 0x0014
Status: active, boot-order
Partition: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
File: └─/EFI/fedora/shim.efi
Title: Windows Boot Manager
ID: 0x0013
Status: active, boot-order
Partition: /dev/disk/by-partuuid/56dff960-86b5-4846-89d3-fed0620f471a
File: └─/EFI/Microsoft/Boot/bootmgfw.efi
thanks,
Koen
Bisect log:
git bisect start
# good: [dcb99fd9b08cfe1afe426af4d8d3cbc429190f15] Linux 3.14-rc7
git bisect good dcb99fd9b08cfe1afe426af4d8d3cbc429190f15
# bad: [39de65aa2c3eee901db020a4f1396998e09602a3] Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect bad 39de65aa2c3eee901db020a4f1396998e09602a3
# bad: [ec0159503ae74aeb834e78366bdf4b9663ca1129] hwmon: (k10temp) Add support for AMD F16 M30h processor
git bisect bad ec0159503ae74aeb834e78366bdf4b9663ca1129
# bad: [675c354a95d5375153b8bb80a0448cab916c7991] Merge tag 'char-misc-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 675c354a95d5375153b8bb80a0448cab916c7991
# bad: [3786075b5ebc8c4eaefd9e3ebf72883934fb64b3] Merge tag 'regulator-v3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect bad 3786075b5ebc8c4eaefd9e3ebf72883934fb64b3
# bad: [1ce235faa8fefa4eb7199cad890944c1d2ba1b3e] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect bad 1ce235faa8fefa4eb7199cad890944c1d2ba1b3e
# good: [8c292f11744297dfb3a69f4a0bccbe4a6417b50d] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 8c292f11744297dfb3a69f4a0bccbe4a6417b50d
# bad: [e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0] Merge branch 'x86-kaslr-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0
# good: [971eae7c99212dd67b425a603f1fe3b763359907] Merge branch 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 971eae7c99212dd67b425a603f1fe3b763359907
# bad: [204b0a1a4b92612c957a042df1a3be0e9cc79391] x86, efi: Abstract x86 efi_early calls
git bisect bad 204b0a1a4b92612c957a042df1a3be0e9cc79391
# bad: [3db4cafdfd05717dc939780134e53023a3c1f15f] x86/boot: Fix non-EFI build
git bisect bad 3db4cafdfd05717dc939780134e53023a3c1f15f
# bad: [0154416a71c2a84c3746c8dd8ed25287e36934d3] x86/efi: Add early thunk code to go from 64-bit to 32-bit
git bisect bad 0154416a71c2a84c3746c8dd8ed25287e36934d3
# good: [426e34cc4f6094cefe4f3175764cdf583128e7cd] x86/mm/pageattr: Always dump the right page table in an oops
git bisect good 426e34cc4f6094cefe4f3175764cdf583128e7cd
# good: [677703cef0a148ba07d37ced649ad25b1cda2f78] efi: Add separate 32-bit/64-bit definitions
git bisect good 677703cef0a148ba07d37ced649ad25b1cda2f78
Build command line:
cp defconfig-3.13 .config ; yes '' | make oldconfig ; make bzImage -j4 && sudo cp arch/x86_64/boot/bzImage /boot/vmlinuz-3.14 && sudo reboot-
On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
> Hi,
>
> After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
>
> Failed to get file info size
> Failed to alloc highmem for files
>
> After a morning of running git bisect and rebooting, the bad commit seems to be:
>
> 54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
Thanks for the report. Can you try this patch against Linus' tree?
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 1e6146137f8e..280165524ee4 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
efi_file_info_t *info;
efi_status_t status;
efi_guid_t info_guid = EFI_FILE_INFO_ID;
- u32 info_sz;
+ u64 info_sz;
status = efi_early->call((unsigned long)fh->open, fh, &h, filename_16,
EFI_FILE_MODE_READ, (u64)0);
--
Matt Fleming, Intel Open Source Technology Center
Op 10 apr. 2014, om 14:11 heeft Matt Fleming <[email protected]> het volgende geschreven:
> On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
>> Hi,
>>
>> After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
>>
>> Failed to get file info size
>> Failed to alloc highmem for files
>>
>> After a morning of running git bisect and rebooting, the bad commit seems to be:
>>
>> 54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
>
> Thanks for the report. Can you try this patch against Linus' tree?
That indeed fixes it, so:
Tested-by: Koen Kooi <[email protected]>
regards,
Koen
>
>
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 1e6146137f8e..280165524ee4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
> efi_file_info_t *info;
> efi_status_t status;
> efi_guid_t info_guid = EFI_FILE_INFO_ID;
> - u32 info_sz;
> + u64 info_sz;
>
> status = efi_early->call((unsigned long)fh->open, fh, &h, filename_16,
> EFI_FILE_MODE_READ, (u64)0);
> --
> Matt Fleming, Intel Open Source Technology Center
>
* Matt Fleming <[email protected]> wrote:
> On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
> > Hi,
> >
> > After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
> >
> > Failed to get file info size
> > Failed to alloc highmem for files
> >
> > After a morning of running git bisect and rebooting, the bad commit seems to be:
> >
> > 54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
>
> Thanks for the report. Can you try this patch against Linus' tree?
>
>
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 1e6146137f8e..280165524ee4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
> efi_file_info_t *info;
> efi_status_t status;
> efi_guid_t info_guid = EFI_FILE_INFO_ID;
> - u32 info_sz;
> + u64 info_sz;
Might be prudent to do the same in __file_size32(), instead of
truncating silently, especially is that function too has a u64 output
AFAICS.
Also, while reviewing the file I noticed that there's "u32 fb_base",
which is recovered like:
status = __gop_query64(gop64, &info, &size, &fb_base);
but ->frame_buffer_base is u64. Is it always guaranteed u32?
Thanks,
Ingo
On Fri, 11 Apr, at 09:20:44AM, Ingo Molnar wrote:
>
> Might be prudent to do the same in __file_size32(), instead of
> truncating silently, especially is that function too has a u64 output
> AFAICS.
This change isn't required for __file_size32() because we only use that
function if the firmware is 32-bit. The signature of
EFI_FILE_PROTOCOL.GetInfo() looks like this,
EFI_STATUS (*EFI_FILE_GET_INFO) (
EFI_FILE_PROTOCOL *This,
EFI_GUID *InformationType,
UINTN *BufferSize,
void *Buffer
);
UINTN translates to unsigned long, so for 32-bit firmware is u32. The
firmware will never write 64-bits to &info_sz in __file_size32().
> Also, while reviewing the file I noticed that there's "u32 fb_base",
> which is recovered like:
>
> status = __gop_query64(gop64, &info, &size, &fb_base);
>
> but ->frame_buffer_base is u64. Is it always guaranteed u32?
Good catch. ->frame_buffer_base isn't always u32, but we only have u32
bits in which to store it (struct screen_info.lfb_base), so we
implicitly truncate it,
static efi_status_t
__gop_query64(struct efi_graphics_output_protocol_64 *gop64,
[...]
*fb_base = mode->frame_buffer_base;
But you raise a good point - it would probably make more sense to
complain loudly if we get an address above 0xffffffff.
--
Matt Fleming, Intel Open Source Technology Center