Seagate Barracude 7200.7 8GB - ST380011A - died

[atzensepp]

last week my 80 GB data disk - a ST380011A - began to deteriorate. Although Bios and chkdisk did not complain errors the drive went slower and slower until the system (Windows XP) hung for up to a minute. Smart-Tools revealed a very high and increasing raw read error rate.

Since for several important files on that disk were no backup - forgot to include them in the selection - I tried to rescue what could be done. Unfortunately the system hang during the copying.

The second try: make a raw backup with ddrescue. The disk does not make strange sound but got very hot - I think that is normal - and the maximum read rate were 200 - 500 kB/s. I ran raw backup overnight and obtained 18 GB raw data but then the read rate dropped to vicinity. If I restart reading from 41 GB onward the rate increases again to 200 kB/s - still too slow for being normal.

Since the reading rate is so slow I was thinking that the electronics is gone and I wanted to give it a try with a pcb replacement. On the other hand the degradation of read speed with subsequent reading could indicate that the cylinders are "worked out" by reading.

Is there a way to find out if electronics is defective or if there is a surface damage?

Or could one conclude from the symptoms described, that an electronic error is very unlikely.

Any suggestions for diagnosis and proceeding?

thanks

[pcimage]

Unlikely to be PCB, more like weak/dirty heads or media issues.

If you really need the data then please stop tinkering with it and seek a pro with the right equipment to get as much as possible out of this dying drive.

[SAjunky]

You received professional advice, the best solution. As your drive is still accessible, you can also try to disable SMART before copying - and also automatic sector relocation (if present on ATA commands menu in HDAT2). That would prevent drive from relocating bad sectors or updating SMART statistics during copying. One bad in SMART area can slow copying process to death and can also cause total lockup. So assuming your user space surface is still good, it should work.

[atzensepp]

Thank you for your suggestions. SAjunky: Your proposal sounds to be worth a try since it is "non-invasive" and leaves option for a professional recovery open. The HDAT2 tool seems to be suitable for drive testing and parameter setting but not copying. Will the settings done with this tool (disable SMART statistics and sector relocation) "survive" a reboot so that one can copy the files from within Linux or Windows?

[SAjunky]

This shoud be an option when issuing command. What HDAT says? And what it reports after power cycling?
Once you disable it (and possibly similiar options), continue with DD, of course, see if helps.
BTW, DR's do the same from their software or terminal interface.

[SAjunky]

Just tested the same model, F/W 3.06, it rejects command "Reverting to power on defaults". It means disable SMART is valid only to the next reset.

[atzensepp]

Well SAjunky many thanks for your suggestions! I would likt to give it a try since it sounds very plausible.

But how would I disable the SMART statistics for the drive? Under Linux there is smcarctl. But I am in doubt whether it can disable the drive specific setting. And also hdparm seems not to do the job.

But with HDAT2 no persistent change can be made and also not a copy of a partition afaik. And Plugging IDE cable off, reboot to Linux and reattach the cable does not sound reasonable and bears the risk to damage controllerboard.

There must be some low level hd programs that are capable to make the settings and perform a disk copy. I guess most of the expensive professional DR-tools will be able to do it.

Another idea was to tweak the settings in Seagate's "Terminal Mode" with a RS232 connector. (Actually I have successfully connected to the drive). But from what I read the HDD listens either to IDE or to the maintenance port. Switching means reset of the hdd which means that the settings will get lost.

Data seem so near but is still far away.

[SAjunky]

If smcarctl can use user supplied ATA commands, it should be able to disable SMART. Disable SMART is an ATA standard command, documentation is freely available, you can find it also in DTAT2 documentation. Other way is to use MDMA or HDAT2, then start DOS version of DMDE for copying. But it will be slow, as you have tried it already.

If you have already working terminal, then I think you can do better things...
I suggest to try it on similiar working drive with no data on it! Once you are confident continue step by step:
1. Examine drive condition using safe to use commands, capture output to file.
Open terminal (9600, one bit stop, no parity, no handshake) and capture HDD power on startup. It is good to have separate power supply for your hard drive.
^Z (to bring terminal up)
^U (current stuff)
^L (ROM info)
^A (Eng rev)
. (dot)
; (semicolon)
%
?
k [ENTER]
y [ENTER] (wait few seconds)

If some command return error, command to load CERT ^R
Go to level 2
T>/2
2>x (display zone map)
2>/0 (back to T level)
T>V4 or V7 (for G-list)

Post result here, maybe some good soul come with suggestion, I will be watching, as I have the same model also with slow sectors waiting for service!!!

