Memtest86+ in Ubuntu 20.04 doesn't work, switch to Coreboot branch or package new release v5.31b is available since 12/04/2020

Source package differences between memtest86+ 3ubuntu2 (which does a whole pass without errors) and 3.1ubuntu1 (which locks up at 79% in test 1) don't seem to explain this.

Status changed to 'Confirmed' because the bug affects multiple users.

memtest86+ 5.01 integrated in xubuntu 20.04 is crashing. It crashs at 30% (16GB) in the first test, after ~5s running. It is completely frozen.

I tried three PCs (all PCs: lagacy-boot, NO UEFI)

1.PC: memtest freeze , Desktop xubuntu 20.04 i7-2600, 16GB (4x4GB)

2.PC: memtest freeze , Thinkpad xubuntu 20.04 Thinkpad T520, i7-2670QM, 16GB (2x8GB)

3.PC: memtest is running fine: Thinkpad x220, xubuntu 18.04 i5-2520M 8GB (2x4GB)
I upgraded 3.PC to 20.04 - now memtest is also frozen at 60% (picture in attachment)

memtest86+ freezes on my am4 ryzen 3 2200G and 3200G systems. Runs fine on all my older systems. And Theirs nothing wrong with the memory on the amd system. Multiple passes with another tester.

Memtest in Ubuntu is very old, not updated since 2013, new Memtest86+ release v5.31b is available at http://memtest.org , dated 12/04/2020

*** Enhancements in v5.31b : ***
I've started compiling many codes branches to release public builds again! Here is Memtest86+ 5.31b, with many bug fixes in the core functions.

Also there is updated Memtest86+ branch at https://www.coreboot.org/Memtest86%2B - several people told, that this branch does work, where original Memtest 5.01 doesn't, see

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943752

Get memtest into debian, and it will get pulled in to Ubuntu ... eventually. The reason it hasn't been updated is that Ubuntu does not wish to fork memtest from Debian.

I think it is not the problem of the memtest version 5.01.

When I boot memtest 5.01 via USB-Stick it is working. No problems.

Only the integrated memtest 5.01 is making problems (started via grub, ubuntu 20.04)

memtest 5.01 was also working in ubuntu 18.04 (via grub). Then I upgraded to 20.04 -> Freeze problem

Installed binary package memtest86+ from Debian Stable (memtest86+_5.01-3.1_amd64.deb) in the Ubuntu 20.04 installation, that version runs fine on all my systems where the Focal Fossa version hangs.

No source code changes between these versions, just differences in the generated grub menu entries and some translations.

Might actually be a toolchain (compiler, linker) issue.

Can confirm the issue with a Dell Precision M4700: While memtest of Ubuntu 18.04.5 server iso works, memtest of Ubuntu 20.04.1 server iso freezes instantly after 1 second.

I have a similar problem.

I have Ubuntu Studio 20.04 installed.
The included Memtest86+ 5.01 freezes at 55% on test #2 every single time.

Memtest86+ 4.20 from an Ubuntu 14.04 DVD passes without error.
Memtest86+ 5.31b downloaded and burned to a CD-RW passes without error.

I have also encountered the issue where Memtest86+ 5.01 freezes on many machines with SMP activated. I do not trust v5.01 to give reliable results any more.

Same problem with HP Elitebook 745 G2, 2x8GB DDR3-1600.

memtest from ubuntu 20.04.1 installer (memtest-5.01) freezes after two seconds (first test at 51%). This happers every time. Tested single RAM chip at a time.

memtest from ubuntu 18.04.2 installer (memtest-5.01) works. I run it for 10h with both RAM chips attached without problems.

Hi,

I am also affected by this problem. It is an overflow check
using undefined behavior in an overflow check in test.c
that looks like "if (pe + SPINSZ > pe && pe != 0)"
but with >4G memory pe + SIINSZ wraps around.

I think the most simple fix would be the following:

2020-12-15 Bernd Edlinger <email address hidden>

 * Makefile: Use -fwrapv-pointer for test.c.

