Bug 213177 - [bisected][Regression] Unable to boot a 5.13 kernel due to commit "x86/setup: Consolidate early memory reservations"
Summary: [bisected][Regression] Unable to boot a 5.13 kernel due to commit "x86/setup:...
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
Depends on:
Reported: 2021-05-22 11:52 UTC by Linux_Chemist
Modified: 2023-03-02 04:09 UTC (History)
4 users (show)

See Also:
Kernel Version: latest (from /torvalds/linux.git/)
Regression: Yes
Bisected commit-id:

config file that works otherwise (99.37 KB, text/plain)
2021-05-22 11:52 UTC, Linux_Chemist
info from Ubuntu kernel 5.11.0-18 (105.74 KB, text/plain)
2021-05-22 18:46 UTC, Linux_Chemist
info from customised kernel 5.12 final (80.07 KB, text/plain)
2021-05-22 18:47 UTC, Linux_Chemist
Full dmesg from ubuntu kernel 5.11.0-18 (177.73 KB, text/plain)
2021-05-22 19:09 UTC, Linux_Chemist
partial-revert-of-a799c2bd29d1.patch (1.32 KB, patch)
2021-05-22 19:30 UTC, Mike Rapoport
Details | Diff
full dmesg of ubuntu mainline 5.13rc2 - working! (175.21 KB, text/plain)
2021-05-23 00:20 UTC, Linux_Chemist

Description Linux_Chemist 2021-05-22 11:52:18 UTC
Created attachment 296939 [details]
config file that works otherwise

CPU: Ryzen 7 3700x
MB: Asrock X470 Taichi bios P4.70

Have been unable to boot 5.13 rc kernels but bisected the issue to this commit:

a799c2bd29d19c565f37fa038b31a0a1d44d0e4d is the first bad commit
commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
Author: Mike Rapoport <rppt@linux.ibm.com>
Date:   Tue Mar 2 12:04:05 2021 +0200

    x86/setup: Consolidate early memory reservations

When trying to boot, the system hangs with a black screen indefinitely. 
I thought it might be an issue specific to my custom (and quite/overly lean) .config so I'll attach that too. If it's at all relevant, these options in it are the same as Ubuntu's defaults:


(Since the commit mentioned "x86/setup", I assume this is x86 specific so I hope I've filed this bug in the correct place!)
Comment 1 Mike Rapoport 2021-05-22 14:52:06 UTC
Can you please post the log of the latest working kernel with 'memblock=debug' added to the kernel command line.
Comment 2 Linux_Chemist 2021-05-22 18:46:05 UTC
Created attachment 296941 [details]
info from Ubuntu kernel 5.11.0-18

'dmesg | grep mem' info from Ubuntu kernel 5.11.0-18
This is probably the more helpful kernel as it still has some debugging stuff in it. (Also has hibernation support as the key difference in memory mapping).
Comment 3 Linux_Chemist 2021-05-22 18:47:32 UTC
Created attachment 296943 [details]
info from customised kernel 5.12 final

This kernel has a lot of debugging pulled out and no hibernation support etc.
Comment 4 Linux_Chemist 2021-05-22 19:09:49 UTC
Created attachment 296945 [details]
Full dmesg from ubuntu kernel 5.11.0-18
Comment 5 Mike Rapoport 2021-05-22 19:30:59 UTC
Created attachment 296947 [details]

I don't see anything that could give a clue in the logs.
The only idea I have for now is to partially revert a799c2bd29d1 and see if it helps. What I'm after is to find what of the reservations moved around causes the regression.
Comment 6 Linux_Chemist 2021-05-22 20:05:40 UTC
Interestingly perhaps, I double checked that the patch was definitely applied successfully - looks like partial-revert-of-a799c2bd29d1 causes the issue too!
Comment 7 Linux_Chemist 2021-05-22 20:06:21 UTC
or rather, it doesn't solve the problem*
Comment 8 Linux_Chemist 2021-05-23 00:19:46 UTC
It seems I have some more digging to do(!) because I just tried the ubuntu mainline kernel 5.13rc2 and that works fine.

As I feared, something in my custom config in particular is no longer kosher after the reorganisation in the commit for memory reservations.
I thought it might be because I didn't have memory hotplug enabled but even with 

to match ubuntu again, it's still a nogo.  Gonna be a good while trying to narrow it down - any suggestions what kernel options may simply need to be turned on now based on my 5.12 "config that works otherwise"? I'll report back once I solve the mystery ;)
Comment 9 Linux_Chemist 2021-05-23 00:20:59 UTC
Created attachment 296949 [details]
full dmesg of ubuntu mainline 5.13rc2 - working!
Comment 10 Mike Rapoport 2021-05-23 05:12:09 UTC
I don't think memory hotplug or hibernation options have anything to do with the hang. I'd rather look for EFI/BIOS related options.

