11 of 20 deleted 5 characters in body

You should see a longer help text for this config option. It offers two reasons.

config X86_RESERVE_LOW
int "Amount of low memory, in kilobytes, to reserve for the BIOS"
default 64
range 4 640

Specify the amount of low memory to reserve for the BIOS.

The first page contains BIOS data structures that the kernel must not use, so that page must always be reserved.


There is a similar comment in the code:

     * A special case is the first 4Kb of memory;
     * This is a BIOS owned area, not kernel ram, but generally
     * not listed as such in the E820 table.

Wikipedia says the traditional BIOS would use the first 1280 bytes (0x500). Linux allocates RAM in units of the MMU page size (4096 bytes). OSDev points out -

After all the BIOS functions have been called, and your kernel is loaded into memory somewhere, the bootloader or kernel may exit Real Mode forever (often by going into 32bit Protected Mode). If the kernel never uses Real Mode again, then the first 0x500 bytes of memory in the PC may be reused and overwritten.

Linux is not generally able to call into the BIOS. It may do so in a few terrifying moments: early boot, shutdown, and resume from sleep mode. If your system was booted using UEFI, then as far as Linux can tell there is no BIOS it could call :-).

Here is the second reason:

By default we reserve the first 64K of physical RAM, as a number of BIOSes are known to corrupt that memory range during events such as suspend/resume or monitor cable insertion, so it must not be used by the kernel.

You can set this to 4 if you are absolutely sure that you trust the BIOS to get all its memory reservations and usages right. If you know your BIOS have problems beyond the default 64K area, you can set this to 640 to avoid using the entire low memory range.

If you have doubts about the BIOS (e.g. suspend/resume does not work or there's kernel crashes after certain hardware hotplug events) then you might want to enable X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check typical corruption patterns.

Leave this to the default value of 64 if you are unsure.

I expect this second reason applies equally to UEFI firmware.

If you look at the Kconfig file that defines the config option, you could use "git blame" and try to find the patch that added it. Here is a link from clicking the "blame" button on github.com:


Although, the way I looked up the following was to search my email archives. To find the first bug report linked below, that I reported after updating my kernel :-).

x86: add DMI quirk for AMI BIOS which corrupts address 0xc000 during resume

Alan Jenkins and Andy Wettstein reported a suspend/resume memory corruption bug and extensively documented it here:


The bug is that the BIOS overwrites 1K of memory at 0xc000 physical, without registering it in e820 as reserved or giving the kernel any idea about this.

Detect AMI BIOSen and reserve that 1K.

We paint this bug around with a very broad brush (reserving that 1K on all AMI BIOS systems), as the bug was extremely hard to find and needed several weeks and lots of debugging and patching.

The bug was found via the CONFIG_X86_CHECK_BIOS_CORRUPTION=y debug feature, if similar bugs are suspected then this feature can be enabled on other systems as well to scan low memory for corrupted memory.

x86: add X86_RESERVE_LOW_64K

This bugzilla:


Documents a wide range of systems where the BIOS utilizes the first 64K of physical memory during suspend/resume and other hardware events.

Currently we reserve this memory on all AMI and Phoenix BIOS systems. Life is too short to hunt subtle memory corruption problems like this, so we try to be robust by default.

Still, allow this to be overriden: allow users who want that first 64K of memory to be available to the kernel disable the quirk, via CONFIG_X86_RESERVE_LOW_64K=n.

x86, bios: By default, reserve the low 64K for all BIOSes

The laundry list of BIOSes that need the low 64K reserved is getting very long, so make it the default across all BIOSes. This also allows the code to be simplified and unified with the reservation code for the first 4K.

This resolves kernel bugzilla 16661 and who knows what else...

Bug 16661 - Corrupted low memory

[...] It means we should add his BIOS (dmidecode info please) to the blacklist bad_bios_dmi_table in arch/x86/kernel/setup.c. However, the bottom line is that 64K is such a small amount of memory and the list by now covers such a vast number of existing BIOSes, that we should just make it unconditional.

As far as I know, Windows 7 actually reserves all memory below 1 MiB to avoid BIOS bugs.