diff -u memtest86+-5.01.orig/Makefile memtest86+-5.01/Makefile
--- memtest86+-5.01.orig/Makefile 2020-12-15 06:50:42.000000000 +0100
+++ memtest86+-5.01/Makefile 2020-12-15 06:54:08.941390803 +0100
@@ -58,7 +58,8 @@
  $(CC) -c $(CFLAGS) -fno-strict-aliasing reloc.c

 test.o: test.c
- $(CC) -c -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin -ffreestanding test.c
+ $(CC) -c -Wall -march=i486 -m32 -O0 -fomit-frame-pointer -fno-builtin \
+ -ffreestanding -fwrapv-pointer test.c

 random.o: random.c
  $(CC) -c -Wall -march=i486 -m32 -O3 -fomit-frame-pointer -fno-builtin -ffreestanding random.c

The attachment "bug-fix for >4G memory" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

I tried the patch from #15 but it still hangs for me, albeit after 3min and
not after a few seconds like without the patch.

I tried version 5.31b and it works fine.
Core i5-4570, 16 GiB RAM.

There is a fork and major rewrite of the Memtest86+: https://github.com/martinwhitaker/pcmemtest
Unlike Memtest86+, PCMemTest can be used with UEFI as well as with legacy BIOS.

I think Ubuntu and Debian should follow Mageia Linux distribution, where Memtest86 is replaced with PCMemTest, see Release Notes:

https://wiki.mageia.org/en/Mageia_8_Release_Notes#PCMemTest

PCMemTest
This is a fork and major rewrite of the Memtest86+ memory test utility. Unlike Memtest86+, PCMemTest can be used with UEFI as well as with legacy BIOS boot. PCMemTest replaces Memtest86+ as the memory test utility on all the Mageia ISOs. It may also be installed in a user's system.

PCMemTest can be started from GRUB EFI mode like Linux kernel:

menuentry "Memory Test (PCMemTest" {
 search --no-floppy --set=root --file /install/pcmemtest
 set gfxpayload=640x400,800x600,1024x768
 linux /install/pcmemtest
}

I have the same issue as comment #6 on Ubuntu Server 20.04.1 installer that booted from a flash drive.

HW:

00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Desktop)
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)
00:17.0 SATA controller: Intel Corporation Cannon Lake PCH SATA AHCI Controller (rev 10)
00:1c.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #3 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 (rev f0)
00:1d.2 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #11 (rev f0)
00:1d.3 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #12 (rev f0)
00:1f.0 ISA bridge: Intel Corporation H370 Chipset LPC/eSPI Controller (rev 10)
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

Memtest86 5.01 hangs at 60% of first test on Ubuntu 21.04. The machine is Athlon II 640 on AMIBIOS 6.11 motherboard. I have seen another case just like this (hangs at 60%) on AskUbuntu. It worked fine when two 2 Gig DDR3 1333 MHZ SRAM sticks in place and failed when two more identical sticks (same vendor, same part number) were installed. I used 'memtester 6650M' (just leaves enough for OS) for 5 cycles with no errors.

Addendum to comment #21:

sudo apt list --installed | grep memtest

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

memtest86+/hirsute,now 5.01-3.1ubuntu4 amd64 [installed]
memtester/hirsute,now 4.5.0-1 amd64 [installed]

Addendum to comment #21:
The memtest86+ version 5.31b ISO image from http://www.memtest.org/ seems to work fine on this hardware. Source is there as well. Will they let Ubuntu use it?

I wasted a lot of time and angst on this issue. The 20.04 version works as long as I only test with 4GB installed, it hangs if there is more memory. Same memory works fine with PassMark's memtest86 v4.3.7 and with memtest86+ v5.31b. I haven't tried v5.01 directly downloaded from memtest86.org.

I can't help but wonder how may people think they've got bad memory because this tool is broken.

Also encountering this same issue on ubuntu 20.04.2 with HP zbook 17 G2. Memtest loaded through grub freezes. I thought this was because my hardware was faulty. I nearly returned it under warranty.

