this drive has taken itself offline and cannot be used

[Robert Hickman]

Hi,

I have an ADATA SU630 ssd that came out of my dads windows computer that suddenly started refusing to boot. I'm trying to run the latest pre-release 6.1 on it via a zimaboard, in order to see if there are any bad sectors reported. I suspect there is a flash cell on the drive that's reading the wrong data and causing the windows boot to fail.

In spinrite it reports "this drive has taken itself offline and cannot be used", But the filesystems on the drive can be read and mounted without issue under linux.
.

 

[Steve]

Hi Robert.

It's possible for there to be trouble on the drive that doesn't prevent the file system from being mounted.

During this testing we've encountered several other instances of this happening and it's among the very few things that are still needing to be addressed. What appears to be happening is that after encountering an error on a drive, SpinRite attempts to reset the drive after that error but then isn't happy with the drive's state and incorrectly declares it as being "offline". I'll get this sorted out for the next release candidate as soon as I get the digital signing stuff online and am back to SpinRite itself.

One thing you MIGHT try (I'd love to know whether this works for you) is that since I believe the trouble is in SpinRite's AHCI driver, its ATA driver might not have the same trouble. Unfortunately, the one feature missing from the ZimaBoard is the ability to configure its AHCI chipset as ATA (often called IDE or Legacy). But if you were to run SpinRite in another machine that supports SATA controllers in Legacy mode, SpinRite's ATA driver might NOT exhibit this trouble. It's not a solution (I still need to fix this) but it might be a workaround for now.

 

[Robert Hickman]

Hi Robert.

It's possible for there to be trouble on the drive that doesn't prevent the file system from being mounted.

During this testing we've encountered several other instances of this happening and it's among the very few things that are still needing to be addressed. What appears to be happening is that after encountering an error on a drive, SpinRite attempts to reset the drive after that error but then isn't happy with the drive's state and incorrectly declares it as being "offline". I'll get this sorted out for the next release candidate as soon as I get the digital signing stuff online and am back to SpinRite itself.

One thing you MIGHT try (I'd love to know whether this works for you) is that since I believe the trouble is in SpinRite's AHCI driver, its ATA driver might not have the same trouble. Unfortunately, the one feature missing from the ZimaBoard is the ability to configure its AHCI chipset as ATA (often called IDE or Legacy). But if you were to run SpinRite in another machine that supports SATA controllers in Legacy mode, SpinRite's ATA driver might NOT exhibit this trouble. It's not a solution (I still need to fix this) but it might be a workaround for now.

Hi Steve, thanks for your thoughts. Unfortunately I just checked my main computer's bios and I don't think it supports that configuration. The only options are 'AHCI mode' and 'RAID Mode', the latter I presume is AMD's software raid (its a recent RYZEN gen 2 system).

My other computer besides the zimaboard is running a file and version control server that my business depends on, and thus I don't want to mess with. The zimaboard is my 'test stuff computer'.

I can see if my dads computer can boot in that mode, but don't know right now as its a prebuilt and also pretty recent.

EDIT: my dads computer is also too recent to have that option unfortunately.

EDIT 2: I've been copying the data off the drive and there's definitely something wrong with it as various files fail with 'device missing' errors in windows, but the majority of the data is readable. I'll keep the drive around until you make an RC6.

 

[Steve]

I've been copying the data off the drive and there's definitely something wrong with it as various files fail with 'device missing' errors in windows, but the majority of the data is readable.

Right. That tracks with the facts you had shared earlier. The fact that the drive's file system mounts is good and lucky... but that doesn't mean that it's actually intact.

I'll keep the drive around until you make an RC6.

Great! Thank you. It's a perfect test case!

 

[Steve]

@Robert Hickman :
I've finished updating SpinRite to what I'm calling “pre-release 5.01.” (please use 5.02!) Its major improvement is that it is now much more patient, willing to wait up to 60 seconds for a troubled drive to come back online after an error than the 10 seconds of all earlier releases. I determined that some drives were taking longer than 10 seconds.

More information is in the announcement posting, here: https://forums.grc.com/threads/pre-release-5-01.1415/

I'll be super interested to know whether/how this works for you!

 

[RobertBlumen]

I am running SR 6.1 in a virtualized mode as described in some other threads on this forum. I have had the VM working for a few weeks and have run SpinRite successfully on several drives. I have attached the drives that I want to spinrite to the VM, spinrite recognizes them, and it has run successfully, so far.

I am trying to run SR on the 5th of 5 Western Digital SATA 4 TB ("Big Red") drives. The drive is are plugged into an external USB SATA drive bay.

Around the 70% complete point, I get "the drive has taken itself offline" message. If I restart slightly before that point, then it runs to around 70.01% and I get the message again. I can not proceed past that point. I have tried some basic troubleshooting such as restarting SpinRite, restarting the VM, and restarting the host. When it boots up it finds the drive and works up to the 70.01% area.

The host is a Windows PC. If I boot up into Windows, plug in the drive bay and open Disk Management, it recognizes the drive and does not report any errors.

 

[PHolder]

Around the 70% complete point, I get "the drive has taken itself offline" message.

I presume you're using the latest version of SpinRite 6.1 and not one of the pre-release snapshots? (It should be unlikely, but you never know. The development versions had changes in this area.)

Drive firmware is a black box to SpinRite. All it can do is ask the drive to do specific "authorized" actions like read and write LBAs. If the drive decides to refuse, or to stop responding to SpinRite, there is nothing SpinRite can do to address the issue. In essence, SpinRite seems to stress the drive in a way it doesn't like, and its response is to temporarily simulate being a brick.

What are you seeing in your logs around this point, perhaps you can share some of your logs?

Have you tried moving beyond 70%? Like start at 71% and see how that goes?

Also, there is a command line option you can try. FORCEBIOS. I don't know if it will work differently in a VM environment, but on actual hardware it was known to behave different in development editions. It will definitely run slower though.

 

[RobertBlumen]

I am running the latest 6.1.

As for the driving not liking spinrite, I have five drives of the same model and the other four ran to completion without this issue. If it is an issue with the drive it is with this instance of the drive, not with the entire family.

I did not notice the logs. I will run it again and look at the logs.

I have not yet tried starting at 71% but I will try that also.

 

[PHolder]

If it is an issue with the drive it is with this instance of the drive, not with the entire family.

Two things.

The Red Drives (I have many) have a firmware version indicated on the label. It's possible you do have a drive with different firmware than the others, so you should at least check that.

Red firmware is the NAS firmware, and it behaves differently with respect to recovery, because it expects the NAS RAID software to handle all errors in a way that is compatible with the RAID. (Presumably the NAS would read the other drives to rebuild a defective sector, and then relocate the data or something like that. I presume most NASes are not inclined to mess around with potential data loss as that is not something a user would enjoy.) Accordingly, the firmware might not try as hard as non NAS firmware, and so might disconnect more readily under specific circumstances that we, on the outside, are completely unaware of. The fact your one drive is acting differently is an indication of it having some [media] error the others do not.

I guess a third thing is: I hope you're not testing drives that have actual data on them that you intend to keep. If you make changes/"repairs" to a drive outside of your NASes RAID, you may learn the hard way that your NAS will not like it. When it comes to NASes, it's ALWAYS the best idea to run the NASes specific audit [routinely on a schedule is best].

 

[RobertBlumen]

I will check the firmware version on the drives. I might be able to get that from the UI of my NAS or I will have to shut down the NAS.

I have five drives for a NAS with four bays. At any time four of the five are in use. The one that I am running spinrite on is the spare. I don't care what happens to the data on the spare. I only want the drive maintenance benefits of spin rite. I want the spare to be in good condition in case I need to swap it into the NAS.

 

[RobertBlumen]

The four drives that worked have firmware revision 83.00A83. The one that I am having problems with is 82.00A82.

 

[cschuber]

Could the drive have a password applied to it? Some BIOSen have a disk drive protection feature. This writes the BIOS password to disk EPROM. You will need to either reinstall the drive back into your dad's machine, remove the drive protection, then remove it.

I apply BIOS passwords. On one laptop I had enabled disk drive protection. Moving the drive to another laptop, it failed to boot. I had to put the drive back into the old laptop, remove BIOS disk drive protection, and move it back. Both laptops had the same BIOS password.

 

[RobertBlumen]

I presume you're using the latest version of SpinRite 6.1 and not one of the pre-release snapshots? (It should be unlikely, but you never know. The development versions had changes in this area.)

Drive firmware is a black box to SpinRite. All it can do is ask the drive to do specific "authorized" actions like read and write LBAs. If the drive decides to refuse, or to stop responding to SpinRite, there is nothing SpinRite can do to address the issue. In essence, SpinRite seems to stress the drive in a way it doesn't like, and its response is to temporarily simulate being a brick.

What are you seeing in your logs around this point, perhaps you can share some of your logs?

Have you tried moving beyond 70%? Like start at 71% and see how that goes?

Also, there is a command line option you can try. FORCEBIOS. I don't know if it will work differently in a VM environment, but on actual hardware it was known to behave different in development editions. It will definitely run slower though.

I tried starting at 71% and spinrite proceeds. I let it run for a while, not all the way to the end but longer than it was taking to stop before. I think that this isolates the problem to something on the disk in between 70-71%. I would have hoped that SpinRite or the firmware on the disk could isolate the bad sectors and mark the as off limits, but it seems not. At this point do I have a defective drive and I should replace it?

 

[RobertBlumen]

Could the drive have a password applied to it? Some BIOSen have a disk drive protection feature. This writes the BIOS password to disk EPROM. You will need to either reinstall the drive back into your dad's machine, remove the drive protection, then remove it.

I apply BIOS passwords. On one laptop I had enabled disk drive protection. Moving the drive to another laptop, it failed to boot. I had to put the drive back into the old laptop, remove BIOS disk drive protection, and move it back. Both laptops had the same BIOS password.

I'm not sure if @cschuber is responding to me or @Robert-hickman who was posting about his Dad's computer. On my computer the drives are not password-protected.

 

[DanR]

I would have hoped that SpinRite or the firmware on the disk could isolate the bad sectors and mark the as off limits, but it seems not. At this point do I have a defective drive and I should replace it?

Since there is no data of concern on the drive, you might consider trying this: Start SpinRite with dynastat 0 on the command line

spinrite dynastat 0

Start at 59% and stop at 72%. That could force reallocation of the bad sector(s) with NO data recovery attempts to stress the drive into going off line.

If so, then in theory the drive would be "repaired" but may always have a cloud of doubt hovering over it.