Spinrite 6.1 RC5 with OCZ Vertex 60GB SSD: Attempt to Execute Illegal Opcode

[cj0]

Drive: OCZ Vertex 60GB SSD P/N OCZSSD2-1VTX60G
Hardware: Foxconn R10 S2 or S3, I think the S3, thus board: 945S04, cpu: dual core Atom 330
Spinrite: 6.1 RC 5 on USB thumb drive
Error reproducible: yes, always (Segment and error location changes)
Other drives? Spinrite runs OK with other (rotational) drives.

With this drive Spinrite is running slow. Between spinrite start and drive detection error is approximately 4-5 minutes. Image _3191 is at :40 and error Image _3194 is at :44. Which is 4 minutes later.

_3190:

_3191 (after system restart):

_3192:

_3193:

_3194 (second time the Illegal Opcode error occurred):

 

[PHolder]

I have a memory of those OCZ Vertex drives having a buggy SSD controller or buggy drivers or something. I think I had one of those drives fail when new (purchased in a whitebox pre-built PC) and had to have it replaced. Were I you, I would restrict any usage of that drive to breaking SpinRite and replace it now with something more modern.

 

[Steve]

Yikes @cj0 !!

I definitely want to pursue this!!

To that end, I've sent you, under separate cover, the account creation instructions for creating a new account over at GRC's GitLab instance. (This information is non-public, for our developers and testers who have problems to report, only, since we want to keep bots and spammers out of there.)

One thing that's unclear is when this problem occurs, and where those 4 to 5 minutes are spent?

From your screen photos after the first reboot, it appears that the crash is occurring after _3193: and before _3194:, is that correct?

Screen _3193: show "Adding IDE drive @ E400:E402" ... so I'm assuming that the screen goes from there to the illegal opcode screen?

At that point, SpinRite will have already found the OCZ Vertex drive and the boot drive. Does that machine have another drive?

What I think would be most useful would be having you start SpinRite with the "diags" command-line option. This will cause SpinRite to create another ".DBG" file in the boot drive's SRLOGS subdirectory. Could you share that file either here or on our GitLab?

thanks!!!!

 

[AlanD]

We have previously established that Screen Thief will work with SR to capture screenshots. IIRC, Steve has made it available in the Downloads folder. https://www.grc.com/dev/SpinRite/DOS_Screen_Thief_TSR_v2.04f.zip

 

[Steve]

Is it possible to use a TSR program such as Snarf to capture SpinRite screenshots?

Huh... I've never encountered SNARF before. But as @AlanD noted, we've all been using Screen Thief. It's a very nice image capture TSR the gets along with SpinRite without trouble. (And, yes, I agree that it would be preferable to photos.) It once offered image compression, but patent issues with LZ compression caused its author to remove them. So it's BMP only, though we did locate a BMP to PNG converter for DOS that does a great job.

In the GitLab wiki I added a note about ScreenThief's (many) command-line parameters:

NOTE for ZimaBoard (and other) users: By default, Screen Thief does not recognize the ZimaBoard's video as VGA. But it can be told to by adding "/v:v" to its command line. Some other tricks are that the annoying screechy screen capture noise can be disabled using "/cl-" and screen capture can be converted into the traditional "Ctrl-C" (for Copy) by adding "/k:c /sh:c". Low memory fragmentation can be avoided by using "/bu:h" and resident memory usage can be minimized by adding "/st:128 /w:720". And, finally, increased stability under SpinRite can be achieved by adding "/rtc-". This can all be placed into a single environment variable by adding this list to your autoexec.bat file:
set screenthief=/bu:h /cl- /k:c /n+ /rtc- /sh:c /st:128 /v:v /w:720