Re: ESRT failures ... was Re: [PATCH 04/11] efi: Add efi_memmap_init_late() for permanent EFI memmap

[Prarit Bhargava <prarit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 07/25/2016 11:13 AM, Matt Fleming wrote:
> 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.
> 

Nope, nothing else is displayed with "earlyprintk=efi" as a kernel parameter (I
already had that as a kernel parameter).

P.