Memtest86+ 7.0 Released With IMC Polling & Initial ECC Polling

[bug77]

Great stuff. With those out of the way, developers can now concentrate on rewriting it in Rust! *runs and hides*

(yeah, yeah, I know, it runs before/instead of everything, memory safety means nothing here)

[debrouxl]

Auxiliary upstream memtest86+ maintainer here.

That's not a bad idea. I wonder if the authors would be receptive to some kind of way to integrate it into an automated setup. It would need to accept some run parameters from the UEFI settings and it would need to return some kind of results the same way for the host OS to log.

I assume there's some kind of infrastructure in UEFI for this kind of thing, but I'm not familiar with it.

Passing command-line parameters is supported, though the CLI isn't that rich: for instance, no selection of tests or processor cores (yet, at least).

However, no way to export results is currently implemented, because memtest86+ really does not want to take the easy route, namely depending on the UEFI boot services, which could indeed be used to implement such functionality, for two reasons:
* UEFI boot services leave some memory - on some computers, large amounts thereof, in the hundreds of MBs - permanently locked and therefore un-testable, which runs strongly counter to the goal of a well-behaved memory testing program;
* unlike PassMark's proprietary and commercial software with a severely crippled no-fee version, memtest86+ still wants to support non-UEFI computers, which isn't much of a technical burden anyway, and does not want to cripple functionality for these computers.

The most likely route for implementing data export data is supporting FAT16/FAT32 on a USB MSD. That still requires implementing a sizable amount of code, probably custom code even, in order to fit memtest86+'s peculiar constraints (a memory image which fully relocates itself dynamically at runtime every once in a while, and leaves as few memory pages locked as possible, so that as much memory as possible can be tested)

It seems memtest86+ has supported secure boot since 6.10, per this article https://www.phoronix.com/news/memtest86-plus-6.10

Secure Boot is indeed supported, and has been tested to work on many computers. However, memtest86+ binaries are not signed with Microsoft's key, or any usual distributor's key. For now, one needs to sign it with their own key, the validation key for which needs to be inserted into your BIOS' MOK, just like what happens e.g. with DKMS for Linux kernel modules

[willmore]

Auxiliary upstream memtest86+ maintainer here.

Passing command-line parameters is supported, though the CLI isn't that rich: for instance, no selection of tests or processor cores (yet, at least).

That would be necessary, I believe as some sort of limits would be necessary to ensure that memtest86+ doesn't run forever, etc. it would probably need to be given information on how to report results as well.

However, no way to export results is currently implemented, because memtest86+ really does not want to take the easy route, namely depending on the UEFI boot services, which could indeed be used to implement such functionality, for two reasons:
* UEFI boot services leave some memory - on some computers, large amounts thereof, in the hundreds of MBs - permanently locked and therefore un-testable, which runs strongly counter to the goal of a well-behaved memory testing program;

Ugg, yes, that does sound like a problem. Rely on the UEFI support and not be able to do your job or reimplement it all and *enjoy* all the pain that provides. If I had to make a guess, I would say that the former would be the way to go as this isn't meant to be as complete of a test as one would want to do on a new machine, but more of a 'are we still sane' periodic test. While I agree that I would like the most thorough test that can be done, I do appreciate that compromises often need to be made. Expecting you to implement device drivers, filesystem drivers, etc. in memtest86+ seems like asking too much.

The most likely route for implementing data export data is supporting FAT16/FAT32 on a USB MSD. That still requires implementing a sizable amount of code, probably custom code even, in order to fit memtest86+'s peculiar constraints (a memory image which fully relocates itself dynamically at runtime every once in a while, and leaves as few memory pages locked as possible, so that as much memory as possible can be tested)

Understood. You live under some unique constraints and I, at least, appreciate the work you and the other developers do on this very critical piece of software infrastructure. Thank you.

[debrouxl]

That would be necessary, I believe as some sort of limits would be necessary to ensure that memtest86+ doesn't run forever, etc. it would probably need to be given information on how to report results as well.

On the one hand, counter-intuitively, especially in the absence of a way to store test result information, that memtest86+ runs forever can be considered more of a feature than of a limitation.
On the other hand, for the benefit of users who have a good use case and are aware of the consequences, we're open to the idea of limiting the number of passes
If you have such a use case, you can post about it in https://github.com/memtest86plus/memtest86plus/pull/343 . It may help prioritize this feature.

[Nth_man]

if you just want a quick and dirty "does my xml/ram overclock"-works test just use stress-ng

Do you mean xmp/ram?

[Old Grouch]

On the one hand, counter-intuitively, especially in the absence of a way to store test result information, that memtest86+ runs forever can be considered more of a feature than of a limitation.
On the other hand, for the benefit of users who have a good use case and are aware of the consequences, we're open to the idea of limiting the number of passes
If you have such a use case, you can post about it in https://github.com/memtest86plus/memtest86plus/pull/343 . It may help prioritize this feature.

The obvious place to 'store' test-result information is the screen. Either plain text, base-64 encoded info, or a QR-code (which could be quite information dense if pixel-addressing is possible) or similar error-correcting code were used. The relative ubiquity of smartphones with cameras, and often the ability to interpret QR codes makes this much more viable than the past. Just don't blank the screen at the end of a run.

If you want to get funky, build a 'flasher' on the screen that gives you a channel out. The conceptually simplest method is a photodiode taped to the screen that is read by a separate device, which may or may not emulate a keyboard as well to give you a (control) channel in. You could almost certainly get a smartphone to 'read' and encoded area on the screen that varied over time. Otherwise, just use a video-game 'light-gun', which is 'just' a photodiode. (Some programming required). There's likely some Arduino or Raspberry Pi kit that does what you need.

[ALRBP]

That's not a bad idea. I wonder if the authors would be receptive to some kind of way to integrate it into an automated setup. It would need to accept some run parameters from the UEFI settings and it would need to return some kind of results the same way for the host OS to log.

I assume there's some kind of infrastructure in UEFI for this kind of thing, but I'm not familiar with it.

I have a recent high-end ASUS motherboard, and it performs some kind of automated memtest regularly on bootup (shown on the mb embedded screen for a few minutes).

[stormcrow]

that's not really possible as you cant test ram while the system is running.
some very early ram tester even ran from gpu memory so they could test all of the system ram.

if you just want a quick and dirty "does my xml/ram overclock"-works test just use stress-ng

Not strictly true. You can test (and must test - otherwise memtest86/+ wouldn't work!) while the system is running. You just shouldn't do the kind of testing memtest does on a fully operational multi-process/multi-user system in use, it needs to be dedicated to that single task to do it correctly, and with as minimal a physical RAM footprint as possible. Even then you must swap around your RAM modules to test the area taken by the OS and program doing the testing.

You can still "test" RAM in any OS that allows locking physical RAM addresses, depending on what your goal is. You just allocate and lock a physical region in RAM for your use then keep writing patterns to it and scanning/comparing the result.

[AlanTuring69]

I run memtest86+ (open source only) every time before I boot to make sure the VIA hasn't nanochipped my special encrpytion (ecc) memory with backdoors. I bleachbit the ram after shutdown too of course...

...

and memtest every new PC, and sometimes during RAM upgrades / reseats. It's a great program.

[thomasjkenney]

(yeah, yeah, I know, it runs before/instead of everything, memory safety means nothing here)

My mentor told me an awful long time ago that you'd have a hard time allocating a buffer to construct an error message for an out-of-memory error.