From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s Date: Fri, 11 Apr 2014 09:20:44 +0200 Message-ID: <20140411072044.GA15418@gmail.com> References: <20140410121146.GA17021@console-pimps.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20140410121146.GA17021-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Matt Fleming Cc: Koen Kooi , Matt Fleming , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Kees Cook , Zhang Yanfei , linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-efi@vger.kernel.org * Matt Fleming 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