Spinrite Crash during lvl 2

[SmashOveride]

Background: Running Proxmox PVE for my home lab and it keeps crashing. Memtest 86 show that I had some bad memory so I replaced that about six months ago. I was still getting crash problems so I ran spinrite 6.1 on the 4TB M.2 SSD and it gave me a random reboot. Level 2 would reboot after about 20 mins. I have run the level two and level three scans with the same results. Level three reboots after about nine hours vs 20 mins so there's that. I have run multiple attempts at level two and now finally running a level one scan. Of note, the first time I ran a level two scan, it did reboot...but my Proxmox stability was increased noticeably. It ran for about a month with no problems. Hence my suspicion on the SSD failing.

Other than the M.2 SSD just being toast, is there any reason why this would happen? Or perhaps anything else I can do? I did by a 2TB SSD to replace the 4TB to eventually transfer all operations to (WD_Black).

Thanks for all the help and insight.

Smash

 

[miquelfire]

I feel as though the real issue is either with the motherboard or the PSU. Double-check your power connections first, one of them might have gotten loose.

 

[PHolder]

Random reboots are the worst to debug/understand.

How old is the PC? Sometimes older PCs have problems with capacitors. Check the motherboard for any obviously bad/bulging/blown caps.

I would start with the obvious hardware debugging. Check that all the fans are working, and spinning freely (so check their spin with the power off, then power on and make sure they all spin up.) With the power off, check all the connections, re-seat any you can. Use some canned air and dust anything you think would use the attention.

 

[SmashOveride]

So I ran a level 2 scan on my new 2TB M.2 SSD and it completed no problems all green. The board is a Asrock X399 fatality. Since the scan runs on the 2TB no problems, I feel like this points back to the 4TB being thr faulty component.

I'm going to attempt to create an image of the faulty SSD and then deploy it to the 2TB SSD. Then I'll wipe the 4TB SSD, run spin right, and see what happenes. I got a feeling it will keep doing the reboot, but figure it's worth a shot.

Thoughts?

Thanks for the previous ideas.

 

[ColbyBouma]

It's not normal for SpinRite to reboot. Either it's crashing exceptionally hard, or something is happening at the hardware level such as your CPU overheating or a power problem (as mentioned above).
Can you scan the 4 TB SSD in a different computer?

 

[SmashOveride]

I do believe it is a hardware problem, but wouldn't the most likely culprit be the 4TB chip itself since I can successfully scan the 2TB SSD? With the way this machine is acting, it kind of feels the same as a bad stick of ram. Bad ram can cause a "glitch in the matrix" and instant resets right? I know they are not the same Flash vs volatile storage and operating voltages, but it's just the similarity in how this machine is acting that gives me that feeling. If it were a power supply or overheating CPU problem, wouldn't that have produced the same outcome when scanning the 2TB SSD running in a parallel slot? I could try swapping the SSDs with each other and see if the problem follows the chip? If the problem does not follow the chip, then the problem would be specific to that slot and a component that feeds it (like a bad capacitor previously mentioned).

Only other way that I could scan the 4TB drive would be for me to purchase an M.2 to USB adapter and run it on my laptop. How well does SpinRite run on external USB connected SSDs?

 

[ShadowMeow]

Try these...

ZimaBoard 232 2G 32G:

https://www.amazon.co.uk/dp/B0C61RZVJQ

ZimaBoard Dual M.2 NVME SSD Adapter Card:

https://www.amazon.co.uk/dp/B0BQFCTZ6Q

 

[AlanD]

With the way this machine is acting, it kind of feels the same as a bad stick of ram. Bad ram can cause a "glitch in the matrix" and instant resets right?

Is there more than one RAM module? Can you swap them? SR will only use the first part of RAM for buffers, if you have enough "spare" RAM, you might move the fault out of the used space.

 

[DanR]

How well does SpinRite run on external USB connected SSDs?

Well, maybe. SpinRite can only access USB drives thru the system BIOS. Thus it can be very problematic. And with very slow BIOS I/O speed when it does work.

SpinRite 6.1 does a Ram test at the beginning of the program that tests the specific ram that SpinRite uses - a very small amount of the total ram. Is that test error free?.

I would suspect a combination of the possibly failing 4 TB drive and possibly a marginal (at best) system power supply.
Normally, a failing drive should simply go off-line with SpinRite informing the user accordingly. SpinRite does NOT reboot a system,

Possible Long Shot: Re-seat all of the power cable connections from the power supply to wipe/clean the contacts, in case one of them has a dirty contact issue.

 

[peterblaise]

@DanR "... SpinRite can only access USB drives thru the system BIOS. Thus it can be very problematic ..."​

Perhaps it's best to identify 'problems':

- BIOS is slower ( as mentioned ) than some SATA - a 'problem' for those of us in a hurry. Note: some older HDDs hard disk drives transfer data over IDE/ATA/SATA at speeds equivalent to today's USB3, so even when a drive is connected internally over IDE/ATA/SATA, it may go slowly compared to new 'fast' drives, especially compared to new unused SSDs.

- BIOS USB may only see 137GB-ish - a 'problem' for those of us wanting to apply SpinRite 6.1 data recovery and drive maintenance to larger drives, though it's up to the BIOS, any particular BIOS may 'see' the entire drive, or may not even show any USB drive beyond a boot drive at all, and some USB sockets behave differently, so try them all before proceeding with data recovery and drive maintenance.

Essentially, we try it, and work with, or around, what we find.

Note, there's a FORCEBIOS command-line option in SpinRite 6.1 to bypass SpinRite's own IDE/ATA/SATA drives, presumably to resolve any stumbled-upon compatibility 'problems' we may find in any drive, and by going comparatively slower, BIOS-access has the advantage of being, um, 'gentler' when crunching through a wonky drive with a tough sector or two or more:

SPINRITE FORCEBIOS​

BIOS is just another tool, another way for SpinRite 6.1 to perform our data recovery and drive maintenance.

- - - - -

@DanR "... SpinRite 6.1 does a Ram test at the beginning of the program ..."​

I use the command-line option NORAMTEST to run SpinRite 6.1 without it running the RAM test . . . because I have noticed 'different' behavior in at least SpinRite 6.1 enumeration of drives present, and so, considering that my goals are data recovery and drive maintenance, I separate those two tasks apart from system integrity checking:

SPINRITE NORAMTEST​