Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Hardware

Memtest86+ Is Back After 9 Years (tomshardware.com) 60

Memtest86+ just got its first update after 9 years. The program has reportedly been rewritten from scratch and is back in active development. The new version, 6.0, features a plethora of updates to bring the application up to date, and support the latest system hardware from Intel and AMD. Tom's Hardware reports: For the uninitiated, MemTest86 was originally created back in the mid 1990s, and was one of the earliest DDR memory testing applications for personal computers. But development stopped in 2013 once Memtest86 was split into Memtest86 and Memtest86", with the former being bought by PassMark. Officially, we don't know why development stopped. But compared to the now modern Memtest86, Memtest86+ is the open-source variant.

Needless to say, version 6.00 features a lot of updates, which were required to bring it up to modern standards compared to the 2013 version. The new version includes completely rewritten code for UEFI-based motherboards, the modern version of a BIOS, for both 32-bit and 64-bit versions of the application. Furthermore, the application features added support for x64 long mode paging, support for up to 256 cores, added detection for DDR4 and DDR5 memory -- since DDR3 was the latest memory standard in 2013 -- and adds support for XMP version 3.0.

CPU support has been significantly enhanced, addingdetection for all pre-Zen and AMD Zen-based processors ranging from the Ryzen 1000 series to 7000 series, and any older parts that were made after 2013. Intel support has also been added for chips up to 13th gen Raptor Lake. Finally, the last patch notes indicate version 6.0 adds support for older Nvidia and AMD chipsets - probably pre-2010 since it mentions Nvidia nForce chipsets, along with numerous bug fixes, optimizations and enhancements.

This discussion has been archived. No new comments can be posted.

Memtest86+ Is Back After 9 Years