But downloading memtest86+ 5.01 from memtest.org and loading via syslinux worked fine, and memtest reached 100%. I thought it might be a GRUB issue but copying /boot/memtest86+.bin to my USB drive and loading via syslinux caused the same freeze. So the problem is with the ubuntu build of memtest86+.

Memtest86+ is supposed to "completely reliable", according to their website. A diagnostic tool is near useless if it gives false positives, and a freeze of memtest86+ would seem to indicate a severe memory failure. Including this build in ubuntu is doing a disservice to upstream and to users.

Here too, memtest86+ 5.01 version from Ubuntu would consistently freeze during test #2 (58% in). If test #2 was skipped, test #3 would trigger a reboot at some point. Those 2 problems only occurred when more than 4G was installed in the system.

Switching to the pre-compiled binary from https://www.memtest.org/ version 5.31b showed that there were no problem with the memory/board, the tests all completed successfully.

I have the same issue on Ubuntu 20.04 LTS. There is some issue with the memtest86 binary in Ubuntu. Here is how to fix it:

1. Get rid of Ubuntu version of memtest
   sudo apt remove memtest86+

2. Download the official memtest86 5.01 binary from here : https://www.memtest.org/download/5.01/memtest86+-5.01.bin.gz

3. Extract from the archive and copy memtest86+-5.01.bin to /boot
    sudo cp memtest86+-5.01.bin /boot/memtest86+.bin

4. Update grub
    sudo update-grub

Hi, I'm working on a new build for debian experimental with version 5.31b
for now multiboot patch is disabled and binaries should be near to upstream build

work done for now about memtest86+ package is here: https://salsa.debian.org/debian/memtest86plus/-/commits/debian/experimental

is someone want help to test it

Note for users: 5.31b is marked upstream as not ready for production, keep attention! even if for what I see for now is better that 5.01 that is unusable or not correctly working on major of recent systems

About multiboot I don't have knowledge about assembly and the boot part except a little something done years ago that I hardly remember anything about, I don't have enough time recently to read up and study the parts. Is there anyone with enough knowledge about it to help me get the correct multiboot part please?

Latest memtest86+ release is already packaged in Debian experimenal/unstable - see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977217
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989030

Please include latest release into Ubuntu 22.04 LTS. Should I report separate FFE bug about this?

there should be autosync bot that take from debian unstable until the features freeze, if it doesn't work I will report

another good news: about upstream the main developer replied me today and he is trying to do an upstream git that and will try to converge existing forks in memtest86+ 6.00 if the various developers will accept

Lionel Debroux <email address hidden> told at http://bugs.debian.org/943752
Date: Tue, 18 Jan 2022 23:08:44 +0100

https://github.com/anphsw/memtest86 is another memtest86+ fork which contains some interesting changes. Unlike both upstream and coreboot's fork:
* in dmi.c, it's not affected by https://bugs.debian.org/1003906 , and it contains updated DMI struct definitions;
* in spd.c, struct pci_smbus_controller smbcontrollers[] contains ~30 additional entries for Intel hardware;
* in main.c and test.c, it has new latency analysis and Rowhammer tests;
* etc.

In config.h and lib.c , both forks have support for 4 serial ports, up from 2.

On its side, the coreboot fork integrates multiboot changes, embeds a much newer and larger JEDEC ID list than both upstream and anphsw's fork, etc.

Lastly, unlike both forks, upstream 5.31b has DDR5 entries in dmi.c's static char *memory_types[], a number of typo fixes, the beginning of a user-space unit test program for memtest86+ (which could be used as a starting point for fuzzing the DMI, SPD, ACPI, etc. parsing functions).

It's a mess :)

PS: I used the following mechanical changes to clean up a bit the large diffs between memtest86+ 5.31b and the anphsw / coreboot forks:

