Barracuda XT, Barracuda, Barracuda Green, DiamondMax and other desktop SATA and IDE drives

[Suudy]

I have a ST3250823AS drive that I've had for a few years.  This is the first Seagate drive I've ever had that seems to have failed.  It seems that this drive refuses to spin-up or be detected in the BIOS.  This suddenly appeared on a reboot.  I had it installed in a Fedora system, and I upgraded the kernel, rebooted, and it refused to boot.  Looking in the BIOS, the drive refuses to appear.

So, doing some searching, it appears that the Barracude 7200.11 drives have a known problem.  But this is a 7200.8 drive, and I'm not sure if those fixes apply to this drive.  There are no firmware updates available for the drive.

I can connect it to my Windows box via a USB-SATA connector and Windows (7) finds the drive.  At first, I was excited.  I thought I might be able to recover the drive.  So I booted into a Live CD Linux version, and the drive was failing with I/O errors.  So I though, ah heck, I'll just format it in Windows.  When I try to initialize the drive using Disk Management, I get "The request could not be performed because of an I/O error."

So I downloaded SeaTools and started running the tests.  Every single one of them pass.  S.M.A.R.T., short drive test,  short generic, long generic, and fix all fast pass.  Fix all long is still running, but I'm not anticipating a failure.

I'm at a loss here.  Any ideas?  My searching on the forums hasn't revealed anything, and Google even less.

[Cantbecanit]

Is it in W7 as a sata cable slave it doesn't appear?

If it's coming online as a USB it would indicate to me your O/S is broken, or the sata cable or port on the MB, have you tried other ports and cables  yet ?

Forget the 7200.11 thing, it's not applicable to 8 series drives.

[Suudy]

Here's the use cases.

Initially it was installed as a secondary master on a Fedora core box.  This drive came from an older WinXp machine I had put bigger drives into.  I had 2 of these drives, and both have failed similary.

After the failures, I had a spare 100G drive laying around that I put into this machine.  I then started trying to diagnose these drives. So I plugged one of them into a USB-to-SATA connector, and plugged that into a Win7 box.  I ran SeaTools, and all the tests passed.

Since your post, I tried the USB-to-SATA cable with another drive on the same Win7 box.  So I'm confident the USB-to-SATA cable is correct.  I then tried the USB-to-SATA on my Linux box.  When connected, I get the output below in syslog.  When I try to use fdisk for parted on the drive, I get a failure.

here's the 

May 13 11:50:14 scrappy kernel: [2410843.855483] usbcore: registered new interface driver uas
May 13 11:50:14 scrappy kernel: [2410843.875460] Initializing USB Mass Storage driver...
May 13 11:50:14 scrappy kernel: [2410843.875634] scsi8 : usb-storage 1-4:1.0
May 13 11:50:14 scrappy kernel: [2410843.876220] usbcore: registered new interface driver usb-storage
May 13 11:50:14 scrappy kernel: [2410843.876225] USB Mass Storage support registered.
May 13 11:50:15 scrappy kernel: [2410844.963093] scsi 8:0:0:0: Direct-Access PQ: 0 ANSI: 2 CCS
May 13 11:50:15 scrappy kernel: [2410844.992437] sd 8:0:0:0: Attached scsi generic sg2 type 0
May 13 11:50:17 scrappy kernel: [2410847.448326] sd 8:0:0:0: [sdb] READ CAPACITY failed
May 13 11:50:17 scrappy kernel: [2410847.448332] sd 8:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
May 13 11:50:17 scrappy kernel: [2410847.448338] sd 8:0:0:0: [sdb] Sense Key : Unit Attention [current]
May 13 11:50:17 scrappy kernel: [2410847.448344] sd 8:0:0:0: [sdb] Add. Sense: Not ready to ready change, medium may have changed

May 13 11:50:17 scrappy kernel: [2410847.485699] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled
May 13 11:50:17 scrappy kernel: [2410847.523200] sd 8:0:0:0: [sdb] Asking for cache data failed
May 13 11:50:17 scrappy kernel: [2410847.523204] sd 8:0:0:0: [sdb] Assuming drive cache: write through
May 13 11:50:18 scrappy ata_id[18507]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument
May 13 11:50:18 scrappy kernel: [2410848.545339] sd 8:0:0:0: [sdb] READ CAPACITY failed
May 13 11:50:18 scrappy kernel: [2410848.545345] sd 8:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
May 13 11:50:18 scrappy kernel: [2410848.545350] sd 8:0:0:0: [sdb] Sense Key : Unit Attention [current]
May 13 11:50:18 scrappy kernel: [2410848.545356] sd 8:0:0:0: [sdb] Add. Sense: Not ready to ready change, medium may have changed
May 13 11:50:18 scrappy kernel: [2410848.582837] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled
May 13 11:50:19 scrappy kernel: [2410848.620199] sd 8:0:0:0: [sdb] Asking for cache data failed
May 13 11:50:19 scrappy kernel: [2410848.620204] sd 8:0:0:0: [sdb] Assuming drive cache: write through

May 13 11:50:19 scrappy kernel: [2410848.620209] sd 8:0:0:0: [sdb] Attached SCSI disk

And when I tried again with fdisk or parted, I get the following in syslog:

May 14 13:14:06 scrappy ata_id[19810]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument

[Cantbecanit]

Hmmm, I have to be honest I'm not sure what has happened, if you think the Fedora thing may have got into the drives instructions though iirc Seatools Dos has a function to re-write what is basically a boot file to the drive, this is what I would try, and consider that it has simply died of age as well, but those scrappy messages suggest a command set change has happened to me.

[fzabkar]

If the drive doesn't spin up, then it is most likely a board fault. Alternatively, if you can hear very soft noises, then it could be a stiction fault (heads stuck to platters), or a seized spindle motor.