In meantime waiting for answers:
2. Find from above how to find firmware pointers and backup firmware on the patient drive using STmem-Win (on files section of this forum). You need copies of APP, CERT, CERT TABLE, ATA OVL and Vendor tracks.
Script to backup a track:
R_SECTORS/Track_No/0/Read_buffer_No/0/SPT/filename.trc/1/1

3. Learn how to test heads, as many things depends on heads condition.

[atzensepp]

Hi SA Junky. Thank you for your detailled suggestions!

Lately I found how - in principle - one could copy files with the tools from HDAT2. One problem you already mentioned: copying is very slow. The other one is that the copy command has some difficulties with long NTFS filenames. But in my opinion one needs a raw copy.
(b.t.w. the weird thing is that HDAT2 does not report any bad sectors if scanning for them)

I have to make myself familiar with the material you provided. Accidentally I have a second old ST380011A drive with the same PCB board number (but with different Firmware: 8.01 ). I will try to use it as a "training vehicle" for terminal mode lessons.

[SAjunky]

Re long filenames, can't do it under DOS, but at least you get files.
RAW copy is the method suggested by professionals. It should be used, unless there is only few important files to transfer.
No bad sectors, nothing special. You will see it in terminal... Just check if partial copy has valid data on it (if you decide continnue with copying).
I suggest to take a time for research, it is what I am doing now...
And remember: as long you are doing right nobody is going to help on this forum. When you make mistake, bunch of good adviisors will popup and couple smiles
Just forgotten: clean PCB contacts with soft pencil rubber before continuing. Firmware corruption you are experiencing happens due to the poor contacts!

[atzensepp]

This is the result of your command seuqence.
k and y don't work. And AT-stuff is empty in contrast to my other (8.01-er) drive.

Interface task reset
1024k x 16 buffer detected
ALPINE - 1_Disk M.14 01-16-03 11:51

Buzz - Head Mask 0000 - Switch to full int.
Spin Ready
3.06 02-17-04 10:59
(P)PATA Reset

^Z
T>

^U
T>AT Stuff
0000: 0000 0000 0000 0000 0000 0000 0000 0000
0008: 0000 0000 0000 0000 0000 0000 0000 0000
0010: 0000 0000 0000 0000 0000 0000 0000 0000
0018: 0000 0000 0000 0000 0000 0000 0000 0000
0020: 0000 0000 0000 0000 0000 0000 0000 0000
0028: 0000 0000 0000 0000 0000 0000 0000 0000
0030: 0000 0000 0000 0000 0000 0000 0000 0000
0038: 0000 0000 0000 0000 0000 0000 0000 0000
0040: 0000 0000 0000 0000 0000 0000 0000 0000
0048: 0000 0000 0000 0000 0000 0000 0000 0000
0050: 0000 0000 0000 0000 0000 0000 0000 0000
0058: 0000 0000 0000 0000 0000 0000 0000 0000
0060: 0000 0000 0000 0000 0000 0000 0000 0000
0068: 0000 0000 0000 0000 0000 0000 0000 0000
0070: 0000 0000 0000 0000 0000 0000 0000 0000
0078: 0000 0000 0000 0000 0000 0000 0000 0000
0080: 0000 0000 0000 0000 0000 0000 0000 0000
0088: 0000 0000 0000 0000 0000 0000 0000 0000
0090: 0000 0000 0000 0000 0000 0000 0000 0000
0098: 0000 0000 0000 0000 0000 0000 0000 0000
00a0: 0000 0000 0000 0000 0000 0000 0000 0000
00a8: 0000 0000 0000 0000 0000 0000 0000 0000
00b0: 0000 0000 0000 0000 0000 0000 0000 0000
00b8: 0000 0000 0000 0000 0000 0000 0000 0000
00c0: 0000 0000 0000 0000 0000 0000 0000 0000
00c8: 0000 0000 0000 0000 0000 0000 0000 0000
00d0: 0000 0000 0000 0000 0000 0000 0000 0000
00d8: 0000 0000 0000 0000 0000 0000 0000 0000
00e0: 0000 0000 0000 0000 0000 0000 0000 0000
00e8: 0000 0000 0000 0000 0000 0000 0000 0000
00f0: 0000 0000 0000 0000 0000 0000 0000 0000
00f8: 0000 0000 0000 0000 0000 0000 0000 0000



Not configured-0


^LALPINE - 1_Disk 3.06 02-17-04 10:59
Built for ALPINE,GRAND2,Diamondback,TI1761 PreAmp,STL6 Andante PreAmp,InternalSp
in,GC110,SVC123AC,OneToOne,2Disk,LowDelta,220 Servos,7200RPM,8Pole,NonModGray,10
0MHz,Code DRAM,Early Exit,Stall Converter,RwFeat=0000,SeaDex,HDW

^A
Eng Rev = .100

