Warning: Careful about using WD drives on RocketRAID controller cards

Had 4 WD7500AAKS disks connected to a RocketRAID 2320 controller in JBOD configuration. Now that I want to use the disks independently elsehwere, without the 2320 controller, I’m finding that Windows won’t detect them. Scenario shares some similarity with this thread, and from Newegg feedback it seems HighPoint may have a problem with this controller writing RAID headers to certain WD drives that makes other controllers unable to detect them.

Data Life Guard boot disk can detect the drives and run tests. I’m wondering if writing 0s will “reset” them to a normal state?

After much investigation it appears that this indeed is a known problem with RocketRAID 2320 and certain WD drives. I don’t know if it extends to other HighPoint controller cards. Basically if you ever initialized an affected drive on this particular controller, it can’t ever be used again with other controllers, so please think carefully if you have a similar setup.

AIUI, RAID controllers write their metadata to track 0 of each drive. I don’t know whether this also happens in JBOD configurations.

Could we see the partition table and boot sector with Microsoft’s Sector Inspector?
http://www.users.on.net/~fzabkar/SecInspect.zip

Extract the above archive to the one folder and execute the SIrun.bat file. The procedure will generate a report file named SIout.txt which you can then upload to a file sharing service so that we can examine it.

You could also examine track 0 (sectors 0 to 62) using a disc editor in read-only mode.

HxD - Freeware Hex Editor and Disk Editor:
http://mh-nexus.de/en/hxd/

Thanks for the suggestions. While I haven’t tried the tools mentioned above, I did use (http://hddguru.com/software/2005.10.02-MHDD/)]a low level inspection tool, which showed sector count as 0. I may go back to work on them some day but at this point I don’t need to use the affected drives immediately and am just tired of working on this problem, so giving it a break.

I had the same problem, but in my case all four of my WD2500YS were dead to the BIOS on two different ASUS motherboards. All the drives had been connected to my RocketRaid 2300, and I wanted to use them in a soft raid config, as the RocketRaid now runs with 4 x WD15EARS. I found the actual reason for the drives to show up as being 0 GB in size: they did not power up when I turned on the power. I confirmed that they were supposed to power up and spin up by connecting another SATA drive to the mobo. The strange thing was that I was able to install Linux on the drives, and when i did a warm reboot the drives showed up in the BIOS and worked as expected. But a cold boot left me with mystery drives again. A lot of searching around the net led me to this thread, and I immediately “knew” the solution. I ran into my computer room 10 minutes ago, and hooked up one of my drives to the RocketRaid, and went into the RocketRaid’s BIOS. There I disabled “staggered spin up”, reconnected the drive to the ASUS mobo, and lo and behold - the drive powered up and was recognized by the BIOS. I hope this is something that makes it into WD’s FAQ, as I guess all WD drives will suffer from this problem if connected to a RocketRaid card, and staggered spin up is enabled. This might even happen with all other RAID-cards that implements staggered spin up.

1 Like

Thanks for the tip. Unfortunately my situation is a little different, as staggered spinup was disabled, and I assume if the disks had not been powered on, they would not show up in BIOS at all or in Data Life Guard.

Someone else suggested that the disk wiping tool DBan might work, so that’s something else I’ll try given time.

Well, my disks showed up in the BIOS, but with an empty description text and with 0 GB in size (this was an ASUS A8N-E MB). The disks did power on after I booted into DOS and run the program to flash the disks to the latest firmware, and also the Ubuntu Server installation disks were able to find, and power on the disks. This can probably be explained by the fact that linux probes the disk controller independently of what the BIOS reports. Have you tried connecting the drive to the RocketRaid card, and verified that the actual disk has not gotten the staggered spin up enabled?

The ATA standard defines a Power Up In Standby (PUIS) feature set.

See section 4.19 (page 49) of the following document:

Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/Documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf

Here is an excerpt from the standard:

If the device:

a) implements the Enable/disable Power-up in Standby subcommand;
b) has the PUIS feature set enabled; and
c) receives an IDENTIFY DEVICE or IDENTIFY PACKET DEVICE while the device is in the Standby power mode as a result of powering up in that mode,

then the device shall respond to the IDENTIFY DEVICE or IDENTIFY PACKET DEVICE command without spinning up the media. If the device is unable to return a complete response without accessing the media, then the device shall set word 0 bit 2 to one to indicate that the response is incomplete . At a minimum, word 0 and word 2 shall be correctly reported. Those fields that are not provided shall be filled with zeros.

The meanings of Words 0 and 2 are defined in section 7.16.7.