--- title: "The Curse of Soldered RAM" slug: the-curse-of-soldered-ram url: https://listedarticles.com/articles/the-curse-of-soldered-ram canonical_url: https://blog.hardill.me.uk/2026/10/24/the-curse-of-soldered-ram/ content_type: blog_post language: en published_at: 2026-10-24T08:08:27.000Z updated_at: 2026-10-24T17:10:00.377Z author: "Ben Hardill" authored_by: human publisher: "Ben's Place" publisher_url: https://blog.hardill.me.uk/ topics: ["Hardware", "Linux", "Opinion"] license: all-rights-reserved word_count: 1068 reading_minutes: 5 citation: "Ben Hardill, Ben's Place. \"The Curse of Soldered RAM.\" 24 Oct 2026. https://blog.hardill.me.uk/2026/10/24/the-curse-of-soldered-ram/ (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # The Curse of Soldered RAM > Ben Hardill describes his Lenovo X1 Carbon developing crashing tabs and BTRFS checksum errors, confirming faulty soldered RAM with memtest86+, and working around the bad addresses with the Linux memmap kernel parameter instead of replacing a module, arguing soldered RAM is especially painful amid today's shortage-driven memory prices. The trend for soldered on RAM in modern laptops is truely evil especially in these current trying times of shortage induced high prices. I normally run 2 laptops, one for personal stuff and one for work stuff in a vein attempt to try and keep things separate and be able to leave the work one in the “office” at the end of the day. I blogged about when I got my c[urrent work laptop](https://blog.hardill.me.uk/2022/02/28/new-daily-driver/) back in 2021. This Lenovo X1 Carbon has been great, until recently when I noticed a lot more browser tabs crashing and every now and again the root filesystem would mark it’s self as ReadOnly, which was less than useful. ``` Oct 15 23:33:35 razor-crest kernel: BTRFS warning (device dm-0): csum failed root 257 ino 166754 off 5859786752 csum 0x31019647 expected csum 0x6d009929 mirror 1 Oct 15 23:33:35 razor-crest kernel: BTRFS error (device dm-0): bdev /dev/mapper/luks-571c7357-a343-49f3-993c-167c8c5dcec6 errs: wr 0, rd 0, flush 0, corrupt 3856936704, gen 0 ``` These failure made me wonder if there were RAM errors, so I added a [memtest86+](https://www.memtest.org/) boot image to my Ventoy USB stick and booted from it. ## Memtest86+ This tool boots an absolute minimal OS that then proceeds to write a bunch of patterns to every physical memory address possible and reads them back. If the value read back doesn’t match what was written then there is a problem. If left to run it will do multiple passes, because some errors only show up intermittently. But in this case it showed a bunch of errors almost immediately. In the past this would have been an easy fix, the output would have been enough to narrow down which of the DIMMs was faulty, or at worst you would pull one out and run the test again to do a binary search. Once identified you could just order a replacement DIMM (or take the opportunity to upgrade) and move forward. But in the search for even thinner laptops (because a DIMM socket adds ~6mm of depth) and maybe cynically ensure that any failures result in needing to buy a whole new laptop, RAM is now soldered directly to the motherboard of most laptops (things like the FrameWork are the exception) so unless you are skilled at replacing ball grid chips it’s not really an option to replace. Depreciation over 5 years and advances means it is actually probably time to find a new laptop, but I’d like to see if there is any way to keep the Lenovo X1 Carbon running as it’s still a very capable machine and could replace the even older Dell XPS 13 I use as my personal laptop. I’ll write about the replacement later. ## Memmap Whlie I wait for new laptop to arrive, I thought I’d see if I could make it more stable. A little research turned up 2 options that could be passed to Linux kernel to have it avoid using the bad sectors - badram - memmap `badram` turns out to be an out of tree patch that is only usually shipped in Debian/Ubuntu based distros. I run Fedora on this machine so that wasn’t going to work. `memmap` is a core kernel feature, so should be available on Fedora. You need to supply a list of memory addresses and lengths in the format `length$offset` on the kernel command line. Memtest86+ can output the correct format (for both `badram` and `memmap`) and even save it to a file, but I couldn’t get it work with the `iso` image I’d put on the Ventoy USB stick, so I had to resort to taking a photo of the screen. ![](https://i0.wp.com/blog.hardill.me.uk/wp-content/uploads/2026/10/PXL_20261023_211704140.MP_.jpg?resize=660%2C371&ssl=1) I then had to manually transcribe this, which as “fun”. All the documentation for adding kernel command line arguments say to edit the `/etc/default/grub` file and add the values to the `GRUB_CMDLINE_LINUX` entry and then run `grub2-mkconfig -o /boot/grub2/grub.cfg` ``` GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=\$memmap_val memmap=0x30$0x3fe90140,0x48$0x3fe90b08,0x48$0x3fe90ba8,0x48$0x3fe916a8,0xf0$0x3fe91c00,0x90$0x3fe92560,0xf0$0x3fe92f00,0x50$0x3fe93200,0x90$0x3fe93260,0xf0$0x3fe93800,0xf0$0x3fed4300,0x70$0x3fed4900,0x70$0x3fed4980,0xf0$0x3fed5400,0xf0$0x3fed5e00,0xf0$0x3fed6700,0xf0$0x3fed6d00,0xf0$0x3fed7000,0x30$0x3fed7a00,0xb0$0x3fed7a40" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true ``` I tried this but when I restarted the machine it failed to boot. I managed to get to grub screen and show the kernel command line it was trying to boot and it looked like the `$0` in the `memmap` entry had been replaced by `grub2-mkconfig`. This smacks of classic environment variable substitution (`$0` is usually the name of the script that is being run). I found this RedHat [bug](https://bugzilla.redhat.com/show_bug.cgi?id=2102303) describing a similar problem and it had a solution to add the value as variable. ``` # grub2-editenv /boot/grub2/grubenv set memmap_val='0x30\$0x3fe90140,0x48\$0x3fe90b08,0x48\$0x3fe90ba8,0x48\$0x3fe916a8,0xf0\$0x3fe91c00,0x90\$0x3fe92560,0xf0\$0x3fe92f00,0x50\$0x3fe93200,0x90\$0x3fe93260,0xf0\$0x3fe93800,0xf0\$0x3fed4300,0x70\$0x3fed4900,0x70\$0x3fed4980,0xf0\$0x3fed5400,0xf0\$0x3fed5e00,0xf0\$0x3fed6700,0xf0\$0x3fed6d00,0xf0\$0x3fed7000,0x30\$0x3fed7a00,0xb0\$0x3fed7a40' ``` Change the /`etc/default/grub` to ``` GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=\$memmap_val" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true ``` And run `grub2-mkconfig -o /boot/grub2/grub.cfg` again. This time things booted properly and the correct values can be seen in `/proc/cmdline` ``` BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.2.11-200.fc44.x86_64 root=UUID=869b183b-b858-40e5-8da7-e923dd367c2a ro rootflags=subvol=root rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=0x30$0x3fe90140,0x48$0x3fe90b08,0x48$0x3fe90ba8,0x48$0x3fe916a8,0xf0$0x3fe91c00,0x90$0x3fe92560,0xf0$0x3fe92f00,0x50$0x3fe93200,0x90$0x3fe93260,0xf0$0x3fe93800,0xf0$0x3fed4300,0x70$0x3fed4900,0x70$0x3fed4980,0xf0$0x3fed5400,0xf0$0x3fed5e00,0xf0$0x3fed6700,0xf0$0x3fed6d00,0xf0$0x3fed7000,0x30$0x3fed7a00,0xb0$0x3fed7a40 ``` I’ve created a text file on a USB stick with the `memmap` values so I can re-apply it if I end up doing a full reinstall. This should keep things running until the new laptop arrives and hopefully for a bit longer. Next task is to make sure I’ve backed everything I need up and then run `btrfs check --fix` to see if I can sort out the meta data in the file system.