Memtest86+ 7.20 Adds Support For Intel Arrow Lake & AMD Zen 5

[phoronix]

Phoronix: Memtest86+ 7.20 Adds Support For Intel Arrow Lake & AMD Zen 5

Memtet86+ 7.0 debuted back in January while now as we approach the end of 2024, Memtest86+ 7.20 is now available as the latest significant update to this open-source memory tester commonly used on Intel and AMD systems...

https://www.phoronix.com/news/Memtest86-Plus-7.20

[tildearrow]

Typo:

Memtet86+ 7.0 debuted back in January

[avis]

Binaries are on the front page:

https://memtest.org/

[willmore]

I've been using this for years and gotten a lot of benefit from it so I decided it was past time to donate. They don't have a way to donate.

[debrouxl]

memtest86+ co-maintainer here. Thanks for the news item, Michael.

The NUMA support is disabled by default; on specific pieces of hardware, usually multi-socket servers, it allows testing at higher bandwidth. On my quad-socket PowerEdge R820 (which I bought with my own money, like most pieces of hardware I use for memtest86+ testing), whose IVB-EP Xeons only have 2 QPI links, there's a major bandwidth bottleneck when not enabling NUMA awareness: the run time for testing 256 GB of DDR3-1866 (maximum speed) RAM is cut from ~55h down to < 8h in NUMA-aware mode.
I'd really like to be able to test the NUMA awareness code on a 4S Skylake or Cascade Lake platform equipped with 1 DIMM Per Channel and processors supporting 3 UPI links, but that's easily 2-3 months of day job wages, even used on eBay...

I've been using this for years and gotten a lot of benefit from it so I decided it was past time to donate. They don't have a way to donate.

Well, there used to be a way to donate money, but it was disabled because of issues with Paypal... I guess they performed something like an improper lockout of Sam's account. It wouldn't be the first or last software developer / creator and therefore project harmed by Paypal, Patreon, etc.

The alternative way to donate indicated on memtest.org is to perform direct hardware donations, or to perform tests on specific pieces of hardware and provide a picture as proof. Both old and new hardware is interesting:
* tests on motherboards with old NVIDIA and VIA chipsets, especially, would allow uncommenting up to well over a dozen PCI IDs for SMBus controllers (standalone or behind PCI/ISA bridges) in https://github.com/memtest86plus/mem...stem/i2c_x86.c . I found VT8237S myself in an electronics equipment trash bin several weeks ago, yielding https://github.com/memtest86plus/memtest86plus/pull/448 (postponed until after this release);
* modern hardware has different usefulness.

