I have bad ram which is soldered on so I can't replace it. I have run memtest86+ and got the output in badram format. I added this to the current kernel with:

sudo grubby --args=badram=0x0000000050d54a08,0xfffffffff7fffadc --update-kernel /boot/vmlinuz-5.9.8-200.fc33.x86_64

I can see from dmesg that the parameter is there but nothing seems to be happening. I was expecting that area of ram to show up in the logs somewhere:

[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-11-12
[    0.000000] Linux version 5.9.8-200.fc33.x86_64 ([email protected]) (gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6), GNU ld version 2.35-14.fc33) #1 SMP Tue Nov 10 21:58:19 UTC 2020
[    0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.9.8-200.fc33.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet systemd.unified_cgroup_hierarchy=0 badram=0x0000000050d54a08,0xfffffffff7fffadc
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009d000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000000fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000010000000-0x000000001000afff] reserved
[    0.000000] BIOS-e820: [mem 0x000000001000b000-0x000000009e0a6fff] usable
[    0.000000] BIOS-e820: [mem 0x000000009e0a7000-0x00000000acbfefff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000acbff000-0x00000000acd7efff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000acd7f000-0x00000000acdfefff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000acdff000-0x00000000afffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000024dffffff] usable

I have also tried 32-bit addresses but it's the same. I have also searched for 'mem', 'bad' etc and not found anything. Unfortunately I only get errors from the bad ram every few days so can't know if it's working yet.

The actual output from memtest86+ is:


I also tried adding memtest=1 parameter to get the kernel to run it's own test but this was also ignored.

  • badram is a kernel patch, not official feature. with unpatched kernel, you can try your luck with the memmap=nn[KMG]$ss[KMG] (mark region as reserved) or memtest=n (test all ram n times and auto reserve bad detect regions). good luck! Nov 20, 2020 at 11:59
  • if these parameters work for you please write an answer to your own question. I don't have bad ram and setting up a VM with emulated bad ram is too much effort so I can't write you an answer that's verified to actually work for someone Nov 20, 2020 at 12:02
  • saw your edit too late, if memtest=1 does not work, try larger number, for example memtest=10 (multiple passes with multiple patterns, more likely to detect) then check dmesg that it actually ran the memtest: paste.ubuntu.com/p/cKb5vFyVDX - of course, in my case, there is no bad ram to find... Nov 20, 2020 at 12:36
  • 1
    memmap is working but only if I edit the command line in grub myself before booting - I can't pass it through properly in /etc/grub/default because the $ gets removed. I have tried escaping, double escaping, quoting, everything. I think it's the $0 it's seeing, so maybe I have to format the address as KMG instead. What is 0x50d5000 in k? Sorry!
    – eggbert
    Nov 20, 2020 at 13:21
  • 1
    In /etc/default/grub you have to write literal $0 as \\\$0 (assuming it's inside double quotes in the /etc/default/grub file). This is because the shell eats one layer of escape, and grub itself also eats one (allows $variables in grub.cfg) so you need two. Escape $0 once is \$0, escape twice is \\\$0. Check cat /proc/cmdline to see the literal string that was passed to kernel. Nov 20, 2020 at 13:42

2 Answers 2


Finally managed to get this working using GRUB_BADRAM:

[    0.000000] BIOS-e820: [mem 0x000000001000b000-0x0000000050d547ff] usable
[    0.000000] BIOS-e820: [mem 0x0000000050d55400-0x0000000058d547ff] usable
[    0.000000] BIOS-e820: [mem 0x0000000058d55000-0x000000009e0a6fff] usable

I was trying to use grubby to update a single kernel because I was worried about leaving the system un-bootable but it's so easy to edit the kernel parameters in grub before booting that it's not worth worrying.

I also tried to use memmap which worked but it was completely impossible to pass through the $, it kept getting eaten by grub.


There's no such option as badram, instead you have to use memmap:

                        [KNL,ACPI] Mark specific memory as reserved.
                        Region of memory to be reserved is from ss to ss+nn.
                        Example: Exclude memory from 0x18690000-0x1869ffff
                        Some bootloaders may need an escape character before '$',
                        like Grub2, otherwise '$' and the following number
                        will be eaten.

badram is a GRUB option: How to blacklist a correct bad RAM sector according to MemTest86+ error indication?

  • Thanks for the grub badram pointer. Great! Nov 20, 2020 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .