6 ms·

Memtest86 v6.00 with UEFI support released

115 points by conductor 4y ago

imwillofficial 4y ago
A thankless champion of quality tools. Memtest, I love you.
- systems_glitch 4y ago
  Donate. That's how we support the open source projects we depend on!
  - imwillofficial 4y ago
    Will do! I've been using memtest since like 2006.
- rasz 4y ago
  Which one? passmark or plus one?
  - imwillofficial 4y ago
    The plus 1 I believe
pt_PT_guy 4y ago
Isn't there a confusion between memtest86 from passmark and memtest86+? and memtest86 from passmark has a lot of nice features that aren't available MemTest86+, includin UEFI support, writing logs to disk, fully 64bit code, additional RAM tests, benchmarking, row hammer testing and more? and passmark shows that: https://www.memtest86.com/compare.html https://www.memtest86.com/compare.html
- anderskaseorg 4y ago
  Yeah, title should be Memtest86+ 6.0.0, not Memtest86 6.0.0. The original (PassMark) Memtest86 has been proprietary since 2013.
  - conductor 4y ago
    I guess HN has stripped out the "+" sign from the title.
  - mjevans 4y ago
    Could a mod or someone with privileges please change the title to: Memtest86plus ???
mastax 4y ago
I wonder what this changelog entry means: > Add support for SDRAM Surely it had support for SDRAM before, since DDR, DDR2, ... are all SDRAM. Edit: I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM", referring to Single Data Rate SDRAM.
- xxpor 4y ago
  >I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM", referring to Single Data Rate SDRAM I have seen some dumb naming choices in my time but that might just take the cake.
  - Fatnino 4y ago
    The USB waves hands everything is a masterclass in how not to name things.
  - mastax 4y ago
    Well DDR SDRAM hadn't been invented yet, and since everyone calls DDR SDRAM "DDR" it's not particularly confusing in context.
systems_glitch 4y ago
Glad to see this finally out of beta! I've been using the various UEFI beta releases for a while, many new systems won't legacy boot the old memtest86+ correctly. Every machine in the shop, every server deployed, every customer repair (industrial control) gets memtest86+ after assembly and before going any further.
frou_dh 4y ago
I've returned faulty RAM after confirming a suspicion using MemTest86 (the PassMark one), several times over the years. In that situation, it's so nice to actually have some evidence to point to (a photo of the test results screen).
- linsomniac 4y ago
  Memtest is awesome, I've used it for decades and run it on every new machine I get. It's great at detecting memory, bus, and CPU problems. We had a Dell R640 rackmount that arrived and part of our burn-in testing is running memtest, which said one of the modules had a problem. I contacted Dell support and they had me run the Dell built in memory test, which IIRC took something less than an hour. Memtest was taking around a day to generate this error. Dell support didn't want to replace it because their built in test wasn't showing anything. This was maybe the 5th or 6th same model server we had gotten and all of them were clean, so I really didn't want to put this into production. Could have been a memory problem, could have been CPU or motherboard issue... Went back and forth a few times, and finally contacted our sales person asking them what our return window was for the server. They reached out to support, who contacted us and said "Fine, we'll send you a replacement, but only this one time!" Usually I've gotten really good support from Dell Pro Support, but this time I was pretty disappointed.
  - booi 4y ago
    This is why I rarely ever bought dell pro support. It's easier to take the savings and buy an additional unit if anything ever goes wrong (assuming you buy enough machines to make this economical). After a while you really don't need dell support to help and it's cheaper and faster to just replace the ram/drive/backplane/server.
    - linsomniac 4y ago
      This. This is what I did when I had ~100 servers, mostly lower end Supermicro, just buy an extra unit. But now I have ~20 higher end Dell boxes ($13K), and the pro support makes more sense, especially since maybe only a third of them are on support. I used to buy a couple machines a month, now I'm buying a machine or two a year. As I said, Pro Support has been fantastic for every other issue I've had, it was just this one memory issue. For comparison, a couple years ago we had a machine in production that system load went crazy on, 300-400 in "uptime". Nothing was really goning on on the machine. I ended up with 2-3 engineers helping me out as the path of the sun moved me into different support regions. They couldn't pin it down to any specific thing, but ended up replacing a couple SSDs, the RAID card, and the backplane. I'm pretty sure it was the LiteOn SSDs soiling the sheets, but that's what they ended up doing and we've been good since then.
sigjuice 4y ago
Is there potential for UEFI-based aarch64 systems? Or is the code too specific to x86?
- MisterTea 4y ago
  Already done. https://en.wikipedia.org/wiki/Windows_RT#History https://en.wikipedia.org/wiki/Windows_RT#History Windows is (was?) so deeply intertwined with x86 that MS bastardized their early ARM platform with ACPI and UEFI so they didn't have to write a new kernel HAL. Perhaps this has changed since Win RT. The RPi can also run tianocore, an open source reference uefi.
  - xxpor 4y ago
    UEFI/APCI is still a huge UX improvement over a device tree based solution.
    - MisterTea 4y ago
      That is not saying much as anything is better than device trees. We can do better.
- ajross 4y ago
  UEFI is just a (somewhat/very clumsy) C API, there's nothing particularly x86-specific about it. Obviously some aspects like access to particular devices is going to be platform-dependent, but there's no reason it couldn't be used wherever. The question is why would you want to? Almost nothing in the UEFI world beyond core system boot is actually used in practice, and even there all the hard/interesting bits (device selection and bootstrapping, initial security and signature checks) have to happen before UEFI entry anyway. So it's all duplicated code. Your BIOS has a bunch of boot hooks that have to run before UEFI starts, then UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite. It's all just a mess. Frankly if you want an implementation of a clean but featureful boot environment for PCs that extends across architectures, look to Chromebooks.
nope96 4y ago
This was 10+ years ago, but I had an issue with my motherboard not liking my RAM when in dual channel mode that memtest/memtest+ could not find, but Windows Memory Diagnostic (advanced tests) did find. So it's worth running both if you are ever stumped.

115 points by conductor 4y ago

imwillofficial 4y ago

A thankless champion of quality tools. Memtest, I love you.

systems_glitch 4y ago
Donate. That's how we support the open source projects we depend on!
- imwillofficial 4y ago
  Will do! I've been using memtest since like 2006.
rasz 4y ago
Which one? passmark or plus one?
- imwillofficial 4y ago
  The plus 1 I believe

pt_PT_guy 4y ago

Isn't there a confusion between memtest86 from passmark and memtest86+? and memtest86 from passmark has a lot of nice features that aren't available MemTest86+, includin UEFI support, writing logs to disk, fully 64bit code, additional RAM tests, benchmarking, row hammer testing and more? and passmark shows that: https://www.memtest86.com/compare.html https://www.memtest86.com/compare.html

anderskaseorg 4y ago
Yeah, title should be Memtest86+ 6.0.0, not Memtest86 6.0.0. The original (PassMark) Memtest86 has been proprietary since 2013.
- conductor 4y ago
  I guess HN has stripped out the "+" sign from the title.
- mjevans 4y ago
  Could a mod or someone with privileges please change the title to: Memtest86plus ???

mastax 4y ago

I wonder what this changelog entry means: > Add support for SDRAM Surely it had support for SDRAM before, since DDR, DDR2, ... are all SDRAM. Edit: I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM", referring to Single Data Rate SDRAM.

xxpor 4y ago
>I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM", referring to Single Data Rate SDRAM I have seen some dumb naming choices in my time but that might just take the cake.
- Fatnino 4y ago
  The USB waves hands everything is a masterclass in how not to name things.
- mastax 4y ago
  Well DDR SDRAM hadn't been invented yet, and since everyone calls DDR SDRAM "DDR" it's not particularly confusing in context.

systems_glitch 4y ago

Glad to see this finally out of beta! I've been using the various UEFI beta releases for a while, many new systems won't legacy boot the old memtest86+ correctly. Every machine in the shop, every server deployed, every customer repair (industrial control) gets memtest86+ after assembly and before going any further.

frou_dh 4y ago

I've returned faulty RAM after confirming a suspicion using MemTest86 (the PassMark one), several times over the years. In that situation, it's so nice to actually have some evidence to point to (a photo of the test results screen).

linsomniac 4y ago
Memtest is awesome, I've used it for decades and run it on every new machine I get. It's great at detecting memory, bus, and CPU problems. We had a Dell R640 rackmount that arrived and part of our burn-in testing is running memtest, which said one of the modules had a problem. I contacted Dell support and they had me run the Dell built in memory test, which IIRC took something less than an hour. Memtest was taking around a day to generate this error. Dell support didn't want to replace it because their built in test wasn't showing anything. This was maybe the 5th or 6th same model server we had gotten and all of them were clean, so I really didn't want to put this into production. Could have been a memory problem, could have been CPU or motherboard issue... Went back and forth a few times, and finally contacted our sales person asking them what our return window was for the server. They reached out to support, who contacted us and said "Fine, we'll send you a replacement, but only this one time!" Usually I've gotten really good support from Dell Pro Support, but this time I was pretty disappointed.
- booi 4y ago
  This is why I rarely ever bought dell pro support. It's easier to take the savings and buy an additional unit if anything ever goes wrong (assuming you buy enough machines to make this economical). After a while you really don't need dell support to help and it's cheaper and faster to just replace the ram/drive/backplane/server.
  - linsomniac 4y ago
    This. This is what I did when I had ~100 servers, mostly lower end Supermicro, just buy an extra unit. But now I have ~20 higher end Dell boxes ($13K), and the pro support makes more sense, especially since maybe only a third of them are on support. I used to buy a couple machines a month, now I'm buying a machine or two a year. As I said, Pro Support has been fantastic for every other issue I've had, it was just this one memory issue. For comparison, a couple years ago we had a machine in production that system load went crazy on, 300-400 in "uptime". Nothing was really goning on on the machine. I ended up with 2-3 engineers helping me out as the path of the sun moved me into different support regions. They couldn't pin it down to any specific thing, but ended up replacing a couple SSDs, the RAID card, and the backplane. I'm pretty sure it was the LiteOn SSDs soiling the sheets, but that's what they ended up doing and we've been good since then.

sigjuice 4y ago

Is there potential for UEFI-based aarch64 systems? Or is the code too specific to x86?

MisterTea 4y ago
Already done. https://en.wikipedia.org/wiki/Windows_RT#History https://en.wikipedia.org/wiki/Windows_RT#History Windows is (was?) so deeply intertwined with x86 that MS bastardized their early ARM platform with ACPI and UEFI so they didn't have to write a new kernel HAL. Perhaps this has changed since Win RT. The RPi can also run tianocore, an open source reference uefi.
- xxpor 4y ago
  UEFI/APCI is still a huge UX improvement over a device tree based solution.
  - MisterTea 4y ago
    That is not saying much as anything is better than device trees. We can do better.
ajross 4y ago
UEFI is just a (somewhat/very clumsy) C API, there's nothing particularly x86-specific about it. Obviously some aspects like access to particular devices is going to be platform-dependent, but there's no reason it couldn't be used wherever. The question is why would you want to? Almost nothing in the UEFI world beyond core system boot is actually used in practice, and even there all the hard/interesting bits (device selection and bootstrapping, initial security and signature checks) have to happen before UEFI entry anyway. So it's all duplicated code. Your BIOS has a bunch of boot hooks that have to run before UEFI starts, then UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite. It's all just a mess. Frankly if you want an implementation of a clean but featureful boot environment for PCs that extends across architectures, look to Chromebooks.

nope96 4y ago

This was 10+ years ago, but I had an issue with my motherboard not liking my RAM when in dual channel mode that memtest/memtest+ could not find, but Windows Memory Diagnostic (advanced tests) did find. So it's worth running both if you are ever stumped.