Bug 1127339 - kernel: efi: EFI_MEMMAP is not enabled
kernel: efi: EFI_MEMMAP is not enabled
Status: VERIFIED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Takashi Iwai
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-28 11:06 UTC by Martin Kravec
Modified: 2022-07-21 17:27 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Test fix patch (1.56 KB, patch)
2019-03-01 11:54 UTC, Takashi Iwai
Details | Diff
Upstream fix patch (2.29 KB, patch)
2019-04-01 15:27 UTC, Takashi Iwai
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.