Bug 213991 - 'exit_boot() failed' due to EFI_MMAP_NR_SLACK_SLOTS being too low (on 2.31 AMI UEFI)
Summary: 'exit_boot() failed' due to EFI_MMAP_NR_SLACK_SLOTS being too low (on 2.31 AM...
Status: NEW
Alias: None
Product: EFI
Classification: Unclassified
Component: Boot (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: EFI Virtual User
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-07 21:53 UTC by Javier S. Pedro
Modified: 2021-08-17 15:27 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.13.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
attachment-31673-0.html (1.95 KB, text/html)
2021-08-09 08:55 UTC, Andy Whitcroft
Details

Description Javier S. Pedro 2021-08-07 21:53:53 UTC
I am on the following system:

DMI: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
efi: EFI v2.31 by American Megatrends

and I keep hitting the issue where the efi stub fails to boot with the following messages:

exit_boot() failed!
efi_main() failed!

Then the system hangs and does not respond to Ctrl+Alt+Del or magic sysrq. 

This happens on every single kernel version I've tried on this machine (from 4.19 to 5.13.6). So it is not a regression and not related to CONFIG_EFI_DISABLE_PCI_DMA.

It happens very frequently albeit not consistently. Tends to happen more frequently after a warm boot or whenever I have more than a couple USB devices plugged in (with just 3 devices it happens almost 99% of the time after reboot). 
Tends to happen less frequently after a cold boot, or if I enable "MSI Fast Boot" option in BIOS which seems to disable UEFI USB stack. 


I was able to diagnose the issue a bit. Turns out that ExitBootServices returns INVALID_ARGUMENT, so we call GetMemoryMap again which fails and returns BUFFER_TOO_SMALL. The error messages shown above are quite misleading; it is not exit_boot which fails, it is GetMemoryMap.

From my printfs, it seems that this BIOS may actually require 10 to 12 extra descriptor slots in the map after calling ExitBootServices, rather than 8. 

I tried bumping EFI_MMAP_NR_SLACK_SLOTS to 16 and this fixed the problem completely. I could not make it fail even after plugging every single USB device I have.


Looks like some distributions are already carrying this change (e.g. Ubuntu bumps it to 16 too : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851810 ), but no idea why the patch was not submitted upstream.
Comment 1 Javier S. Pedro 2021-08-07 22:08:21 UTC
Link to Ubuntu patch: 

https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20191108102546.233856-1-apw@canonical.com

As per the comment there it looks like grub is the main reason for the extra required slots. I concur it fails much more frequently from Grub, albeit I have also seen it fail even when booted from the shell.

CCing apw in case there is some reason for the patch not to go upstream ?
Comment 2 Andy Whitcroft 2021-08-09 08:55:19 UTC
Created attachment 298233 [details]
attachment-31673-0.html

I believe this was fixed separately by another change in the EFI code.
Wherein a sizing was corrected.

-apw

On Sat, 7 Aug 2021 at 23:08, <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=213991
>
> Javier S. Pedro (debbugs@javispedro.com) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |apw@canonical.com
>
> --- Comment #1 from Javier S. Pedro (debbugs@javispedro.com) ---
> Link to Ubuntu patch:
>
>
>
> https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20191108102546.233856-1-apw@canonical.com
>
> As per the comment there it looks like grub is the main reason for the
> extra
> required slots. I concur it fails much more frequently from Grub, albeit I
> have
> also seen it fail even when booted from the shell.
>
> CCing apw in case there is some reason for the patch not to go upstream ?
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 3 Ard Biesheuvel 2021-08-17 15:27:18 UTC
(In reply to Andy Whitcroft from comment #2)
> Created attachment 298233 [details]
> attachment-31673-0.html
> 
> I believe this was fixed separately by another change in the EFI code.
> Wherein a sizing was corrected.
> 

I vaguely recall something like this as well, but I tried to find it in the git history and nothing stands out.

I don't have any problems with increasing the number of slots, though. The current value was chosen arbitrarily to begin with.
 

> 
> On Sat, 7 Aug 2021 at 23:08, <bugzilla-daemon@bugzilla.kernel.org> wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=213991
> >
> > Javier S. Pedro (debbugs@javispedro.com) changed:
> >
> >            What    |Removed                     |Added
> >
> >
> ----------------------------------------------------------------------------
> >                  CC|                            |apw@canonical.com
> >
> > --- Comment #1 from Javier S. Pedro (debbugs@javispedro.com) ---
> > Link to Ubuntu patch:
> >
> >
> >
> >
> https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20191108102546.233856-1-apw@canonical.com
> >
> > As per the comment there it looks like grub is the main reason for the
> > extra
> > required slots. I concur it fails much more frequently from Grub, albeit I
> > have
> > also seen it fail even when booted from the shell.
> >
> > CCing apw in case there is some reason for the patch not to go upstream ?
> >
> > --
> > You may reply to this email to add a comment.
> >
> > You are receiving this mail because:
> > You are on the CC list for the bug.

Note You need to log in before you can comment on or make changes to this bug.