memtest86+ v6.0 Released As Rewritten Open-Source RAM Tester

[debrouxl]

Oh. I did not receive any notification for a new issue on memtest86plus/memtest86plus, and I can't see it in the list of open or closed issues either, so indeed, it looks like something's up

[Anux]

Maybe a direct link works? https://github.com/memtest86plus/mem...lus/issues/195

[debrouxl]

I had tried that too, but nope, 404 for me, despite being logged in... Nothing in the notifications, either.
I have push rights but I'm not an owner of the organization or repo, though.

[Anux]

Yeah its not a thing of pressure, I made a support ticket to the github guys. So far the GRUB version rulez.

[timrichardson]

How is this safe for your memory if it's not written in Rust?

[Jabberwocky]

I personally found memtest86 rather slow in finding errors. I much rather use google's stressapptest, I only wish it was included in the main repo of more distro's.

This makes sense but not exactly apples to apples when comparing it to memtest86*. I have not used stressapptest before but I'll certainly try it out! Thanks for that.

* IMO an application won't ever be able to do what a low level software like memtest86 does. Application level tests are really messed up by OS memory and scheduling management, especially in recent years with transient execution CPU vulnerabilities. Additionally stressapptest might cause problems with hardware (cooling) or running into driver bugs.

If you ignore my tEcNiCAlLy OCD:
Step1: Run stressapptest
Step2 Run memtest86 (if stressapptest does not detect any problems and stability problem persists)

[debrouxl]

How is this safe for your memory if it's not written in Rust?

Writing self-relocating code which communicates through common variables, contains at least one infinite loop and accesses an amount of memory bounded only by the physical memory (minus several reserved pages for e.g. USB controllers) is an interesting exercise in any language capable of bare metal execution.
Besides freestanding low-level C++, Rust is probably the main contender for a non-C implementation of such code, but I'm not convinced either brings any strong decisive advantage over the current, relatively small amount of C using GCC inline assembly with C operands.

[grok]

. Keep in mind that the longer a machine is in service, the more likely its memory is to develop errors. This is one reason I tend to buy new PCs with a slightly lower amount of memory and then do a mid-life upgrade to 2x the amount (i.e. by replacing the existing 2 DIMMs - and it's always better to run 2 DIMMs instead of 4, if you can).

This is one reason to use a "DIY" desktop, you can simply slow the RAM down vs throwing a Dell or HP to the trash because it won't let you. Although sometimes the Dell still is in good shape after 15 years vs a rust bucket on life support.

[debrouxl]

Per https://github.com/memtest86plus/mem...ent-1369274968 , Secure Boot support in memtest86+ now works well on most computers it has been tested on, and the supporting code is therefore now part of the main branch in the memtest86+ repository.