Did you try completely reverting a799c2bd29d19c565f37fa038b31a0a1d44d0e4d from v5.13-rc2?
(There should be no conflicts if you first revert c361e5d4d07d63768880e1994c7ed999b3a94cd9)
Comment 11 Linux_Chemist 2021-05-23 20:21:01 UTC
Cause for celebrations! - I've managed to narrow down to the precise kernel config change which causes the inability to boot on the latest kernels.

So before the kernel commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d, booting worked fine with 


However, by default this is set to 64 (also default for the Ubuntu kernels). Setting this back to 64 and I can boot normally again!

In think the past, I had set that to 640 to avoid any potential headaches in line with the guidance for it: "If you know your BIOS [to] have problems beyond the
default 64K area, you can set this to 640 to avoid using the entire low memory range."  Thought it would be better to give it all the breathing room it needed since there was plenty of memory to spare.

Perhaps this is reproducible on other hardware with it set to 640? If not, I don't know, maybe similar effects can be seen on the same hardware setups as mine. An unintended consequence of the reservation reorganisations?  

I have to imagine this is still a bug because some setups will necessitate having that set to 640 and may no longer be able to boot. Hopefully you can see a solution, I'm just happy to be able to test out the next couple of weeks' release candidates again!
Comment 12 Mike Rapoport 2021-05-24 05:59:50 UTC
Great news!

I could reproduce it with qemu simply by setting reservelow=640k in the command line.

The reason for the failures is that when we reserve all 640k very early there is no enough memory for allocation of the real-mode trampoline.

We could move the reservation of the range between 64k and 640k after the real-mode trampoline setup, but in a sense this contradicts CONFIG_X86_RESERVE_LOW=640 (or reservelow=640k). If user requested to reserve the entire low memory range and we are anyway allocating real-mode trampoline there there is a danger that BIOS will corrupt the trampoline memory. OTOH, if we respect the user's request to keep the first 640k reserved there is no room for real mode trampoline.

I think the best way to move forward is to lower the upper limit of CONFIG_X86_RESERVE_LOW to, say 512K.

@Boris, what do you think?
Comment 13 Linux_Chemist 2021-05-26 09:11:08 UTC
They say the best bugs are the ones that get squashed. Thanks for your help, hopefully I can be somewhat useful again with the next bug haha
Comment 14 Mike Rapoport 2021-05-29 05:30:36 UTC
Hmm, probably it's because of the debug info. I think if you disable it in "Kernel Hacking" -> "Compile-time checks and compiler options" -> "Compile the kernel with debug info" in kernel configuration (e.g. make menuconfig) the size of the rpm will be much smaller.
Comment 15 Mike Rapoport 2021-05-30 09:57:59 UTC
(In reply to Mike Rapoport from comment #14)
> Hmm, probably it's because of the debug info. I think if you disable it in
> "Kernel Hacking" -> "Compile-time checks and compiler options" -> "Compile
> the kernel with debug info" in kernel configuration (e.g. make menuconfig)
> the size of the rpm will be much smaller.

sorry, this was posted to a wrong bug :)
Comment 16 Borislav Petkov 2021-06-07 08:20:43 UTC
5.13-rc5 should have the fix, can you test it to confirm please?
Comment 17 Linux_Chemist 2021-06-07 11:07:26 UTC
Confirming, all good with the patch f1d4d47c5851b348b7713007e152bc68b94d728b for the use of 

5.13-rc5 is a 'go'!
Thanks :)
Comment 18 Andy Lutomirski 2023-03-02 04:09:04 UTC
Sadly, commit f1d4d47c5851b348b7713007e152bc68b94d728b is buggy.

Is there any actual need for the reservelow mechanism?  is not, I propose that we revert commit f1d4d47c5851b348b7713007e152bc68b94d728b and call it a day -- reservelow is gone as of commit 1a6a9044b96729abacede172d7591c714a5b81d1, so the original bug here should be squashed one way or another.  If we *do* need reservelow, then someone needs to go and implement it correctly, and commit f1d4d47c5851b348b7713007e152bc68b94d728b is not a correct implementation of reserving low memory.

The whole concept is a bit bizarre.  We *need* to allocate low memory in order for the kernel to work correctly.  On a BIOS system (or maybe even on UEFY?), we can't use the actual BIOS region, and we should also not use the EBDA.  And the memory above BIOS and below 1M is probably not a great idea.  And we probably shouldn't use the page at PA 0.  But this means that, as an x86 kernel, we *must use memory somewhere above 0 and below BIOS / EBDA*.  There is simply no way to operate otherwise with suspend or SMP unless we want to start using high memory (or whatever it's called -- it's been quite a while since I messed with DOS).

So IMO it just does not make sense to reserve a fixed area at the bottom of memory greater than one page.  Because a fully correct implementation of this sort of reservation WILL NOT BOOT if the reservation hits the EBDA.  And pretending that we reserved a region while still using it for the trampoline is just wrong -- if BIOS clobbers the trampoline, we are every bit as clobbered as if BIOS clobbers any other random kernel memory, if not more dead.

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