MemTest86 v9.5 Beta 1: Millions of DMA Errors

[kwinz]

I tried the beta on an 6 year old board (i5-4460 on an ASUS Z97K with newest BIOS, with 4GB RAM) and got millions of errors.
All other Memtest86 test pass without errors, only the DMA test fails. Is this expected?




This is a crosspost from: https://twitter.com/MarkusKrainz/sta...74641995943939

[David (PassMark)]

It would seem unlikely that your RAM is that bad and only on one test.

More likely it is a bug or incompatibility with the hardware that we need to fix.

Would it be possible to Email us the debug log file
https://www.memtest86.com/tech_debug-logs.html
(this file should have automatically been created on your USB drive)

[kwinz]

Hi David! Thanks for your reply! I restarted for another memtest to collect the debug log file for you and in classic fashion the errors disappeared.

I started to puzzle together what might be happening:

1. According to your documentation for the DMA test you are doing is using the disk controller since that was the most portable way to do DMA access.
2. I am not booting memtest86 directly from a USB drive.
3. Instead I am booting from an IODDmini [1] [2].
4. The IODDmini is a popular USB drive that emulates a USB disk drive from ISO files. And simultaniously it can emulate one or more removeable or non-removable USB mass storage devices from VHD image files. My memtest86 installation was on an VHD image file and mounted write protected until I attempted to get the log for you.
5. Now that the test is running and not throwing constant errors any more I can see the IODDmini disk access LED flashing. That wasn't the case last time when it threw millions of errors.

So my thinking is maybe you need to guard against an empty USB drive being present, or an empty DVD drive being present and probably not giving you data on reads or a USB drive that is write protected being present.

I was booting vie EFI. The CSM was completely disabled.

Even though the test worked much better this time, and didn't throw a single error any more, memtest86 still crashed/froze 86% through the DMA test and the HDD access LED stopped blinking.


[1] http://iodd.kr/wordpress/product/iodd-mini/
[2] https://www.amazon.com/256-bit-Secur.../dp/B07Y4FR9H7

[kwinz]

I redid the test for a third time and again it was freezing/locking up at the same 86% - exactly at address 0x100000000. See attached screenshot.

[kwinz]

And a fourth run, again in the configuration without write protection and only the single drive that does not throw millions of errors. Except this time I interrupted the test before it reached 86% so it would write a debug log. I am sending you this log via PM David.K (Passmark) . Please treat confidential and only use for the purpose of fixing bugs.

This is as much time as I can justify on spending on reporting this bug / theese bugs. I hope this was helpful! Cheers

[David (PassMark)]

We have never heard of, or tested with, IODDmini.

But yes, the drive needs to be writable. (but we should detect this if it isn't, so this is something we need to check on)

It would have been good if you could repeat the test with a real physical USB drive and see if you get the errors / lockups.

If IODDmini is emulating a physical drive, then it probably won't be doing any real DMA. So the whole test it worthless in this case.

[kwinz]

> We have never heard of, or tested with, IODDmini

IODDmini is exactly for this kind of work: having Windows 10/11/Server installer disks, several Linux bootable distros and a memtest86 allways with you. 1 device instead of 10 USB drives. I figure I won't be your only customer who useses those. Maybe get one to test yourself, they are around 130 bucks + tax.

> If IODDmini is emulating a physical drive, then it probably won't be doing any real DMA.

I don't know how your code works. Isn't the DMA controller independent of that? I mean the emulation happens outside the PC, the PC just sees a USB mass storage device connected to the PC. There is no additional code or driver running on the tested computer. I don't see how this would affect the DMA controller. But I also don't know how the EFI presents USB drives to memtest exactly.

The PC I was testing on also had a 18TB HDD drive connected via SATA during the the whole test that AFAIK memtest86 didn't use at all. If it's important not to use a USB drive for the DMA test then improve the heuristic which device is suitable or let the user choose one.

I don't have time to do any additional tests with the Beta.

Any idea why the test froze reproducibly, exactly at address 0x100000000, even after I made the drive writeable?

[keith]

Any idea why the test froze reproducibly, exactly at address 0x100000000, even after I made the drive writeable?

We believe this is an unrelated UEFI bug that we've seen with older systems, when accessing addresses > 32-bits. You can confirm if this is the case by seeing if it fails similarly for the other tests.

Unfortunately, this requires a proper UEFI firmware fix from the vendor, which isn't very likely for an older system.
One workaround is to set an upper address limit of 0x100000000 which limits the amount of RAM tested, but will avoid crashing the system.

[kwinz]

if it fails similarly for the other tests.

Thanks for the reply! When I ran it with Test 14: DMA disabled, the other tests passed without a problem.