This is prompting me to check my two machines. It's been a couple of years since the last memtest86 run.
Issues running SpinRite 6.1 Rel 2 on Zimaboard
- Thread starter the_physio
- Start date
- Watchers 10
-
DNS Benchmark v2 Release 5 with Consultant License Guest:
If you own any earlier release of our DNS Benchmark you may immediately download its release #5 replacement. Running an earlier release will detect the new release and help you upgrade.
Although this release is cosmetic, appearance matters and affects ease of use. The biggest change, as seen in the image above, is that the DNS Benchmark now has a traditional Windows application menu to more fully expose its many features. This release is also "Consultant License Aware" and GRC will now issue a Consultant version when owners have previously purchased four "Personal Use" licenses. If you have previously purchased four DNSB licenses, or if you wish to upgrade your "Personal Use" license to Consultant, GRC's purchase process will direct you through that process.
/Steve. -
Be sure to checkout “Tips & Tricks” Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!
/Steve. -
BootAble – FreeDOS boot testing freeware
To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.
GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.
The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.
You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.
(You may permanently close this reminder with the 'X' in the upper right.)
I have not seen a problem recently, but when a Windows machine fails multiple times with different error codes, Memtest is always my first thought. Thinking back, it was probably DDR2 and earlier RAM that was most susceptible to these problems.
HI Team, I awoke to a large "FAIL" on the monitor - see attached screen shots. I've also attached the LOG file (renamed to a TXT file) but happy to upload the HTML if that's better. I'll review again when I get home from work & please feel free to suggest any checks or changes to the tests - it does recommend running one in Parallel Mode so I'll probably do that at least.
Happy to not return the Zimaboard if it's of use to the project - like you said no hurry.
I'll look forward to kicking off a Parallel Mode test tonight - unless for any reason it's recommended not to.
Happy to not return the Zimaboard if it's of use to the project - like you said no hurry.
I'll look forward to kicking off a Parallel Mode test tonight - unless for any reason it's recommended not to.
Attachments
IMO, there's no need to. The RAM has problems.
You could do it just to see how bad it is.
In the ZimaBoard BIOS is there a way to change the RAM settings? Maybe lower the speed or bump the voltage up a .01v? If so you *may* squeeze a pass out of it as @ColbyBouma did.
Ran Memtest on my new to me computer for 2 days, got to around pass 13 with no errors. I actually had a free bad stick of DDR memory years ago, with a single stuck bit. Experimented passing a custom kernel parameter to exclude that 4k block of memory, and the system was perfectly fine with it. That memory was from a computer in a house that got struck by lightning, which fried the motherboard, power supply and DSL modem. Not the Intel Pentium CPU, those were hardy beasts, I tried killing one with an electric fence energiser, and after 50 jolts of 8J of energy, it was still perfectly good. Still a 200MHz part, but still fine. Finally killed it using a set of jumper cables and a car battery to pass around 100A through the substrate, burning off half the pins.
Nice!! I wanted to be sure that you saw my earlier posting, here:
https://forums.grc.com/threads/issues-running-spinrite-6-1-rel-2-on-zimaboard.1536/post-11562
I'll be working on adding built-in RAM integrity testing to SpinRite once I get the image downloading sub-system finished. THANKS!
Perhaps given this happened with a Zimaboard which has memory soldered in, you could include a mention of the $64 ZimaBlade in your sitewide announcement of the ZimaBoard, one of which I just received, that you can plug memory into separately. The cheaper price so far for me doesn't diminish performance but I understand you'll need to test it for yourself beforehand. There are discount coupons for March: $10 off with code "starbird10" or 15% off with code "HOMER15" that brings the price of the ZimaBlade down to $55.
The main difference is only one USB port and one ethernet port, one less of each than the ZimaBoard, also the ZimaBlade is powered by a separate USB type C port which if you don't have at least a 3amp 12 volt supply for, will need to be purchased separately. Also if you don't already have spare RAM to plug in then buying RAM is an additional purchase.
Last edited:
Hmmm, still waiting for mine. The expected shipping date jumped from Jan. 31 to Mar. 29
I'll just note that it's not really a $64 ZimaBlade since that purchases a RAM-less board. Add the $40 16GB of RAM and we're up to $104. Still less expensive than the $119 ZimaBoard and yes, certainly, plugable RAM (though I would argue that the reduced reliability of an additional connector might offset the benefit of exchangeable RAM.
I DO like the fact that it appears to have power and reset headers included. I've had to add those to my ZimaBoards. And having an outboard means for resetting and power-controlling my ZimaBoards have been a "must have". So I, too, have one on order to see for myself.
I DO like the fact that it appears to have power and reset headers included. I've had to add those to my ZimaBoards. And having an outboard means for resetting and power-controlling my ZimaBoards have been a "must have". So I, too, have one on order to see for myself.
Wow! That's quite something! I'm glad you ran this again.
I've just finished implementing the non-Windows (Linux) support for directly downloading bootable images. So my next project that I'll be working on now is adding RAM testing to SpinRite so it will hopefully be able to catch this sort of problem before it begins.
So... please stay tuned!
I've just finished implementing the non-Windows (Linux) support for directly downloading bootable images. So my next project that I'll be working on now is adding RAM testing to SpinRite so it will hopefully be able to catch this sort of problem before it begins.
So... please stay tuned!
@the_physio:
I've added an upfront RAM test to SpinRite and it would be EXTREMELY valuable to see whether it is able to detect that something is amiss with your ZimaBoard: https://www.grc.com/dev/SpinRite/SR61-RT0.EXE. This is an unlicensed directly downloadable release of SpinRite v6.1 which cannot actually do anything with drives since that code had been removed... but this makes is easier to obtain and test.
Note that it would be great to know not only whether or not the testing detects any problem with your ZimaBoard, but also, if it does, how quickly it does. (And if it does, could you try running it a few times to see how quickly, since that might vary.) Thanks very much!
I've added an upfront RAM test to SpinRite and it would be EXTREMELY valuable to see whether it is able to detect that something is amiss with your ZimaBoard: https://www.grc.com/dev/SpinRite/SR61-RT0.EXE. This is an unlicensed directly downloadable release of SpinRite v6.1 which cannot actually do anything with drives since that code had been removed... but this makes is easier to obtain and test.
Note that it would be great to know not only whether or not the testing detects any problem with your ZimaBoard, but also, if it does, how quickly it does. (And if it does, could you try running it a few times to see how quickly, since that might vary.) Thanks very much!
I downloaded the above RAM test version & then on the bootable USB, renamed SPINRITE.EXE to SR61R2.EXE, copied the SR61-RT0.EXE onto it & renamed it SPINRITE.EXE. The AUTOEXEC.BAT has SPINRITE.EXE as the last line so kicks it off immediately.
I’ve run the RAM Test SpinRite 3 times without any apparent errors.
Test #1 was for about 3 hours with about 201,000 patterns tested.
Test #2 was for about 1 hour & I did use the command “SPINRITE.EXE /DIAGS” with about 92,000 patterns tested without any apparent errors. But I couldn’t see any log produced by the RAM Test SpinRite.
Interestingly when I ended Test #2 I noticed that SpinRite stated there was a BIOS it couldn’t access – I’m guessing this was due to the BIOS Boot Option Filter being set to “UEFI & Legacy” as this matter disappeared when I set it to “Legacy Only” & ran the test a third time.
Test #3 is now still running.
I've got some screen shots of some of the above if they help.
Any suggestions or questions?
I’ve run the RAM Test SpinRite 3 times without any apparent errors.
Test #1 was for about 3 hours with about 201,000 patterns tested.
Test #2 was for about 1 hour & I did use the command “SPINRITE.EXE /DIAGS” with about 92,000 patterns tested without any apparent errors. But I couldn’t see any log produced by the RAM Test SpinRite.
Interestingly when I ended Test #2 I noticed that SpinRite stated there was a BIOS it couldn’t access – I’m guessing this was due to the BIOS Boot Option Filter being set to “UEFI & Legacy” as this matter disappeared when I set it to “Legacy Only” & ran the test a third time.
Test #3 is now still running.
I've got some screen shots of some of the above if they help.
Any suggestions or questions?
I'm disappointed but I'm not surprised. One of the things I noted from your tests with MemTest86 was that the region where those two bits were being found uncertain were higher in memory than the region SpinRite uses. But, at the same time, the nature of those bit uncertainties, always being the same two bits widely scattered, doesn't feel like specific problems with RAM locations, but rather a problem with the "bit lines" of the memory. And of those 101 errors in your second test run, only one appeared down in the first 50 megabyte region that SpinRite uses.
It's also interesting that one time you ran MemTest86 you got 1 error on the 1st pass, 5 errors on the 2nd pass, and then no errors on the 3rd or 4th passes. Then, when you ran it again, you got a total of 101 errors.
But of course, what we care about is that SpinRite's operation appears to be affected by something about your ZimaBoard, and when you ran MemTest86 on it, it produced errors.
I'm going to spend some more time with the RAM testing to see whether I might be able to do something more. I'll be back in touch!
It's also interesting that one time you ran MemTest86 you got 1 error on the 1st pass, 5 errors on the 2nd pass, and then no errors on the 3rd or 4th passes. Then, when you ran it again, you got a total of 101 errors.
But of course, what we care about is that SpinRite's operation appears to be affected by something about your ZimaBoard, and when you ran MemTest86 on it, it produced errors.
I'm going to spend some more time with the RAM testing to see whether I might be able to do something more. I'll be back in touch!
Okay, I've left the RAM Test SpinRite running overnight - still no apparent errors after 913,592 patterns testing. Let me know if you want: (a) this test to stay running; (b) keep starting additional tests if there are no errors after an hour or so; (c) run MemTest86 again; (d) try SpinRite 6.1 Rel 2 again; or (e) turn Zimaboard off & await further instructions.
Attachments
@the_physio:
Thanks for your continued testing! I have another test release for you to try: https://www.grc.com/dev/SpinRite/SR61-RT1.EXE. Note that it's "RT1" instead of "RT0". (You setup everything correctly last time... Though you could also just place the SR61-RT1.EXE on the boot drive then exit SpinRite to the DOS prompt after it starts, then manually start SR61-RT1 by entering its name on the command line. My point being... there's no need to rename things, if that might be easier for you, since you can run whatever you choose from the DOS prompt after exiting SpinRite.)
This RT1 test takes a different approach. The first one was filling all of the various SpinRite buffers with the same repeating 32-bit pseudo-random pattern of data. But if the trouble is with those two data bit lines not moving up or down quickly enough, it might be that successive reads and write need to have different data. So this -RT1 test starts with a random 32-bits, but rotates it every time. This has the effect of causing different data to be written and read from successive transfers.
Anyway... Let's see how this one does? If it doesn't produce an error in an hour then it doesn't appear to be any more able to generate trouble for your ZimaBoard than the first one.
And at that point, yes, it might be useful to have you re-run MemTest86 just to verify that it's still able to make your ZimaBoard misbehave.
Thanks VERY much!!
Thanks for your continued testing! I have another test release for you to try: https://www.grc.com/dev/SpinRite/SR61-RT1.EXE. Note that it's "RT1" instead of "RT0". (You setup everything correctly last time... Though you could also just place the SR61-RT1.EXE on the boot drive then exit SpinRite to the DOS prompt after it starts, then manually start SR61-RT1 by entering its name on the command line. My point being... there's no need to rename things, if that might be easier for you, since you can run whatever you choose from the DOS prompt after exiting SpinRite.)
This RT1 test takes a different approach. The first one was filling all of the various SpinRite buffers with the same repeating 32-bit pseudo-random pattern of data. But if the trouble is with those two data bit lines not moving up or down quickly enough, it might be that successive reads and write need to have different data. So this -RT1 test starts with a random 32-bits, but rotates it every time. This has the effect of causing different data to be written and read from successive transfers.
Anyway... Let's see how this one does? If it doesn't produce an error in an hour then it doesn't appear to be any more able to generate trouble for your ZimaBoard than the first one.
And at that point, yes, it might be useful to have you re-run MemTest86 just to verify that it's still able to make your ZimaBoard misbehave.
Thanks VERY much!!
Ran SR61-RT1.EXE & all looked good for the first 15 minutes so I set an alarm & came back after it had been running for an hour or so to find this warning (see attachment RAMTest-RT1-a.jpg).
Used ESC to return to DOS & ran it a second time. Interestingly after an hour or so it was running error free (see attachment RAMTest-RT1-b.jpg) – actually it still is after nearly 1.5 hours. I’ll see how long it takes for an error on this second run. It can run just off to the side of my TV while I watch the Australian F1 GP.
Used ESC to return to DOS & ran it a second time. Interestingly after an hour or so it was running error free (see attachment RAMTest-RT1-b.jpg) – actually it still is after nearly 1.5 hours. I’ll see how long it takes for an error on this second run. It can run just off to the side of my TV while I watch the Australian F1 GP.
Attachments
It's great that the second version found the trouble... and it seems like it's about as sensitive as MemTest86, since it also never found any problems during the 3rd and 4th passes the first time you ran it.
But... it doesn't look like we'll be able to count on a =brief= RAM test, which is run at the start of SpinRite, to detect this sort of very marginal RAM.
THANK YOU for the testing. I'll be interested in any further experiences you have with this. And I may have more thoughts later!
But... it doesn't look like we'll be able to count on a =brief= RAM test, which is run at the start of SpinRite, to detect this sort of very marginal RAM.
THANK YOU for the testing. I'll be interested in any further experiences you have with this. And I may have more thoughts later!
Have continued testing the SP61-RT1.EXE with the following (confusing?) results:
2 hours 30 minutes – 2nd error occurred
0 hours 1 minute – 3rd error occurred
0 hours 0 minutes 10 seconds for 4th error
0 hours 0 minutes 14 seconds for 5th error
Immediate production of 6th error
0 hours 0 minutes 10 seconds for 7th error
0 hours 4 minutes for 8th error
0 hours 3 minutes for 9th error
Have taken screen shots of the errors if these are required.
I think I'll run the MemRest86 again overnight.
2 hours 30 minutes – 2nd error occurred
0 hours 1 minute – 3rd error occurred
0 hours 0 minutes 10 seconds for 4th error
0 hours 0 minutes 14 seconds for 5th error
Immediate production of 6th error
0 hours 0 minutes 10 seconds for 7th error
0 hours 4 minutes for 8th error
0 hours 3 minutes for 9th error
Have taken screen shots of the errors if these are required.
I think I'll run the MemRest86 again overnight.
I would say that your particular board has a memory chip that is on the edge of passing, which passed the factory test and speed grading, but which was actually marginal, likely with it having, due to ineviatable process variations, a delay in responding that is on the edge of being faulty, so the random fails in memory bits. Probably best to return the board, or try to underclock it, setting the RAM settings to a slower speed, so the memory has more time to respond to the CPU. Otherwise you could try adding on extra cooling, with a fan keeping the memory temperature down, or with a cooler for the entire board.
Similar threads
