Dealing with faulty RAM modules in 2026
How to test and safely keep using your janky RAM without compromising stability using memtest86+ and the memmap kernel param.
Syndicated from the fediverse. Read and engage on the original instance.
View original on feddit.onlinehttps://blog.kumio.org/posts/2026/01/memtest86plus.htmlOpen linkView original on feddit.online
6 replies
This is amazing!! I had no idea this was possible!
One point of feedback: not having worked with memmap before, it is not immediately obvious to me which hex means what (I am guessing RANGE@START? ). Would be nice to have a link to an explanation there.
I am definitely sharing this, thank you for writing the blog!
Thank you, I'm glad you like!
I just have the link to the kernel docs because I think they do a better job explaining it than I would 😁
But yeah, basically. Except for this use-case you want
RANGE$STARTnot@. And you can use human sizes like128M$RANGE.Ooh, that rasdaemon looks interesting. thank for sharing!
Well done. I recently revived the BadRAM kernel patch in order to do something similar; memtest86+ supports that functionality too, using , , , .
I'm curious: What's motivating you to do that when the memmap param can do the same without patching?
BadRAM specifiers can apply to stripes of memory corresponding to certain physical hardware failures. The memmap hack only allows for contiguous allocations. BadRAM's intended for repurposing consumer-grade RAM that might normally be thrown out, not for reconfiguring motherboards that have strange layouts.