Bug 1127339

Summary: kernel: efi: EFI_MEMMAP is not enabled
Product: [openSUSE] openSUSE Tumbleweed Reporter: Martin Kravec <mkravec>
Component: KernelAssignee: Takashi Iwai <tiwai>
Status: VERIFIED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: jlee, mloviska, rbrown, tiwai
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Test fix patch
Upstream fix patch

Description Martin Kravec 2019-02-28 11:06:00 UTC
openQA: https://openqa.opensuse.org/tests/864184#step/journal_check/4

Please say if this error in log can be safely ignored
> kernel: efi: EFI_MEMMAP is not enabled.

I noticed it on non-uefi jobs.
Comment 1 Richard Brown 2019-02-28 14:09:58 UTC
Kernel-folks, can you give your opinion as to whether or not this error is worthy of concern?
Comment 2 Takashi Iwai 2019-02-28 14:23:25 UTC
I don't think it's a serious problem, but certainly a thing that started appearing recently.  Adding Joey to Cc.
Comment 3 Takashi Iwai 2019-02-28 17:27:03 UTC
Since it could be easily reproduced, I bisected.  It leads to the commit
  61f0d55569463a1af897117ff47d202b0ccb2e24
    efi/esrt: Only call efi_mem_reserve() for boot services memory
Comment 4 Takashi Iwai 2019-03-01 10:39:08 UTC
Sorry, the bisection was incorrect.  Now retrying...
Comment 5 Takashi Iwai 2019-03-01 10:42:39 UTC
OK, the second try lead to the commit
38ac0287b7f4f3922e25fd8f81db67f2c13d16bb
    fbdev/efifb: Honour UEFI memory map attributes when mapping the FB

This sounds more reasonable.  It's the commit introducing the efi_mem_desc_lookup() check at efifb_probe().
Comment 6 Takashi Iwai 2019-03-01 10:47:53 UTC
... and it means that the error message is harmless and nothing to worry much.

The call efi_mem_desc_lookup() inspects whether the given area has been reserved, so it should be OK even if it's not reserved.

The easiest "fix" would be to downgrade the message to pr_info*() or pr_debug*() instead of pr_err*().  Or we may add a flag not to spew errors, but I guess it's overkill.  There are only a few places calling efi_mem_desc_lookup().  The other callers show the errors via pr_err() or err_warn() when an error is returned from the function, so showing an error in the function is almost superfluous.
Comment 7 Takashi Iwai 2019-03-01 11:54:15 UTC
Created attachment 798559 [details]
Test fix patch
Comment 8 Takashi Iwai 2019-03-01 13:45:12 UTC
I submitted the patch to usptream.  Let's see whether it's accepted.  Then we can backport to TW kernel.
Comment 9 Takashi Iwai 2019-03-18 15:17:41 UTC
(In reply to Takashi Iwai from comment #8)
> I submitted the patch to usptream.  Let's see whether it's accepted.  Then
> we can backport to TW kernel.

This went on to an interesting discussion, and the upstream dev suggested a better fix.
  https://lkml.org/lkml/2019/3/1/303

Will check and backport once when it's merged to upstream.
Comment 10 Takashi Iwai 2019-04-01 15:27:19 UTC
Created attachment 801843 [details]
Upstream fix patch
Comment 11 Takashi Iwai 2019-04-01 15:27:42 UTC
Now I pushed the upstream fix patch in the subsystem tree to stable branch.
Comment 14 Martin Loviska 2021-06-17 09:41:11 UTC
Haven't been present in the latest runs. If no objections, I close this report.