Dealing with faulty RAM modules in 2026

https://blog.kumio.org/posts/2026/01/memtest86plus.html

How to test and safely keep using your janky RAM without compromising stability using memtest86+ and the memmap kernel param.

50 points · 6 comments · view on lemmy.world

6 Comments

F04118F@feddit.nl · 4 pts · 222d (1 reply)

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!

kumi@feddit.online · 6 pts · 222d

Thank you, I'm glad you like!

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 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$START not @. And you can use human sizes like 128M$RANGE.

jwt@programming.dev · 1 pts · 222d

Ooh, that rasdaemon looks interesting. thank for sharing!

Corbin@programming.dev · 1 pts · 221d (2 replies)

Well done. I recently revived the BadRAM kernel patch in order to do something similar; memtest86+ supports that functionality too, using , , , .

kumi@feddit.online · 4 pts · 221d (1 reply)

I'm curious: What's motivating you to do that when the memmap param can do the same without patching?

Corbin@programming.dev · 1 pts · 203d

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.