So this is an old thread, but I wanted to follow up on the matter.
sent me the drive in question and I received it today. It didn't take me long to encounter issues.
SMART shows the drive in the state shown here:
The first thing I did was attempt to zero the drive, which is the same thing rockisland
attempted to do earlier.
Within a few moments of the zeroing beginning, I started hearing repetitive clicking coming from the drive itself
. The clicking sounds like a head that's stuck repeatedly trying to re-read a sector, and not the actuator arms resetting back to track 0. I doubt rockisland
could hear this if the drive was mounted in a chassis or enclosure, but I do all of my testing with bare drives externally attached to a system (literally SATA power and SATA data cable hanging out of the case).
, which of course was blocked for quie some time by the kernel CAM and underlying AHCI layer since it was waiting for an I/O transaction, and the CAM timeout is 30 full seconds. During this time, I started seeing this on the console (which is to be expected):
A general end-user probably can't decode any of this, but it reads quite clearly to me. The drive began experiencing a physical problem of some sort (and is stil experiencing it) causing the entire SATA bus (well, this port) to lock up hard. The reason is that the underlying firmware on the drive, on this model, is apparently designed very
poorly -- it does not handle error conditions correctly.
The end result is a drive firmware itself which is stuck in an infinite loop trying to deal with the underlying physical problem (whatever that may be); the SATA controller on the drive
appears to be entirely driven by the firmware as well (this explains the deadlock, followed by the drive falling off the bus entirely -- AHCI/SATA protocol should still work despite the underlying drive going catatonic).
As I type this, the drive is still clicking away, and refuses to reappear on the bus because the firmware is downright wedged. It's been literally a full 10 minutes now, which is longer than the total amount of CAM retries and timeouts (5 retries, 30 seconds each).
I tried the god-awful trick of smacking the drive against a flat surface while operational -- this is not something I normally do, but when I hear a drive clicking like this, it's sometimes worth it to see if you can jostle the arm enough that it might unwedge or trip some other condition in the underlying firmware code. Sadly no avail -- I even heard the drive (mechanically) re-set the actuator arm but it went right back to trying to clicking. It's hell bent on trying to read that naughty LBA.
So bottom line is that there's no way to reset this drive without power-cycling it. It flat out refuses to respond to any ATA CDBs once it gets into this indefinite loop, and as such, also stops responding at the SATA protocol level. Pretty awesome; nicely designed firmware! *cough* :P
There isn't much I can do with the drive other than use it as a real-world example of how technology since the days of this drive (circa 2006) have evolved and improved. What's extra amusing is that the WD1500ADFD is a 10,000rpm Raptor drive, which is what WD toted as "reliable and fast and awesome" -- it just goes to show no matter how much money you pay, no matter what "classification" of drive you buy, what ultimately matters is whether or not the programmers of the underlying device firmware actually designed their code sanely and never to get stuck in deadlock/infinite loop situations like this one.
Attached is an .mp3 file recorded from my digital camera of the clicking in question, amplified by 8dB. :-) I do plan on opening this drive while it's in operation to see if there's some visual defect or reason I can detect for its issue.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.