I can confirm what ferjim above me writes:
- Intel i5-3450 at default frequency;
- Intel DH77EB;
- 2 sticks of Kingston HyperX Blu KHX1600C9AD3B1K2/4G (2 x 4GB memory), tested at DDR3-1333 and DDR3-1600 (no difference)
Only connected a USB keyboard and monitor via DVI. Memtest86+ beta-1 hangs in test#2 at a random time. Memtest 4.20 runs OK (well, tried it for 5 minutes).
Edit: memtest 4.20 runs OK for more than 24 hours (no errors); Memtest 5b1 in failsafe mode runs OK - at least for 5 minutes.
Dernière modification par vanaalten ; 02/07/2012 à 22h26.
Motif: added information
Asus Sabertooth x79 (Bios 1104), I7-3930K C2, 8x8GB DDR3-1600
System auto reboot after finish Test #6 (12core detect/active)
will run normally if I disable hyper-threading in bios, or using F3 (6core detect/active)
I have the same board and can confirm that I see this as well.
I just bought a new Dell Optiplex 9010 and a kit of Crucial Ballistix 2x8GB DDR3 1600 CL9 RAM. I've had a couple hard lock-ups, so I grabbed memtest. The 4.20 release of memtest86+ turned up several errors around the 250ish MB mark (I don't remember exactly where), but I thought it could have been because Ivy Bridge wasn't properly supported, and it was conflicting with the region of video ram. Of course then I found this 5.00b1 version, but am getting what appears to be the same error, in test 3, at failing addresses 0000f5d6138, ...13c, ...140, ...144, ...148, ...14c, ...150, ...154, ...158, ...15c (and 18 more before that that are off screen).
See screenshot here:
I'm now not sure if this is a 5.00b1 bug, or if I legitimately have bad RAM, or something else entirely. This first pass is just finishing up, so I wanted to post now while I had a couple minutes to kill, but I'll yank out the first stick of RAM and re-test ... then if that's clean, I'll put the first stick in the second slot and see if errors pop up at 8 GB + 245 MB the next time around.
Edit: It moved onto the second pass as I finished writing this, and is past test #3 (where the failures occurred the first time around) and didn't report any additional errors, for whatever that's worth.
---------- Post added at 20h12 ---------- Previous post was at 19h53 ----------
Ok, that was pretty fast. I pulled the stick from slot 1, moved the stick from slot 2 into slot 1, put everything back together, and get a very similar (but not quite identical) set of errors, this time at 245.6 MB.
Screenshots from very beginning of test with only one DIMM, and the errors:
I'll still test with just the other stick, but this is looking to my untrained eye like either a Memtest86+ 5.00b1 bug or a bug in some other hardware (or BIOS).
---------- Post added at 20h32 ---------- Previous post was at 20h12 ----------
This DIMM didn't fail until test *4* this time (whereas the previous tests of both DIMMs and just the other DIMM), but again failed at 245.5 MB:
Any thoughts on whether this is a Memtest86+ 5.00b1 bug, something in my hardware, something fixable in my BIOS, and/or how to figure that out?
Ummmm ... is it possible the error is triggered by having Ethernet plugged in? Could that conceivably make sense?
I've had about three clean Memtest86+ runs with Ethernet unplugged (i.e. all that I've tried so far), and every other test with errors had Ethernet plugged in. I just sequentially and back-to-back did a test with Ethernet unplugged (fine), Ethernet plugged in (errors), and again with Ethernet unplugged (fine).
Edit: I just plugged Ethernet back in, ran Memtest86+ again, and got errors at 245.1 MB again. This seems completely repeatable at this point. Do you want me to run any other tests, or should I just ask for a replacement [motherboard] from Dell?
Dernière modification par omegadrh ; 07/07/2012 à 08h06.
Working on initial test of a new build. Currently: Gigabyte x79-ud3 mobo, 3930k cpu, 2x4gb Crucial Vengeance 9-9-9-24 RAM. I've OC'd from 3.2 to 4.0 GHz. (Yes, the RAM is only 2 channel and should be quad. Builder goofed )
Anomalies found... some of these I'm not sure if my problem or a bug...
1) Memory speed varies based on F1/F2/F3 vs older version. 4.2= 17.4 GB/s; 5.0b f1 or f2= 15.68 GB/s; 5.0b F3 = 13.6 GB/s; 5.0b -- = 12.0 GB/s -- that last one concerns me a bit. Does it make sense to get worse performance with 12 threads than with 6? And with six rather than one?
2) Running in F3 mode I got the (looks fake) two bad memory spots at 1a6f0 and 1a6f8
3) Can't see SPD data, SMBus controller not known
4) I'm OC'd to 4000 MHz and the BIOS shows that in several ways, but I see 3.20 GHz in 5.00beta [Could this be my problem? Or could MemTest86+ somehow keep the CPU at its default speed???]
5) Not sure if this should be a report or not... I initially ran 24 hours in normal mode. Accumulated a lot of errors in a "normal" part of RAM. I *tightened* the RAM timing from the XPD listed 9-9-11-24 to the labeled/spec'd 9-9-9-24. Have had no "real" errors since then, but not yet run a repeat 24 hour test.
This does look like it will be a nice release! I love the CPU temp displaying
Update. Now running 8Gx4 (Corsair Vengeance 10-10-10-27 RAM).
Envoyé par MrPeteH
2) Running in F3 mode I got the (looks fake) two bad memory spots at 1a6f0 and 1a6f8
After running overnight it is clear the RAM itself tests out reasonably good. But still getting "random" multibit errors in the low region.
SO... I set the upper range to 1m (BUG: this ONLY works just after startup. If I do it later, any change causes a reboot)...
... and let it fly. Instant zillion errors. The entire range of errors is 1a4f0 to 3cf68 on my system. Errors are on 8 byte spacing. Always multiple "random" bits. I'll attach a few screen shots. As others have noted, test # reporting is wrong. Error in test 7 shows up in 5, and similar issues on some others (rarely, I see errors reported as 6 and 8 as well in this region)
BTW, a Question: is there any way to scroll through the error list? Neither arrows nor page up/down work.
A further update. Having set the **lower** limit to 1m (18 passes immediately after startup), it has now run almost 21 hours on 32GB of RAM with no errors (18 passes in 21 hours... even with 12 active cores/threads this takes a while ).
By the way, another bug report. Look at the first screen shot in my message #74. The error counts are not being handled correctly.
* Notice that the total count (line 10 of the screen, right side) is much larger than the sum of counts below.
* In action, I observe that as the counts grow, the per-type count goes up then gets "stuck" for a while (usually at 32768 IIRC), then resets and counts up again.
* Sometimes the total count also gets stuck as well
* The total count during the normal scrolling display never gets stuck
Given that this < 1 MByte and other issues are "well known" (as no doubt are others) do you have plans to release any further beta's for testing soon?
Seems little point in re-testing Beta 1 when there are fixes for know issues which need to be tested. We can get on with verifying those fixes on a wide range of platforms while you are updating the code for other issues! :-)
- On every second or third pass, test #7 (Block Move) reports 2 errors in low region, sometimes at 13cf0 + 13cf8, sometimes at 274f0 + 274f8. I believe this is already reported here and a confirmed bug in the software. But beware, it is not test #5, as reported in error log, it is test #7 (Block Move). Just wanted to mention this to make sure you look into the right test to fix the bug. Strangely, errors are reported with a different test number (-2), so test 7 errors are reported as test 5 errors.
- When I add 2 more DIMMs of the exact same type (to a total of 4 DIMMs/16Gig), test #7 (Block Move) gives tens of thousands of errors over the whole memory range, from 0 to 16Gig. Usually in the lower and higher region of each single 2Gig test segment, seems like there is 1 bit missing, always the same bit. Can anybody confirm if this is a bug in the software or could this be serious RAM / MoBo / CPU error? Retesting with Memtest86+ 4.20 gives errors during "block move" too, but it seems it is a different bit reported there. I don't think that the RAM is faulty because every pair of dual channel runs fine if tested seperately (8Gig). Only if they stick in together (16Gig) there is a problem. I've devcided to run this machine now with 8Gig only until I know for sure that 16Gig is working fine. If there is any hint that this is a software bug, please let me know.
- Oh, there is one more thing. The access speeds shown in the upper left corner seem to be incomplete. While L1/L2/L3 cache throughput (MB/s) is reported correctly, the memory throughput is left blank (Memory: MB/s). This seems to be happening with AMD FX, since I've seen this in a screenshot of another beta tester who has the same CPU (AMD FX-8150).
Thank you, it's a great piece of software! Keep up the great work.
Dernière modification par chuck noland ; 27/07/2012 à 11h31.
I've tested 5.00b1 today on another machine with NVidia chipset...
Motherboard: ASUS M2N-E
Memory: Kingston HyperX KHX6400D2LLK2/4G (2x2GB Dual Channel)
CPU: AMD Phenom II X4 945 C3 (4 Core)
Mem Speed: CL4-4-4-12-2T@1.95V (Kingston tested timings)
- Did only run two passes (no errors reported), but known errors in test #7 (block move) would probably happen here too if trying more passes.
- DIMM detail information are not shown in the lower portion of the screen. When going into config and pressing 7 (SPD Info), it reports "SMBus Controller not known".
- Strangely, I have to press "c" twice to get into config. At first touch of the button, only a black window is shown where the config menu would be. After second press of the button, the menu appears.
- Same here as with AMD FX-8150 as reported in my last post: The access speeds shown in the upper left corner seem to be incomplete. While L1/L2/L3 cache throughput (MB/s) is reported correctly, the memory throughput is left blank (Memory: MB/s).
- I can confirm further reports of other beta testers, that a complete set of tests is running slower with every pass. The second pass feels like it takes twice as long as the first pass of tests.
Again, thanks for this masterpiece. Will look forward to beta 2. ;-)
- Now come down to test the memory of his hands on one plate,
found one module buggy , gave out a couple of mistakes immediately
or within three hours of testing at a frequency of @1333
sent to guarantee a week ago ...
Now dotestiroval remaining three module: - one and the same error
voltage for the test :
Error #1 module :
Error #2 module :
Error #3 module :
# 4-th module is already in the guarantee week ago
this two months 4x4 = 16 were tested on the dispersal of not more than @ 2400 = 1.65v, it is normal for voltage SEC.
Question - did these errors even in nominal terms,
but this is normal or not? or all of the 4-D module was faulty?
or for some reason 2 months broken?? or can be MemTest 5 / beta / wrong?
What more needs to be done? All of them take under warranty? or a certain percentage of error allowed?
- I can not believe that the whole lot wrong ... may be something else wrong? Win7x64, LinX, playing works fine and well at least a week without having to reboot 24/7 (have not tried longer) to @ 2133 or @ 2400
and even there are no errors in the windows, and the blue screen does not show ...
Dernière modification par 47920 ; 31/07/2012 à 06h40.
I've tested the 5.0b1 on my custom-designed 2nd Gen Core i7 embedded board.
It's HW config:
-Core i7-2715QE @ 2.1GHz BGA1023,
-2 x 4096MB soldered Micron DDR3-1333 w/ECC (9-9-9-24) running at 1600MHz 11-11-11-28,
-BIOS based on AMI codes but significantly modified according to platform needs + improved visuals.
The result is attached, the sytem passed two rounds at default settings without errors. It's just a brief testing, I'll examine it more carefully later.
Doc TB, thanks you for your great work, ver. 5.0b1 is REALLY different from 4.20 and I know how much time it takes.
I have only one thing to know - the lowest string on the screen is Motherboard name, I guess, but, unfortunately, it shows rubbish in my case. Could you please tell where are you reading that ID from? We could modify the respective string in the BIOS code then and the tool could correctly detect our board after that.
Guess I'm an accidental beta tester, as I needed something to test 16GB of RAM on my HP Envy 17 (Ivy Bridge chipset).
I'm testing two 8GB Corsair Vengeance SODIMMS (10-10-10-27) and ran into a one-bit error at about 2 hours into the testing, and the same error again four hours later. Was on the second of the two DIMMs as it was in the 10GB slice of RAM that the errors occurred. As this ties in to the RAM possibly being bad, I sent it back to NewEgg.com for refund and ordered two SODIMMs of the same type, though not packed together in a kit. Same SODIMMs however.
It's an HP-produced board with the HM76 chipset. CPU is a Core i7-3720QM running at 2.6GHz.
I am testing 5.00b1 on a Supermicro X9SCM-F motherboard with 32GB of RAM and an E31275 3.4GHz CPU. I have attached a screenshot and will leave it running overnight. I will confirm the result in the morning.
I have noticed that the ECC mode option has disappeared from the configuration menu in 5.00. Was this intended? Does memtest 5.00 detect single bit ECC errors by default or not?