Multi-CPU Reboots

[Sherrick]

Hello!

I apologize if this has already been addressed, but after quite a while searching the forums, I was unable to locate another instance that specifically dealt with the issue I'm experiencing.

I recently built my first AMD-based system and thus far have been quite pleased with it.

I have an AMD FX-8350 CPU, 8GB of Crucial 1866 RAM (2X4GB) in an Asus M5A99X EVO R2 motherboard. This setup has been quite stable for just about a month now.

Prior to making some other changes in the system, I decided to test the RAM to ensure there were no problems. I downloaded what I believe are the latest versions of Memtest86, both the 4.3.5 build and the 5.0.0-pro beta build.

I booted the system from the ISO created CD and allowed the default multi-core testing to begin. Regardless of which version of Memtest86 I used, the system rebooted about 20 to 25 seconds into the initial test each time. After multiple attempts to get the test to run, I then selected the Single CPU test on the 5.0.0 Beta build and it ran without error.

Is this a known issue with Memtest86 and AMD CPUs or 8-Core CPUs? My concern is that there is an underlying hardware issue with my build and I am unaware of it. This system will soon be placed in a location where it will be difficult to access, so if there are hardware issues, I'd rather deal with them now than later.

Thank you very much for your assistance.
Sherrick

[David (PassMark)]

allowed the default multi-core testing to begin.

The default is actually single core testing. So you might be confused on this point.

In V5 there is a log file created, but only for a USB drive boot. Would it be possible to make a USB version of V5. There will be be a log file that has been generated in the 'EFI/BOOT' directory called MemTest86.log. Sending us, or posting, this will be of great help.

[Sherrick]

Hello David,

Thank you for the quick reply.

I think perhaps my wording created a bit of confusion or perhaps - as you've suggested - I may simply be confused.

When I said I allowed the default multi-core testing to begin, I meant that I didn't press any keys and allowed the program to auto-start. At that point, it said CPUs Found 8, CPUs Started 8, CPUs Active 1. I thought it meant that since 8 CPUs had been started that it was running in multi-core mode. Perhaps I am misunderstanding?

I did as you suggested and created a bootable USB drive and started the system from that device. The first time, I allowed Memtest86 to autorun and it again failed out after about 20 or 25 seconds. When I then booted into Windows and looked for the MemTest86.log file on the USB Drive, there was no such file under the EFI/BOOT directory or anywhere else.

At that point, I rebooted to the USB Drive again and this time I selected the #1 Default testing mode manually. Again, it said 8 CPUs Found, 8 CPUs Started, 1 CPU Active. With me manually selecting the #1 Default testing mode, Memtest86 ran a bit longer, perhaps as long as a minute or so. It reached about 45% or so into Test #4 and then rebooted. I again went to Windows and looked for the MemTest86.log file, but there was no such log file anywhere on the USB Drive.

Am I looking for this file in the wrong place? Is there something else I could try? Any additional assistance you could provide would be most appreciated.

Sherrick

[David (PassMark)]

If there is 1 CPU active, then this means only 1 thread is running.

If the reboot occurs at different points in the tests (i.e. somewhat at random) then there is the possibility that there is in fact a hardware problem.

I think the log file must exist. Maybe the machine booted from the CD, even though the USB drive was plugged in.

Might be worth trying the test with just 1 stick of RAM in the machine at a time.

[Sherrick]

Sorry for the delay. I responded previously but apparently my post failed to stick.

I know the system booted from the USB Stick, as I had previously removed the CD disc from the drive prior to booting from the USB. I also manually selected the USB Drive as my "Boot From" device at start-up. It's not possible that it booted from anywhere else.

I also did a search on both the USB Drive and each of my system drives in an effort to find the MemTest86.log file, but it does not exist. There are a number of files in the USB's EFI/Boot directory, but they all have exactly the same date and time stamp. Nothing new was written there, even after multiple attempts to run the test.

Sherrick

[otacon]

hi there im also having the same problem my build is fx8350, corsair vengeance 8gig ram 1600 and a gigabyte 990fxa ud3..the memtest86 4.3.5 would would always reboot after 20 to 30 seconds running. i took my pc to the shop and they ran a memtest86 4.2 which worked and was able find errors in the stick and was replaced. tried running memtest86 4.3.5 on the new stick and still rebooted every 20 to 30 sec. then tried memtest86+ 5.01 which worked was able to do 5 passes.i have no idea whats wrong memtest86 4.3.5 might be a compatabilty error with the cpu?

[David (PassMark)]

Unfortunately (for us) it looks like it is a real software bug. It was reproducible here on a AMD FX-8150.

The problem also does not occur in MemTest86 V5 beta on our machine (and I also suspect on your machines).

Sherrick,
To clarify your initial post, the problem has nothing to do with multi-threaded mode as the crash occurs when single threaded. The behaviour on V4 and V5 is not the same on our machine. There is no crash in MemTest85 V5 beta. I suspect the same applies to your machine despite your initial post saying the behaviour is the same.

What I think is happening is that you are in fact still running the V4 software and not V5 at all. This would explain why you think the V4/V5 behaviour is the same and why there is no V5 log file on the USB drive. For reference V4 has a blue background. V5 has a black background.

We'll have a look into why V4 is crashing on these CPUs and post the result here.

[Sherrick]

David, I think you are absolutely correct on the version that I am actually booting. I downloaded the version 5 Beta, but apparently I am not booting the UEFI version of the program. When it starts up, it shows version 4.3.5. I presumed, since it booted, that the version number was just something that had not been changed due to the Beta status of the program.

I am very new to the UEFI firmware, and I'm not as comfortable as I would like in making changes to boot order and boot functions. When I select the UEFI USB device from my Boot Order menu, it bypasses the USB altogether and boots on into Windows 7. If I select the USB device (non-UEFI) it runs MemTest86, but it runs the earlier 4.3.5 version. I'm a bit reluctant to go making a lot of changes in the UEFI without some guidance, as I do not yet know what all of the various options in the board's UEFI actually do and I do not want to end up in a non-bootable state.

Sherrick

[David (PassMark)]

On most UEFI motherboard you can press a key during the boot sequence to select a boot device (as a non permanent change). On the machines we have here it is F8 or F12. But I know on other machines it can also be F9, F11 or ESC.

On your ASUS board I think it is F8.

It brings a screen that looks something like this. In the screen shot below the UEFI: KingstonDT is the device we want, but the exact naming will depend on your motherboard and USB drive.

[Sherrick]

Yes, on mine it is indeed F8. At that point, I have 3 selections for the USB Device. If I select the first option, it does boot from the USB Drive, but takes me to the 4.3.5 version of the software. If I select either of the other two (both of which are listed as UEFI devices), the system looks at the USB device briefly and then boots on into Windows 7. I've gone into the UEFI interface and moved the USB Device boot priority around as well, but still end up in the same place. I think I have to make an adjustment elsewhere - perhaps in the Secure Boot functionality or the CSM setting - to get it to actually boot from the USB Device in UEFI mode. If someone knows for sure what I need to select, I'd be very grateful to hear that information.

OR, maybe I need to try a different USB Port, such as the port for the USB Bios Flashback function. I hadn't thought of that previously.

[David (PassMark)]

Yes, you'll need to turn off secure boot. You can turn it back on later if you want. In the medium term we are going to try and get V5 signed to allow proper secure boot (it isn't trivial to get this done however).

[keith]

We believe we may have a fix for the MemTest86 v4.3.5 crash. Can you try the following build:

http://www.passmark.com/ftp/memtest86-usb-4.3.6e.zip