Interesting issue running Memtest86 v7.0 Free with i7-6700K

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • keith
    replied
    Without a screenshot or log, it is hard to say what is causing the errors. It may be an intermittent error due to external factors or it could be a BIOS error.

    The time it takes to run the MemTest86 depends on several factors. On average, it may take about 1-1.5 hours to complete the first pass. See this page for details:
    http://memtest86.com/technical.htm#execution

    Leave a comment:


  • Rodsman
    replied
    So I built my first system last May and have had random bsod and the error code indicated it might be my ram. I bought the pro version of the test and ran it yesterday. It showed over 30000 errors which seemed crazy to me. Rerunning it today and it has shown no errors but it's been going for 8 hours? Clearly I'm new to all of this and have the same CPU in this thread. How long should all the tests take and any thoughts on the huge difference in results. Thanks. I know those of you that know way more than I do may want more info but I wanted to see about the timing issue before wasting anyone's time.

    Leave a comment:


  • zerophase
    replied
    Originally posted by keith
    zerophase, do you have the logs for your MemTest86 run? It seems likely to be a UEFI BIOS multiprocessor issue similar to the ones listed here:
    http://www.passmark.com/forum/memtes...election-modes

    If you can upload or e-mail a copy of the Memtest86.log file under the EFI\BOOT\ directory of the USB drive we can confirm if that's the case.
    My motherboard, Rampage V Extreme, isn't listed in that list.
    Here's the paste(It includes logs going back a couple versions): http://pastebin.com/r9DVexGD
    Last edited by zerophase; Aug-08-2016, 10:24 PM.

    Leave a comment:


  • Psychor
    replied
    I created a bootable USB of MemTest86 V7.1 Free Edition today. When I booted it via UEFI on a new 6900K machine I just built I had a similar issue - it just sits at "Testing multiprocessor support..." and doesn't budge. I didn't have the patience to wait 20 minutes like the above poster though. I checked the USB stick and there were no logs in any of the folders.

    UPDATE: I just took the same exact USB stick and put it in my 3930K system, booted with UEFI and had no issues. Wonder why it's having an issue with the newer processor.

    UPDATE2: I ran diskpart, cleaned the USB and then re-imaged MEMTEST86 with Rufus. I can now get passed the "Testing multiprocessor support..."
    Last edited by Psychor; Aug-08-2016, 10:07 PM.

    Leave a comment:


  • keith
    replied
    zerophase, do you have the logs for your MemTest86 run? It seems likely to be a UEFI BIOS multiprocessor issue similar to the ones listed here:
    http://www.passmark.com/forum/memtes...election-modes

    If you can upload or e-mail a copy of the Memtest86.log file under the EFI\BOOT\ directory of the USB drive we can confirm if that's the case.

    Leave a comment:


  • zerophase
    replied
    Happens on 5960x, as well. The issue continues with 7.1. Getting stuck at Testing multiproccesor support for at least a good five minutes before deciding to just restart. I even tried with compatibility support turned on for bios boot, and that didn't help either.

    Leave a comment:


  • David (PassMark)
    replied
    Can you also try the 7.0.1003.zip release Keith linked to above.

    In the V7.0 release of MemTest86 we changed the internal clock we are using to measure various things. As background: a modern PC has a variety of internal timers and clocks that can be used by software. Any misbehaviour by the clock can result in things happening at the wrong speed or measurements like the CPU clock speed being wrong. For a long long time MemTest86 used a timer in the Programmable Interval Timer (PIT) chip. Every PC made in the last 20+ years has one of these and they all had the same interface, until recently. A very small number of new PCs don't have a PIT. So in MemTest86 V7 we now use the High Precision Event Timer (HPET) by default, and the PIT if a HPET can't be found.

    Unfortunately on a few machines, the HPET was available didn't return values we expected, which we suspect caused some of the above issues. In the next patch release we are a bit more careful in using the HPET, plus we added fallback mechanism to use the legacy PIT to measure the clock speed if the measured CPU clock speed using HPET is unreasonable.

    Leave a comment:


  • tsulkoske
    replied
    Wanted to chime in because I'm having the same exact problem with the same exact processor. It would get stuck on test 10 and basically freeze during the countdown. Version 4.3.7 works fine though! Several passes in and no errors yet.

    Leave a comment:


  • WtheFourth
    replied
    Good news and bad - Memtest86 successfully completed 10 passes on both sticks of RAM individually, so that means the memory is alright! However... that means something else is likely the problem (welp), should the issue persist when I hook everything back up and try out Windows. I suppose I'll leave HWMonitor running to see if I have any outrageous dips or anything.

    Leave a comment:


  • WtheFourth
    replied
    I'm unable to boot to the UEFI version of Memtest linked above, but I am running v4.3.7 successfully as I type this. So, progress?

    http://imgur.com/b1xsXzZ

    Edit: turned off secure boot, successfully running UEFI version. Hopefully I can find some errors so I can figure this out!
    Last edited by WtheFourth; Jul-22-2016, 11:26 PM.

    Leave a comment:


  • WtheFourth
    replied
    Awesome, thanks. I bought and used the memory stick I'm using now to flash the BIOS on my motherboard on around 5/13/2016, but I will try both this one and a new one after I run to Best Buy this afternoon.

    The existing one is a Sandisk Cruzer Fit 16GB, and I have a Silicon Power J80 16GB (although it currently is a Windows 10 Install drive - I can probably overwrite it for now though). Any specific brand or anything you'd recommend?

    Leave a comment:


  • keith
    replied
    Thanks for the uploads.

    Can you give the following build a try:
    http://www.passmark.com/ftp/memtest86-usb-7.0.1003.zip

    Also, if you have another fast, reliable USB memory stick, can you try burning the MemTest86 image on that instead. We have seen cases where an older USB drive caused MemTest86 to slow down considerably due to the amount of time it takes to write entries into the log file.

    Leave a comment:


  • WtheFourth
    replied
    Log: http://pastebin.com/W9dDXLEm

    Video I recorded to show some of what is going on in Memtest: https://youtu.be/E76TfwBjbQo

    Here's an image showing CPU operation within Windows (the high of 53-56C was while running the stress test in the Intel Processer Diagnostic): http://i.imgur.com/uM2eSpp.png
    Last edited by WtheFourth; Jul-22-2016, 03:03 AM.

    Leave a comment:


  • WtheFourth
    replied
    Update: I've done everything above, up to and including resetting the CMOS battery - still got the same issue, leaning heavily on it being something with either the CPU socket or the CPU itself. It seems unlikely it'd be the CPU, and I typically suspect ASUS before ever suspecting Intel. I'm currently only running the CPU, CPU cooler, and a single stick of RAM. On first boot, CPU was at 27°C, still stuck on testing multiprocessor support. Radiator is showing that it was running at 1500 rpm, give or take, in BIOS menu. CPU fans are pumping air as expected. No USB devices aside from keyboard connected.

    So, motherboard?

    Sidenote: will grab logs using laptop ASAP.

    Leave a comment:


  • WtheFourth
    replied
    Originally posted by keith
    MemTest86 starts collecting logs automatically at the moment it boots up and is saved as MemTest86.log under the EFI\BOOT\ directory of the USB drive. Anyways, if you have it, it would be good to have a look and see if there is anything useful in there.
    Oh, awesome, I definitely still have the logs then and I will upload them this evening!

    Leave a comment:

Working...