Mac Mini 2018 i5 multi CPU hang on test 2

[tinus]

Thanks for continually providing this great software!

I have a new Mac Mini (2018 ) with i5 and 8Gb of memory. If I run Memtest86 v8 and use the default, it hangs at the start of test 2. If I use either of the following limitations:

* Start memory address at 0x100000000
* Use only CPU0
* Round Robin CPUs
* Sequential CPUs

the test completes successfully.

The log is attached but I had to split it in two due to size limitations. The log is of a session that starts with the tests that I found to work and then at the end the defaults which crash.

[keith]

It appears that some Mac systems may require a workaround to skip the first few pages in memory, even though they are marked as Free memory.

Can you try adding the following line to blacklist.cfg found under EFI\BOOT\ of the USB flash drive.

"Mac-7BA5B2DFE22DDD8C",ALL,EXACT,RESTRICT_ADDR

[dduncs]

Hi tinus , I am attempting to run MemTest86 on my Mac Mini 2018 i7 and I'm having some issues. I created the boot USB and I tried booting from it, but I can't get past the Apple logo boot screen after I've booted from the MemTest86 USB. Maybe I'm missing a step somewhere.

Would you mind explaining to me how you were able to run MemTest86 on your Mac Mini 2018?

Thanks!

[David (PassMark)]

dduncs, Can you post the debug log.

[dduncs]

Hi David (PassMark) here is an rtf file copied and pasted from my debug log. I hope this is what you need. Thank you!

[keith]

Can you check if a MemTest86.log file was created under the EFI\BOOT\ directory of the USB flash drive.

[dduncs]

Hi keith I looked in the directory and saw no such file! I saw your reply in my other post and I am going to try changing some Startup Utility Settings.

[dduncs]

Hi keith , so I was able to get my Mac Mini to boot from the USB drive by adjusting the Startup Security Utility settings. It seems now that I am having the same issue as tinus where there is a hang on Test 2. I added the line of code that you mentioned in an earlier post to the blacklist.cfg file and tried running the test again, but I had the same results...

I am attaching the MemTest86.log file for you to take a look right here. Thanks again for all your help!

[keith]

Thanks for that.

Can you try the following:

1. Go to 'Address Range' in the Main Menu
2. Set the lower address limit to 0x1000
3. Start the test

If it still fails, try increasing the lower address limit until the problem disappears.

[dduncs]

Hi keith , it worked! I changed the lower address limit to 0x100000 and I was able to run a full 4 pass test! My RAM passed Thanks again for all of your help.

Happy New Year!!

[keith]

Great news.

By the way, if you set the lower address limit to 0x1000 or 0x10000, does the program still hang?

[dduncs]

Hi keith yes, I tried both 0x1000 and 0x10000, but both got hung up on Test 2. 0x100000 was the only setting that worked for me.

[keith]

Hi keith yes, I tried both 0x1000 and 0x10000, but both got hung up on Test 2. 0x100000 was the only setting that worked for me.

Thanks for that. We'll apply this workaround fix in our next public release.

[ciclopez]

Hi keith I'm also using a Mac mini 2018 (i7) and I'm also having this problem with the latest public release. According to the release notes:

• Added Mac Mini 2018 to blacklist which sets the lower address limit to 0x1000 by default

it looks like the fix has been applied from 0x1000 instead of the lower limit of 0x100000 that dduncs pointed out.

Anyway, I've been making some range tests, and found that the exact lower limit that works is 0x3F000 and above, if I use 0x3E000 or below, it hangs on test 2.

Another thing that I found is that ranges with the lower limit starting below 0x3F000 must be shorter than 0x60000 or it also hangs. For example, a range from 0x12000 to 0x72000 works, but a range from 0x12000 to 0x73000 hangs. This means that it's possible to test all the RAM without hangs by doing two tests: one from 0x0 to 0x3F000 and another one from 0x3F000 to <end>. Is this a normal behavior?

To arrive to this conclusions I made these tests:
0x00000 - 0x60000 · OK
0x00000 - 0x61000 · HANGS
0x3F000 - < end > · OK
0x3E000 - < end > · HANGS
0x3E000 - 0x61000 · OK
0x3E000 - 0x100000 · HANGS
0x3E000 - 0x9E000 · OK
0x3E000 - 0x9F000 · HANGS
0x12000 - 0x72000 · OK
0x12000 - 0x73000 · HANGS

Thank you.

[keith]

Hi keith I'm also using a Mac mini 2018 (i7) and I'm also having this problem with the latest public release. According to the release notes:

• Added Mac Mini 2018 to blacklist which sets the lower address limit to 0x1000 by default

it looks like the fix has been applied from 0x1000 instead of the lower limit of 0x100000 that dduncs pointed out.

Anyway, I've been making some range tests, and found that the exact lower limit that works is 0x3F000 and above, if I use 0x3E000 or below, it hangs on test 2.

Another thing that I found is that ranges with the lower limit starting below 0x3F000 must be shorter than 0x60000 or it also hangs. For example, a range from 0x12000 to 0x72000 works, but a range from 0x12000 to 0x73000 hangs. This means that it's possible to test all the RAM without hangs by doing two tests: one from 0x0 to 0x3F000 and another one from 0x3F000 to <end>. Is this a normal behavior?

To arrive to this conclusions I made these tests:
0x00000 - 0x60000 · OK
0x00000 - 0x61000 · HANGS
0x3F000 - < end > · OK
0x3E000 - < end > · HANGS
0x3E000 - 0x61000 · OK
0x3E000 - 0x100000 · HANGS
0x3E000 - 0x9E000 · OK
0x3E000 - 0x9F000 · HANGS
0x12000 - 0x72000 · OK
0x12000 - 0x73000 · HANGS

Thank you.

Thanks for sharing your experimentation results.

Do you know if the results you obtained are 100% reproducible? There's a chance that we are lucky and the memory we touched did not interfere with UEFI firmware/drivers in a fatal manner.

So you may get positive results for a run that may fail at a later time (and vice versa)