perl -pi -e "s/v->/vv->/g" *
perl -pi -e "s/isdigit/mt86_isdigit/g" *
perl -pi -e "s/memcmp/mt86_memcmp/g" *
perl -pi -e "s/memmove/mt86_memmove/g" *
perl -pi -e "s/strncmp/mt86_strncmp/g" *
perl -pi -e "s/strstr/mt86_strstr/g" *
perl -pi -e "s/strlen/mt86_strlen/g" *
perl -pi -e "s/error\(/mt86_error(/g" *
perl -pi -e "s/print_mt86_error/print_error/g" *
+ 1 manual edition to test.h for renaming v to vv

Many whitespace changes still appear in those diffs, despite passing the -b or -w flags to `diff`.

I already know and as already told upstream developer already working contacting developers of these forks for collaborate and try to merge works of all upstream.
For now I'll wait progress of this instead wasting time applying, adapt (for 5.31b) and testing patches from forks now, I'll apply them only if there will be important issue that can't wait.
I have other projects/packages I contribute to, I only recently became a maintainer of memtest86+ after investing many hours in the last 2 months to update it, fix a lot of problems and make some other improvements.
If there are still important issues (with latest version, 5.31b+dfsg-4) let me know please, for now on all cases where old version was not working the latest is on my tests and the only thing not working is the multiboot (which is secondary and disabled by default) which I am not able to fix quickly (I have no knowledge about it) and so I left it like this (after adapting the old patch to at least fix the memory detection) to better invest the time in other parts and projects where I have more knowledge.
If anyone wants to contribute a patch that fixes it is welcome and I would apply immediately (after testing if it doesn't cause regressions) and I will do new build.

5.31b+dfsg-4 is now in Jammy, can be considered this "bug" as solved?

> 5.31b+dfsg-4 is now in Jammy, can be considered this "bug" as solved?

since it's still 'broken' in focal, i added a focal target, but changed the main bug to 'resolved'.

the focal target could be changed to 'wontfix' if you don't think you will fix it there, or you could SRU the entire newer version back to focal if you get a SRU exception:
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases

you could alternatively move the latest version back to the focal-backports pocket if you don't want to mess with SRUing it, but considering that the version in focal seems to be 100% broken, it would be better to just SRU the latest version, I think.

This fault also occurs for me with Ubuntu 20.04. I have 3 x 4G sticks. Any single stick in any slot and the Ubuntu-bundled memtest runs fine. More than one stick will result in the Ubuntu-bundled memtest freezing (at exactly the same point each time). The memory is good, as determined by Memtest86+ 5.31b booting from a CD.

If developers don't have time to fix it for 20.04, and I realise they are volunteers working in their spare time, then IMHO it would be better to remove it altogether. Otherwise, the faulty version causes people to waste a lot of time thinking they have bad memory, many of them never realising the memory is good and possibly throwing it away. I know it would have saved me a lot of time today if this faulty version hadn't been bundled with 20.04.

Ubuntu maintainers,
Thanks for your software and service to us all!
Please, Please, Please stop shipping Memtest86+ version 5.31b with Ubuntu.
From my experience, this software IS NOT threadsafe and will falsely report RAM errors when RAM is OK. I think this happens because, in mult-core (multithread) mode, i.e. use all CPU cores in parallel, the software allows simultaneous reads and writes to a RAM location which corrupts the RAM, causing indeterminate values to be read. These are of course, interpreted as RAM errors, even though the RAM is sound.

I verified this by running Memtest86+ version 5.31b in multicore mode (default that shipped with Xubuntu 22.04) on my E5-2690v4 and E5-2697v3 based servers with DDR4 RAM. The Xubuntu Memtest86+ showed several RAM errors after 30min to 5hrs of running. Memtest86+ running one CPU round-robin showed no errors. Also, Memtest86 version 10.0 (a different vendor than Memtest86+) showed no errors in multicore mode running for 24hrs on both machines.
To users: DO NOT trust Memtest86+ multi-core mode. Use single-core mode only OR better use Memtest86 version 10.0 (latest version) and run that in parallel, multicore mode.

Version 5.31b+dfsg-4~bpo20.04.1 from Focal's backport seems to work. Version 5.01-3.1ubuntu2.1 from main freezes right away. I wonder why keep a broken package in main.