Comments Filter:
  • by The Evil Atheist ( 2484676 ) on Tuesday October 25, 2022 @05:32AM (#62996047)

    Officially, we don't know why development stopped.

    Because it wasn't sexy or motivating to do.

    Nothing excites programmers more than rewriting something from scratch.

    • by AmiMoJo ( 196126 )

      It's one of those annoying things to develop where the cycle time for making a change and testing it is rather long, and you need a supply of broken hardware to test it on.

      I haven't looked lately but maybe it's easier now. QEMU or something?

    • I must be weird then. I love rewriting old junk. I was just toying around with the old Fractint codebase to see if I could get it to run multithreaded with AVX. I'm having some issues getting the types lined up for the SIMD intrinsics, but that's where you learn stuff :)

      • *in my Jack Sparrow voice*

        We need to get you a woman mate.
      • by gweihir ( 88907 )

        Revisiting old things and looking at how you (or somebody else) did it back then and thinking about how to do it better is the hallmark of somebody going for true mastery. I do it occasionally as well. My guess is most people writing code would rather forget what they did back when (or recently). Of course, with that attitude, they will never get really good at it.

    • by jonadab ( 583620 )
      > Because it wasn't sexy or motivating to do.

      Eh, maybe, but I suspect it was mostly because further development was *unnecessary*
      as the software was complete and did what it needed to do. It isn't the sort of thing that
      would need to be constantly updated. It's inherently technical software; regular end users
      do NOT try to diagnose what is wrong with a computer when it malfunctions; they either
      call an expert, or throw the thing out. People who test specific components to diagnose
      a problem, don't need a
  • by evanh ( 627108 ) on Tuesday October 25, 2022 @06:34AM (#62996103)

    Extracted it from the Grub ISO download. I failed to fine the source code mentioned in the readme.

    The V5.01 binary shipped with Ubuntu 20.04 didn't work. It would consistently lock up a couple of seconds in. Though, older compiles of 5.01 worked fine.

  • by poptopdrop ( 6713596 ) on Tuesday October 25, 2022 @06:57AM (#62996145)

    I realise that Linus throwing out the venerable version-naming convention has encouraged others to follow suit, but am I the only one who thinks using double-quotes in a version name is asking for trouble ? /s

    • Naming rules are for the weak of heart. Watch how the knowledgeable few put their mastery of escape characters into use while the society of the unlearned peasantry perishes under the chaos caused by unsanitized inputs.
    • mathematicians love it x, x', x''
    • Pronunciation will be tricky if not stated clearly in the docs. It is pronounced "memtest86 quote", "memtest86 doublequote", "memtest86 rabbitears", or "memtest86q"

  • by Kiaser Zohsay ( 20134 ) on Tuesday October 25, 2022 @06:58AM (#62996147)

    And all because Linus gave it an offhand mention in a post about having a bad RAM chip in his desktop machine, and merges on his laptop were taking sooo long. When I read that the first time I went "Oh yeah, I remember MemTest86". I guess I'm not the only one.

    • by tlhIngan ( 30335 )

      And all because Linus gave it an offhand mention in a post about having a bad RAM chip in his desktop machine, and merges on his laptop were taking sooo long. When I read that the first time I went "Oh yeah, I remember MemTest86". I guess I'm not the only one.

      And the fact that Linux can take badram= as a command line parameter which you get from Memtest86+ so Linux will not use the bad memory at all...

    • by bobby ( 109046 )

      I use Memtest86 fairly frequently, and it's one of the first things I grab when in doubt of a system's integrity. I've gone at least 15 or 20 years with very few RAM problems, but in the past 3 months have had to replace at least 4 bad DIMMs and SoDIMMs. Not sure of the cause, hopefully just coincidence, but am sure glad for Memtest86.

  • The source code for memtest86+-6.00 appears to be unavailable. It is not listed as are the binary releases, and does not seem to be in the download directory for the current releases under any obvious name.

  • with source code NOT available as promised. Doesn't belong here.

  • Thi sia very good tool have, I have used it before when I worked in tech support and also used MEM test tool that come with Ubuntu Live session as well. Not to mention SystemRecue, which is very cool tool.
  • So, this program gets updated literally days after Linus Torvald's kernel work is slowed down by a bad memory stick in his workstation: https://www.theregister.com/20... [theregister.com]

    Suspicious or what!

    • Yep nothing says conspiracy more than updating a program after someone else reported it worked as intended.

  • I still have Memtest86+ in my boot menu. Not because I've ever really needed to use it (although I think I have once or twice), but because if I remove it from Grub my system won't boot into either Manjaro or Windows anymore (I dual boot). I have no idea why, but the issue goes away if I leave Memtest alone so it stays. I wonder if this update will fix the issue?
  • This thing has saved me so many ours of looking for other problems. I remember one time where I hat to run it for two days to find a rare bit-error in an Infinion module.

  • Did it disappear from existence? Pretty sure I’ve used it several times in the past 9 years. Why do people think that software stops working?

    • by pjt33 ( 739471 )

      Because it does? Bit rot is a sufficiently common phenomenon to have a name.

    • It had not been updated so it did not work for some newer hardware. And thus people stopped using it or even downloading it.
    • by higuita ( 129722 )

      because it actually stopped working!

      the old memtest86 didn't work in UEFI systems... if your bios had support to boot the old bios mode, you had to change it, run memtest86 and then turn it off again... on systems that only allowed UEFI mode, you could not run it at all

      IMHO, that was the main reason why development stopped, trying to change the old code that was harder to run on modern hardware on each year, removed most motivation... but of course, this tools is still needed and now some people got enough

  • by RevRagnarok ( 583910 ) on Tuesday October 25, 2022 @09:08AM (#62996443) Homepage Journal
    PassMark themselves seem to have chimed in on the discussions there with some of the history, forking, etc: https://forums.tomshardware.co... [tomshardware.com]
    • by Anonymous Coward

      PassMark themselves seem to have chimed in on the discussions there with some of the history, forking, etc: https://forums.tomshardware.co... [tomshardware.com]

      Excerpt about the differences between PassMark's MemTest86 and the open source MemTest86+:

      Starting from MemTest86 v5, the code was re-written to support self-booting from the newer UEFI platform. The core software still remains free to use without restrictions. The MemTest86 v4 project (for traditional BIOS) is still maintained and remains GPL open source, for use on old machines. However, from V5 with the the software is being released under a proprietary license.

      PassMark did five major releases between 20

  • "The program has reportedly been rewritten from scratch"

    Why was I waiting to read that this had been written in Rust?
    • by DrYak ( 748999 ) on Tuesday October 25, 2022 @10:03AM (#62996597) Homepage

      Why was I waiting to read that this had been written in Rust?

      Well, given that 99.99% of Memtest86+'s activity consist of writing random pattern to arbitrary addresses of unallocated memory,
      that would be the least probably target for a Rust rewrite.

      Unless you're going for the world record for the largest fraction of a production software wrapped inside Rust unsafe sections.

      • Unless you're going for the world record for the largest fraction of a production software wrapped inside Rust unsafe sections.

        All you need is: unsafe { *x=y; } and unsafe { y=*x; }
        That you think it's something else is very telling.

  • On 2 October 2022, I downloaded the freeware Memtest86 (without the +) from PassMark at https://www.memtest86.com/ [memtest86.com]. I set it up on a USB thumb drive. When I booted from the thumb drive, Memtest86 said it is version 10.0. The components -- including a "MemTest86 User Manual Version 10.0" -- are dated 28 September 2022. Previously, I was using Memtest86 v9.0 from 2021. Before then, I used even earlier versions. I do not remember what was the first version I used.

    The "MemTest86 User Manual" contains appe

  • From one of the comments left in the original article, it sounds like this new memtest86+ is triggering antivirus software like Windows Defender to flag it as infected with a trojan horse.

    Seems possible just because it does such low-level memory manipulation. But that's going to scare off a lot of people from using it if they can't get that fixed.

  • Memtest was the first thing I ran on any computer that sat on my bench back in my repair shop days. Saved lots of headaches. I remember running it on 128gb servers for what seemed like days looking for that one bad address. Good times.
  • It's a sad case that we even need this. Why doesn't every system use ECC memory with built in error reporting? Memory is much cheaper than in the days of hand-wound cores.

    • Speed. Cost. I for one wouldn't be using ECC even if it was available to me. The downside are more important than my use case on my PC.

      Have ECC RAM in my server though.

    • That's a good point. ECC ram never got more common as memory prices fell.

    • Re:A sad case (Score:4, Interesting)

      by higuita ( 129722 ) on Tuesday October 25, 2022 @06:12PM (#62997927) Homepage

      blame intel!

      Intel refuse to support ECC in all systems other than server (and maybe some big workstations). laptop and desktop have no ECC in intel.
      AMD supported ECC in many CPUs, even in laptops, but as ECC require more hardware, both RAM and MB get more expensive and when the alternative do not support it and so always use cheaper RAM and MB, most MB builders and PC makers end not supporting too ECC. As there is little support for ECC, (again, other than server market... mostly), prices remain high (in server people can pay more, lack of mass production don't drop the prices)

      If intel supported ECC, people would start to get that extra option and slowly mass production would increase, dropping the prices and pushing even more adoption by users.

      Notice that DDR5 (i think is this one) already have a "forced" ECC, as memory speed as soo high, that ECC is now a spec requirement... but sadly, while AMD can use the full ECC, as intel do not support it, the DDR5 ECC spec is just for the memory chips error check, will not protect memory from errors in other parts of the system, where true ECC can do it.
      Intel do not care about user crashes data corruption, user get a small performance increase (depending of the task, usually if very memory intensive) and they believe that user will blame other components or windows and get away from this for all this years. That is why Linus Torvalds publicly blamed intel for all this:

      https://arstechnica.com/gadget... [arstechnica.com]

      So remember this the next time you buy a system, choose AMD and buy ECC ram ... or buy intel and keep supporting this stupid move

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...