Martin Steigerwald - 08.11.23, 09:05:02 CET: > > I did use that when I first built it. I'm now looking for something
> > that can run in the background, so I don't have to be without my
> > computer for that long. Otherwise I'd have to be without my computer
> > while it runs for a month trying to catch an intermittent problem.
>
> There is memtester in the package of the same name.
>
> Naturally it would not be able to test RAM that is currently in use.
Another addition to the RAM topic:
"lsmem" (from "util-linux") lists memory areas. With "-a" all of them.
With "chmem" you can temparily disable memory regions at runtime.
So after you found out which RAM bar it is, you may test your suspicion by
removing the specific RAM region with "chmem".
Disclaimer: This is all at your own risk. Removing RAM at runtime still
sounds quite a bit like asking for trouble to me. I tried it once out of
curiosity and it appeared to work. However… in any case you get to keep
the results, even if those are undesirable :). I advice against physically
removing the RAM bar at runtime after issuing "chmem", unless you are 100%
sure that your hardware is prepared to handle hot removal.
I'd still test with memtest86+ and just replace the offending RAM bar. I do
not really have experience concluding the affected RAM bar from the output
of memtest86+, but maybe others know how to do that.