For LA64 support, LoongArch went far beyond donating hardware: they actually paid someone to go through the porting, testing, submission and integration process - which also enabled improvements in upstream. At the time of this writing, no vendor of AArch64 or RV64 platform has done that (well, publicly, but I'd undoubtedly know), and as a result, memtest86+ doesn't work on those platforms - yet. Not that ACPI, which is all memtest86+ supports so far, is popular on these platforms, granted. But they'll even be able to benefit from the preparatory work done by LoongArch.

[StandaSK]

The alternative way to donate indicated on memtest.org is to perform direct hardware donations, or to perform tests on specific pieces of hardware and provide a picture as proof. Both old and new hardware is interesting:
* tests on motherboards with old NVIDIA and VIA chipsets, especially, would allow uncommenting up to well over a dozen PCI IDs for SMBus controllers (standalone or behind PCI/ISA bridges) in https://github.com/memtest86plus/mem...stem/i2c_x86.c

I have some Socket 754 motherboards laying around, I think one of them had a VIA chipset? What would I need to check/test?

For LA64 support, LoongArch went far beyond donating hardware: they actually paid someone to go through the porting, testing, submission and integration process - which also enabled improvements in upstream. At the time of this writing, no vendor of AArch64 or RV64 platform has done that (well, publicly, but I'd undoubtedly know), and as a result, memtest86+ doesn't work on those platforms - yet. Not that ACPI, which is all memtest86+ supports so far, is popular on these platforms, granted. But they'll even be able to benefit from the preparatory work done by LoongArch.

That's really cool, nice to see them actually supporting the ecosystem.

[debrouxl]

I have some Socket 754 motherboards laying around, I think one of them had a VIA chipset? What would I need to check/test?

Thanks for your offer.
* visually, if there's no heatsink on the Southbridge chip, you can check the model number against the list of names below case PCI_VID_NVIDIA / case PCI_VID_VIA in the file I linked. VT8237R has the same PCI ID as VT8237 and is already supported by memtest86+, I tested a VT8237R-based MB alongside the VT8237S-based MB.
* you can also check the MB model online: some manufacturers do a good job keeping documentation pages for old MBs, or third parties sometimes do, and some of these pages list the chipset;
* from Linux, `lspci -nn` as root will report the appropriate information; from Windows, the likes of HWiNFO, SIV and CPU-Z should also make it possible to obtain the same information;
* from Linux again, SPD data from RAM sticks can sometimes (due to various shenanigans in motherboards and chipsets) be obtained from Linux through `decode-dimms` (package usually named i2c-tools), which may require `modprobe` of several modules beforehand: `eeprom`, `at1004` are the most common ones.

If your motherboards have a PCI ID for a SMBus controller or PCI / ISA bridge commented out in the NVIDIA or VIA sections of the memtest86+ source code, the general path is to uncomment the appropriate line in a copy of the linked file, build and test the modified copy of memtest86+. I extracted the list of PCI IDs from Linux's i2c drivers, and the NVIDIA and VIA drivers are relatively uniform (the pieces of hardware from this manufacturers are easier to deal with than those from e.g. SiS, resulting in few quirks in the driver), so it's expected to be correct and safe. Proof: picture of the memtest86+ screen containing SPD data (size, speed, usually manufacturer, model, date) displayed in the middle section.

Thanks in advance

That's really cool, nice to see them actually supporting the ecosystem.

Yup. Frankly, I'd have expected AArch64 or RV64 support to be contributed before LA64 support.

[willmore]

memtest86+ co-maintainer here. Thanks for the news item, Michael.
Well, there used to be a way to donate money, but it was disabled because of issues with Paypal... I guess they performed something like an improper lockout of Sam's account. It wouldn't be the first or last software developer / creator and therefore project harmed by Paypal, Patreon, etc.

The alternative way to donate indicated on memtest.org is to perform direct hardware donations, or to perform tests on specific pieces of hardware and provide a picture as proof. Both old and new hardware is interesting:
* tests on motherboards with old NVIDIA and VIA chipsets, especially, would allow uncommenting up to well over a dozen PCI IDs for SMBus controllers (standalone or behind PCI/ISA bridges) in https://github.com/memtest86plus/mem...stem/i2c_x86.c . I found VT8237S myself in an electronics equipment trash bin several weeks ago, yielding https://github.com/memtest86plus/memtest86plus/pull/448 (postponed until after this release);
* modern hardware has different usefulness.

I'll look through the page and through my bins of many things and see if we get any collisions. For numa hardware, the newest I have is a Dell R410 and an R620 each 2S. I have a lot of older single socket machines, so I'll have a look. Thank you!

[fitzie]

I ran this for a while on the zen5 with version 7.0 and it ran fine. I'll try it again once 7.2 hits fedora. It'd be nice to see some traction on secureboot support, like why not use the shim that linux uses.

[debrouxl]

It'd be nice to see some traction on secureboot support, like why not use the shim that linux uses.

It boils down to available maintainer time
I did start https://github.com/memtest86plus/mem...iscussions/370 about the review for shim integration, parts of which should be easier than with a general-purpose OS (the attack surface is very much lower because memtest86+ only cares about few classes of hardware, and besides, it exits the UEFI boot services), and Sam looked at it on his side, but that's it.

PRs which remain unmerged because they're insufficiently tested by maintainers include https://github.com/memtest86plus/memtest86plus/pull/387 . Tormod Volden has a pretty good clue about USB, but I haven't been able to make the code resulting from that PR produce the expected result on my side... and a single pair of computers.