On Mon, 25 Jul, at 11:11:31AM, Prarit Bhargava wrote:
>
>
> On 07/25/2016 10:44 AM, Matt Fleming wrote:
> > On Fri, 22 Jul, at 09:31:20AM, Prarit Bhargava wrote:
> >>
> >> Hmm ... maybe just a Dell specific quirk?
> >
> > Quirks are best avoided at all costs, platform-specific quirks doubly
> > so because there are just so many in the EFI arena that maintaining
> > them all would be a nightmare.
> >
> > Where possible we adopt a "most buggy implementation" approach to
> > compatibility, as a least common denominator.
> >
> > Could you try this patch out? It's not a final version, but I'd just
> > like to see if anything else explodes when we start returning reserved
> > regions.
> >
> > ---
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 05509f3aaee8..9857796c4cd4 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -299,7 +299,8 @@ int __init efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md)
> >
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > - md->type != EFI_RUNTIME_SERVICES_DATA) {
> > + md->type != EFI_RUNTIME_SERVICES_DATA &&
> > + md->type != EFI_RESERVED_TYPE) {
>
> I had tried this fix earlier FWIW and it causes the boot to hang.
Do you know where it hangs? earlyprintk=efi might shed some light on
that if you don't have a serial console setup.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