.Pgm=00 Trk=0F6B8(0F787).0(0).240(23E) Zn=9 Err=00 ErCt=119D Hlth=0008 CHlth=0000
Ready LBA=00000000

;
Age=50 Type=21 MxCyl=16358 MxHd=1 MxSct=44C BSz=0000 TCode=0000

%
:5000000821000001 AX`5JV8NXRQ' "000000000000"0F68E-0F70D
SRAM Ovly = Diag

?
RD:0200:10
WR:0210:10
AC:022B:01FF
AS:042A:0065
SC:048F:0201
DP:022B:01FF
BA:0227:03
ST:022A:01
logbps:0200
codebps:0200

uP:0FE2:1E
FM:0220:07
AD:0220:0B
RL:0FDD
SL:0F1A
AL:0F03
MZ:0FF6
k
Command Inactive - No VALID Cert Code Detected
T>y
Command Inactive - No VALID Cert Code Detected
T>
^R (takes 16s)
T>( VALID Cert Disk Code Detected - Revision # .146

T>/2
2>x
Zone 00: 00018 - 00BE8 1100 (044C) 683.439
Zone 01: 00BE9 - 027FE 1056 (0420) 666.63
Zone 02: 027FF - 04707 1026 (0402) 646.275
Zone 03: 04708 - 06CA3 990 (03DE) 622.431
Zone 04: 06CA4 - 08B66 953 (03B9) 602.353
Zone 05: 08B67 - 0A479 916 (0394) 580.392
Zone 06: 0A47A - 0C405 880 (0370) 545.882
Zone 07: 0C406 - 0D99A 836 (0344) 527.59
Zone 08: 0D99B - 0ECD9 806 (0326) 506.144
Zone 09: 0ECDA - 10337 770 (0302) 480.724
Zone 0A: 10338 - 11397 733 (02DD) 461.672
Zone 0B: 11398 - 12854 691 (02B3) 437.423
Zone 0C: 12855 - 13F38 660 (0294) 410.353
Zone 0D: 13F39 - 14AE7 623 (026F) 396.401
Zone 0E: 14AE8 - 155D6 605 (025D) 383.316
Zone 0F: 155D7 - 16358 572 (023C) 363.922
Sys= 0F68E-0F70D 0280 SPTK on sys trks
Total LBAs = 095333FC


V4Num Entries = 07A7 Checksum = C34A
Alt 0012B.0.384 Offset 0028
Alt 00194.0.34E Offset 0029
Alt 001A4.0.387 Offset 002A
Alt 001FB.0.343 Offset 05A3
Alt 00287.0.34F Offset 0005
Alt 00287.0.354 Offset 003C
Alt 004D6.0.38D Offset 05A5
Alt 005B7.0.368 Offset 05A7
Alt 0067E.0.2FD Offset 05A8
Alt 01750.0.248 Offset 0369
Alt 01750.0.249 Offset 0021
Alt 01750.0.24C Offset 036A
Alt 01750.0.24D Offset 036B
Alt 01782.0.245 Offset 036C
Alt 01782.0.246 Offset 036D
Alt 017A4.0.397 Offset 036E
Alt 01A44.0.280 Offset 0424
Alt 01A62.0.2E3 Offset 0425
Alt 01B10.0.375 Offset 004A
Alt 01B12.0.28C Offset 0426
Alt 01B35.0.30A Offset 004B
Alt 01B5E.0.1F4 Offset 0427
Alt 01B5E.0.1F5 Offset 0428
...

now waiting for the good soul to comment.

[atzensepp]

There is a toll named "Seagate Firmware Repair 5.0" from SalvationDATA Lab.
Does someone know this software? It promises to diagnose and fix some 7200.7 specific HDD problems.

Does someone think this tool could be useful for the problem of my drive? I am sceptic.

[SAjunky]

Don't worry about k and y commands. It work only on higher firmware.

Don't take it granted (not at all), but think as follows:

1. You are right about stuff. Suggests read/write problems.
2. The same:

Code:

Pgm=00 Trk=0F6B8(0F787).0(0).240(23E) Zn=9 Err=00 ErCt=119D Hlth=0008 CHlth=0000

Acumulated health 0008 and Error count since restart show the same.
3. Loading CERT takes 16 seconds, also read errors in system area..
4. Now look at this:

Code:

V4Num Entries = 07A7 Checksum = C34A
Alt 0012B.0.384 Offset 0028
Alt 00194.0.34E Offset 0029
Alt 001A4.0.387 Offset 002A
Alt 001FB.0.343 Offset 05A3
Alt 00287.0.34F Offset 0005
Alt 00287.0.354 Offset 003C
...

Almost 2000 entries in G-list! I look at my sick drive - also 0x7A7. There is no coincidence, G-list must be full in both cases. Bucket overflows and firmware waits for relocation process to complete (which never happens), then after timeout control is transfered back to the reading routine, but not for long. A reason for slow read.
I am missing important information here. Are all entries on the same head? Look at bold area:

Alt 0012B.0.384 Offset 0028

If defects belong to the same head, there could be two reasons:
a) - weak failing head (not good!)
b) - missing or incorrect adaptives for this head.

Slow loading CERT suggests that CERT code or table is corrupt.
It means that you can successfuly read data if you simply find backup copy of CERT Table and load it back to the right place. This is assuming that adaptives are stored in CERT table (which I am not sure).

Your first step is backing up your firmware, then repair CERT area.
Then your third step is to clear G-List, as it was created based on wrong adaptives. That will restore speed for long time, hopefully enough to squize data out (assuming head 0 is still OK).
Any suggestions?

.... Scotty, don't beam me out!
I think Salvation Data utility will work only in the situation of pure firmware corruption, not in this case. Don't try it before backing up your firmware.
Are you going to continue? I will be writing script for backing up my firmware, you can use it. Otherwise you can use SeDiv, I think.

[atzensepp]

SAJunky thanks for your comments!

1. AT Stuff
In this forum there is something about Regeneration of "Stuff":
dump-firmware-from-disk-necessary-areas-t12951.html#p85332

and here:
seagate-momentus-5400-problem-t11419.html

It was stated:
"Stuff" contains ID information on Seagate drives (like model name and LBA sectors number, so it's important)
Stuff located on vendor track
Worth a try, isn't it?

4. G-List Entries (V4 command):
I can confirm that Only entries for Head 0 are present

CERTtable
Loading CERT table (^R) does not issue an error message
if CERT table is corrupt at least an error should be printed
if the CERT table storage area is defective a copy to the same area does not make sense, so
it has to be relocated.
Where is the CERT table located and how can I find a copy of it?

Firmware
Backup of Firmware
Until recently I have thought that:
- Firmware is stored in the controller chip and not on the platters
- Firmware should be the same for all drives
- Only drive specific data is stored on the disk or in a flash eprom

No idea yet how to backup a firmware. So I would be interested in your script.

New Symptoms appear
Either an effect of tinkering or the death of the drive is nigh, I have observed now that from time to time following unfriendly messages appear at boot time:
CE Log EC=0 Rtype=36 OV=0 STStatus0
AutoRd Err 43 at 00f6ba.00.0002

Read Ver Retrys
AutoRd Err 43 at 00f6ba.00.0002

Read Ver Retrys

As long as the drive is not fully bricked and I will try to proceed. I must be crazy.

[SAjunky]

You have corrupted Vendor track.

Code:

Sys= 0F68E-0F70D 0280 SPTK on sys trks

This is your service area (with firmware code and data) Only small boot code and essential data about hardware options is located in ROM.
SA starts from cylinder 0xF68E, this is your base cylinder, 0x280 sectors per track.

This is a message of error reading sector (?) on track 0xF6BA

Code:

AutoRd Err 43 at 00f6ba.00.0002

Firmware parts are located on fixed offset relative to the base track. 0xF6BA minus base = 0x2C
Now we know for sure that some sectors on Vendor track are unreadable, as 0x2C is offset for Vendor track. System area has no dynamic sector relocation, but writing over with proper data can fix a problem. So in other words, the way to deal with it is to find a copy and rewrite original location. If doesn't, RAM image can be loaded from a spare location. It will fix problem till the next power cycling. Going sleep, tomorrow will test script on my drive and post it here.

[Vulcan]

You have corrupted Vendor track.

That would not get my vote (read errors != corruption) but due to our previous communication problems, I'll let someone else see if they want to try to explain... I don't need the stress. If you're sure that your diagnosis is correct, then I wish you good luck helping the OP.

[BlackST]

Ideas FEW and confused. And the drive is NOT failing "as is". Perfectly recoverable - for me - using the drive OWN heads (at this stage) but with all this TMI you are just 1 step away from destroying it.
P.S. ALPINE are a story on their own about problems and failures. Oh, and some stuff is NOT necessary for the drive to start / work, so why worry ?

[SAjunky]

I knew you were coming if I make wrong assessment, didn't I? I wrote about it! Of course, it must be some other damaged area, thanks for a tip!

[atzensepp]

@SAJunky: thanks for your ideas! I am looking forward to your script.

@BlackST: You seem to know the ALPINE family and their common genetic diseases. May I ask you what would be your assessment of the drive situation and what would be your apporach? What should I avoid at any rate?

PS: I am feeling like in a Labyrinth with "deadly" traps.

[BlackST]

PS: I am feeling like in a Labyrinth with "deadly" traps.

Risks of the DIY labyrinths...