Fix SMART attribute UDMA_CRC_Error_Count on a WD Red

[diybit]

I think the problem about the port come from your AHCI setup, look at your 1st screen, there was the col "Cmd port", you need to reinstall Windows with the IDE mode set in BIOS for it works... (I dont know if there are other way instead reinstall...)
It's about sure that HGST_eng.exe will not works in AHCI mode, and for many others tools too.
You will be able to at least identify the drive when you will be in IDE mode.

The HDD-LLF tool from hddguru will normally not reset the UDMA CRC error you are looking for.

I have some experience with those EADS, and maybe your present the SMART symptoms of a full head in a very weak state.
I suggest you firstly doing one full erase with HDD-LLF or Victoria to confirm that you can erase it at a correct speed rate.
I suspect that your drive is actually suffering from the slow issue, and this will not help for testing the VSC "Format Unit" that will maybe take a year to finish...

[diybit]

Im looking to try on my side what I suggest you to do, with my last defective WD20EADS.

Mine is very capricious, with a SMART really similar to yours, in a slow issue mode.
Usually I success to gone from this slow issue by just full writing it, but this time, it completely restart firmware itself on some sectors, that next need to be unplug and disable/enable in device manager to continue the writing with Victoria... (HDD-LLF freeze with a Windows reboot needed to exit it)

The only method I have found that not made this writing scan annoying is by using Victoria PIO mode, but the speed is very low and fall at about 0-1MB/s on very bad spots.
After the very bad spot passed, I return to the UDMA mode, hoping it will not hard re-fail...
And it really do something because re-passing to those very bad spot in UDMA does not reproduce the firmware restart.

The goal is to write on those sectors that are currently pending for they gone to a normal state, that will normally finally resolve the slow issue.
If some "big" parts cannot be written after some retry, resign the write scan, it's likely you have a full defective writing head.

So this message can help you to partially success repairing it...
Try to obtain that the drive "nicely" full write, and then full read it to see the result.
But yes, you cannot right re-thrust it just by doing that, but in some case you can be lucky, and get a drive that is not in a so bad state, for no critical data usage. (but those EADS seems awful...)

I know how to manually fix this slow issue by editing mod02, but Im doing some experiments with this unusual defective drive... (and also in situation without proper tools)

I hope you will not facing the same problems as me...
Anyway Im going to finally try HGST_eng.exe, and I will tell you if the VSC is working, but be patient, in one week max.

[diybit]

Waooh, the fucking drive... I finally succeeded to exit the slow issue, after a very hard battle...
I have never seen that, drive was full rewritten, but all pending was always there...

Here a "tiny" resume of what I have done :
- full write Victoria that was ugly for the about first 50GB, there was no slow issue on about all the next
- I have switch 2-3 times to PIO to avoid drive reboot
- then the drive have enter to an ultra slow issue that even writing was slow on all the drive
- I spotted inside the WDMarvel VSC monitor that it was doing the "Background Data Lifeguard" that I have let it finish to 100%
- then the offline UNC have pass from about 1300 to 700, pending always not moved at about 1300
- I continue trying to write on a very bad spot that now even in PIO mode produce a drive reboot
- try Victoria read remap on this bad spot but the block that produce the reboot is "fine" reading and no remap is done, some others around have been...
- I was on the road to exactly detect what sector is the culprit to avoid getting a giant useless G-List, sadly Victoria minimum block is 32 sectors
- I would find a Windows solution before passing to a DOS mode to detect this faulty sector, and then manually marking it bad with MHDD/HDAT2/hdparm
- first I try an tool I have coded year ago for another defective drive and it success writing without reboot, wow
- I retry Victoria and it reproduce the drive reboot, I dont know what special thing have my tool that Victoria would not have, it use pure WinAPI, like Victoria it seems...
- so I continue doing some write with my tool and the pending finish by fall to about 600
- slow issue have become less aggressive, I try to read the start of the drive, and it show me like those usual drops sign of one weak head
- I begin to be afraid that maybe Im going to completely kill this head, while maybe I will have saved it if I have used the proper tools directly instead playing with rewriting
- so I said me, I resign, and I will play another time with a 80GB drive instead 2TB
- I done an about 1-2 hours pause, and when I go back pending is at 3!!! offline UNC always at 762
- now slow issue is completely gone, I retry a read and it is not as bad as before for this weak head, at least no new UNC, and not a drop at every head cycles
- Im currently doing a last full read and rewrite on bad part, and it seems the drive will be ready to success an format with the desired VSC "Format Unit"...

So Oungawak, the firsts steps I suggest you for your Green :
- try to success full writting it with Victoria
- if always pending sectors or offline UNC : let the drive plugged for about 24hours, and go open time to time the "VSC status monitor" from WDMarvel (dont let it open, it seems it maybe slow down if opened)
- okay, I stop there the little off-topic about reusing your Green... (open another topic if you want)

My drive dont have any UDMA CRC error count, anyone know an easy way to increment it?
No, I dont want to manually play with SMART modules now
Can I unplug SATA during copy or something others without risking to damage my motherboard or the drive??
At least, I will see if the VSC works by looking if G-List is merged to P.

[Oungawak]

I'm back!

I started a full write on the WD Green with Victoria as you said. At first the disk go full speed without problem, but shortly after it slows down and I get this pattern on the grid:


A slow block at the beginning of each line, and sometimes there is a diagonal going from left to right, like the one on the screenshot. The speed varies between 25 MB/s and 14 MB/s (when a diagonal appears), Victoria's estimation of the remaining time varies between 15 and 27 hours. I will let it finish, but do you think I should still try to test the "Format Unit" on the WD Green or will it take forever?

Also I remembered I bought two WD Green. I will try to find the second one. I think it may be in better shape, considering it didn't caused me enough troubles to remember it.

[diybit]

Ooops, I was wrong... I'm very sorry...
Because it's about that the VSC Format Unit will not work on any WD drives...
My WD Raptor have finally never succeeded this VSC, I have retested on it and it's not working, his SMART was finally full cleared.
Now, I'm little confuse and dont even know/remember if CRC is right reset for Hitachi drives during this VSC Format Unit...

I have incremented my Green CRC error with an little defective cable that I have little move during file copy.

I have tested on my Green to find an easy way to reset the CRC errors but nothing have succeeded :
- HGST_eng.exe
- MHDD script VSC Format Unit
- VSC Secure Erase (working but no reset of the CRC)
- VSC WD Quick Format with P-G List or remerge

I now doubt that your Red will success, you can eventually give a try with HGST_eng.exe, it will normally not brick your drive at all.

So next, you will have to follow the fzabkar instructions to success resetting the CRC, that will not be an easy way, and with the risk of bricking the drive. (not totally lose in case of bricking, but you will normally have to buy WDMarvel to success an PCB hotswap with an identical drive)
Or maybe you can found a way to ignore your NAS warning...

I'm ok to test on my side firstly all the fzabkar steps for we confirm it will not brick, but maybe we cannot be sure 100% that it will give same result with your Red 6TB.
I will try to found a way to full disable the SMART, that will maybe let us direct writing the modules at the same place...

So, it's time to plug your Red, done a right backup like you have done for the Green, and zip it in safe place.
I also suggest you to test the checksum of your modules files with the tool CHKSUM2.EXE that you can found somewhere at HDD Oracle.
Then post here all the modules said by BGman : mod20,21,22,23,24,2D,2E, and mod01

About your Victoria scan, those slow blocks are surely there because you actually suffer the slow issue, but the vertical lines are strange.
Let it finish the background scan, then re full erase it if always pending/offline UNC, then repeat these steps to fall to about 0, mine have success to fall at 0 pending and 1 offline UNC (maybe the one that is the culprit about my drive reboot).
When you will be at about 0, and no background scan running, full read it and show an graph with full scan and one with your first 35GB. (untick Grid to show graph)

[Oungawak]

Hello again,

Sorry for the delays between responses, I don't have as much time as before.

I took the WD Red off the NAS and did all I could with it before putting it back in place.

I haven't found CHKSUM2.EXE on HDD Oracle, so I did a check of all modules with WDMarvel, is it okay this way? I also did a backup of all modules like I did with the WD Green... And the results are much worse than what I had with the WD Green... But the WD Red seems working fine for me, is it WDMarvel that doesn't like the newer WD disks?

Here is the log of the firmware backup:

Error reading module ID2D, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID28, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID3B, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID3C, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID3D, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID3E, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID3F, state - DISK_ECU_UNSAFE_ERROR
Error reading module ID1050, state - FM_ERR_CHECKSUM
Successfully read 564 modules
ROM successfully read
Successfully read 7 modules
New format type drive detected
Restore point created with errors

Here are all the errors I got while reading/checking the modules:


More specifically about modules 20, 21, 22, 23, 24, 2D, 2E and 01 asked by BGman:

As you can see, I don't have modules 20 and 22, module 24 have an invalid CRC and module 2D can't be read by WDMarvel. To further complicate things, I also compared the files between the restore point and the modules I read and there is 2 different versions for module 21...

Do you still want a copy of those modules or do you want the modules with "SMART" in the description? And do you intent to modify them and write them back on the HDD? Because if that's the case I don't think I will be able to do that with the demo version of WDMarvel...

About ignoring SMART warnings, the only thing I found on the Synology NAS is how to disable SMART reporting for the entire NAS, which would be functionally equivalent to disabling SMART. It would be a waste to do that just because of one stupid counter, but if there is no alternative... Frankly I don't know what is worse: A SMART attribute that considers a HDD bad for something completely unrelated to the disk, or Synology that can't put a setting to simply ignore an error...

And for the WD Green, I started a full read but I stopped it because it will take forever to finish. Sometimes there are 'holes' in the readings where suddenly a string of sectors takes so long to read there is a timeout, the WD Green also becomes unresponsive:

Maybe we should let it rest in peace.

[diybit]

Strange those DISK_ECU_UNSAFE_ERROR, I suspect they come from bad sectors... but it's ok if they do not touch critical modules, you can eventually compare with another Red, I have already seen that in some drive refurb by WD.

Does you got the module files 24.mod or not? is it a blank file?
Try reading it also by sector copy 0 instead by ID.
Post here all the different versions you get for 01 21 23 24 2D 2E. (and it's normal that some will continuously be tiny modified)
It's not sure that 2E is really needed, and 2D surely not.

CHKSUM2.exe is here http://www.hddoracle.com/viewtopic.php?f=22&t=80#p93 file check.zip
When you do this check inside WDMarvel, it test modules inside the drive, not your backup files, yes normally they are same, it's just to be sure that your backup is not altered.

About writing the modules, you have access to the hard way with MHDD/HDDSuperTool scripts...
Me, I will try to investigate in the MHDD way, I have about never used those scripts, so I cant securely help you more at creating one.
I bet that fzabkar have an "auto" generator for this, that relies to mod01, so post your modules files and normally he will modify them to only reset CRC or hide it, and prepare your scripts.
Me, I can only help securely at creating the two needed mod01. (I will try reproduce the scripts writing steps on my Green...)

I confirm you that I have success to bypass the RAM problem by doing the fzabkar procedure on my WD20EADS, I used and old SMART of 3hours ago, and yes I'm now 3hours back
It seems not so risky finally, at least not by using MHDD scripts...

Here the exact steps I have done:
1) prepare new mod01, add new dummy mod9921 9922.. with same attributes/size as initial mod21 22.. look for free area and add them with WDMarvel "Dir editor"
2) note the 99xx ABA sector start
3) write 01 and reload it
4) write 99xx by sector copy0/1
5) reboot
6) read by sector 99xx and verify they are identical to the one written
7) modify 01 for 21 22.. to point to new ABA of 99xx modules
reboot (we can spot that new SMART is loaded)
9) write initial 01 and reload it
10) write the new mod21 22.. by sector copy0/1
11) reboot
So writing by sector was the key here, that let me write/read mod without adapted header with a right ID, 21 instead 9921 for example.
All modules I have used are 21 22 23 24 2D 2E.
If you fall on defective sector in SA, you will see it at the step 6 and can go back.
Maybe there are another way without creating dummy mod but I dont know how exactly...

I have not found a way to disable SMART that permit direct rewritten it.
Tested smartctl --smart=off --offlineauto=off --saveauto=off /dev/sda
Also tested by the DCO right internally saved with HDAT2.

I do not hope, but about an eventual bricking, compare the ROM of your others Red to see if you really get an good donor, with a very similar ROM. (start part identical normally if I remember good... you can also see firmware version from S/A Operation > Drive info)

The Green have succeeded, so why not for the Red...
But we have to be careful with this mod24 said "Invalid"... (that maybe is a sign of something changed)
Anyone have some experience in those SMART Red, does it is normal the main SMART is invalid, and why??
Humm have tested an WD20EFRX and it also show mod24 as invalid... but 2E 2D are ok.


About the Green:
What is your actual SMART? Spot the "VSC status monitor" button at the main WDMarvel window, does it is doing "Background Data Lifeguard", reread my previous posts, write wriite all, dont redo read scan while you are not at about 0 pending/offline UNC because you risk creating false positive added to G-List. (mine is now entirely fall at 0 pending/UNC)
And also about those EADS drive, the SMART Reallocation seems not working by showing 0 while some are present in G-List...

[Oungawak]

I'm back.

I attached the requested modules for the WD Red, including the 2 versions of module 21 I got, but not the module 2D because it can't be read at all:

Modules WD Red.zip

Dump of the WD Red with bad SMART UDMA_CRC_Error_Count

(286.96 KiB) Downloaded 769 times

I checked the modules with "CHKSUM2.exe -32 *.MOD" and I got the same results WDMarvel gave me, all modules have a valid checksum except module 24.

I also did the same with the second WD Red of the NAS (this one don't have any SMART warning):

Module WD Red 2.zip

Dump of the second WD Red with no SMART problem

(26.66 KiB) Downloaded 753 times

And inspected it with WDMarvel:

- I got the same DISK_ECU_UNSAFE_ERROR so it may be a normal occurrence after all... Or my NAS will explode soon
- Restore points and module reads produced again 2 versions of module 21, so it's probably also normal
- Module 2E can't be read at all
- WDMarvel says fewer modules are invalid on this one
- Module 24 is seen as valid by WDMarvel, BUT the dump fails in CHKSUM2. Either the dump is bad, or the module is written frequently and the checksum not always updated maybe?

Also I compared the "flash.bin" of both WD Red with WinMerge and they are 99% identical, only a small part differs at the end of the files. The drive info are also very similar, the only differences being: "Area density", "max_fmt_LBAs", "max_HQ_LBAs" and all raw data from "max_LBA_for_head_0" to the end. And even those values seems quite close.

About de WD Green... Well its still "alive" but now he can't even do a full write or read in Victoria, it starts fast then quickly halts and all sector timeout after that. Strangely if I open the VSC Status monitor it performs better, one sector timeout, the next is OK, the next timeout, etc. And the VSC status alternates like that:


Honestly I will soon start building a tiny drakkar for a Viking funeral, because this disk is clearly gone at this point. May he rest in pieces.

[diybit]

fzabkar, the SMART modules of the Red are little changed, there is something strange with the sub modules checksums of the invalid mod24.
I dont know, but maybe all the sub modules checksums have maybe now to be zeroed...

On my WD20EFRX that have similar SMART as Oungawak with same size, I spotted that I get an invalid 24 if I read by ID (with sub-checksums filled), and I get a valid 24 if I read by sector copy0/1 (sub-checksums zeroed).
It seems the only change is all 16bit checksums are zeroed.

Oungawak, maybe repost them by reading them by sector copy0/1 to be sure, confirm your files got valid checksum.
Post also your Green mod 01 21 22 23 24 2D 2E, because we will maybe finally begin by the green to be more safe...

[Oungawak]

Hi!

Here is the dump for the WD Red with sector copy:

WD Red (copy 0-1).zip

(287.61 KiB) Downloaded 807 times

Module 2D still can't be read. All files have a valid checksum including module 24. "copy 0" and "copy 1" produced the same files except for module 21 as usual, the file "21.mod" is done with "copy 0", the file "21 (2).mod" is done with "copy 1".

Here is the dump for the WD Green with sector copy:

WD Green (copy 0-1).zip

(165.92 KiB) Downloaded 749 times

All files have a valid checksum. Again "copy 0" and "copy 1" produced different versions for modules 21, 22 and 2E. Files ending with " (2).mod" are made with "copy 1", the others are made with "copy 0".

[diybit]

About the Green, don't resign! they can be very difficult to kill.
Try resurrect it while we look to find a way to write those modules...

But sadly it seems you maybe really have a bad head, your SMART have now ultra tilted on "Command Time Out" and "Reported Uncorrectable Errors"...

You said "it starts fast then quickly halts", verify that your drive do not reboot at this halt. (hear it)
Are you sure your drive is always detected after this halt, stop scan and try reading SMART.
Try to write this part in PIO mode with Victoria.

Anyway, it seems Background Data Lifeguard has kicked in but seems maybe not moving, progress at 0%.
Stop touching the drive while this is running, try to restart firmware or unplug, look if the background scan run, let it go to 100%, and give it 1-2hours idle bonus, before next full write.

You have to spot if you really get a totally dead head or not.
You maybe get one if you get like repetitive teeth drop UNC at reading or maybe writing too. (like you can read, then UNC for about 200MB, then you can read about 1000MB, then UNC for about 200MB, etc)

I'm doing some tests about SMART modules...

[diybit]

Damn... I'm finally always unable to success customizing SMART raw values...

I have well tried, and no way to just remove my one CRC error...
It seems that those value are hidden somewhere inside 2E, and I do not touch 2E.
Previously, I succeeded because I restored an true old SMART with his 2E.

So have tried to hide the CRC, and this is working!!
Sadly it also need to move the 21 (22) 23 24 modules to be applied...

Now, we need to found a way to write them, and the big problem is that we can't write by ID those 99xx modules, we need the write by sector.
I'm currently trying to digest the MHDD script key to write/read by sector (CHS) for WD ROYL...

Attachments

WD Green CRC hide.zip

(47.28 KiB) Downloaded 724 times

WD Red CRC hide.zip

(46.72 KiB) Downloaded 728 times

[diybit]

Sorry Oungawak, but I do not success writing by sector with MHDD scripts...
It seems I'm not far as my reading by sector is working, but I don't see what thing I can try now... (I also succeeded reading/writing by ID)
Drive is not reporting error but nothing is written, even not written at another place in the current track.

Here my Green example where I try to write mod9921 on head 1:
- SA SPT = 1974
- SA tracks = 192
- ABA mod9921 = 78454
- Size mod9921 = 90

Reading success:

Code:

; Read 90 sectors from module 9921

; VSC super on
reset
waitnbsy
regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy

; VSC buffer
regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = r9921.bin

; VSC read 90 sectors (0x5A)
regs = $d5 $5a $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = r9921.mod

; r9921.bin -- 0C 00 01 00 67FFFFFF 01 00 BD 05BC 0000 00

Writing error:

Code:

; Write 90 sectors at module 9921

; VSC super on
reset
waitnbsy
regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy

; VSC buffer
regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = w9921.bin

; VSC write 90 sectors (0x5A)
regs = $d5 $5a $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = 9921.mod

; w9921.bin -- 0C 00 02 00 67FFFFFF 01 00 BD 05BC 0000 00

Have tried modify without result:
- 0000 that seems can be the sector size to 0100, others size give error.
- the size $5a in the VSC to $00 or $01.
- $d5 to $d6 change nothing (even for success an reading)
- control my track, and my calc is ok, this module is inside track -153. (I'm getting it right at reading)

As you can see, the possibility seems now limited and I have test about everything, so I do not understand why this writing is not working...
Anyone have an idea?

[Oungawak]

I don't have any idea myself sorry.

And I feel nobody else will have an idea until Christmas and New Year have passed. Probably one day after too because of the hungover.

[maximus]

First, D5 reads data and D6 sends data, so you need D6 for your write.

Second, from my own past testing I found that reading by CHS was possible, but writing was not. I don't remember if there was any error or not, just that it didn't work. My testing was done with the drive in kernel mode, as I could never get it to read CHS in normal operation.

[diybit]

I finally succeeded my writing...
Thanks maximus for those definitions about D5 D6!

But I also spotted that the full clear SMART is not locked inside WDMarvel.

So Oungawak, you have now to choose between easily clearing the SMART, or go trying the SMART moving with MHDD scripts.
And I think, clearing it is the most safe way to avoid bricking your Red, because of those strange things we spotted about checksums.

I think it will works even with those checksums glitches, but we cannot be sure 100% without trying. (me I have only try on my Green)
And finally having the SMART cleared is not so a problem. (backup it and store it somewhere)

So your drive, your choice!
Hide CRC or clear SMART!?

[Oungawak]

We are almost there! Thank you so much for your help diybit!

So full clear SMART isn't locked!? Seems like an oversight for a "read-only" demo but cool! (Or they count it only as a 'command'.) Have you tested it? If yes does it resets absolutely all SMART data or only some attributes? I was wondering if resetting everything could cause problems by making SMART think the disk is younger than it really is, but now I'm starting to think I am overthinking it... Do you think such reset would have a any significant effect in the long run?

We are talking about the menu "Other > S.M.A.R.T. > Clear S.M.A.R.T.", right? I suppose I could try it for myself with the WD Green. And about the WD Green: When I tried to start a full write in PIO mode, Victoria complained it can't get a "passport" for the disk... (Brexit strikes again ) For now my patience for saving it has ran out, sorry!

About the MHDD script, could you tell me how it works and what can go wrong? From my understanding you changed some values from my dump and we simply write them back. For me that looks simple enough and only change the minimum data required. But again I'm not an expert in HDD firmware...

[diybit]

Clearing SMART will not impact anything on your drive, except that ALL attributes will be reset. (no effect in the long run)
So the only prob with it is you lose your history, but your Red seems in a very well state and his history is about zero except this 37000 hours.
Your attributes "Reported Uncorrectable Errors > 1" and "Command Time Out > 4" are surely intermittent prob caused when you was getting the UDMA CRC growing. (and nice "Load/Unload Cycle Count" you get)
Yes, the option is the one you said in the "Other" menu. (I tried it on my Green and it have works even with the demo)

The point why I'm little hesitate to apply this CRC hide fix on the Red is because of all those sub modules checksums that are zeroed, that normally are right filled like in the Green. (you can see them BAD in the .txt files)
But as this is what we get when reading by sector, they are surely useless and will be re-computed by the drive.

The steps are not just rewriting modules, but also moving them by rewriting the mod01.
What can go wrong:
- drive do not like the modules I prepared
- you miss right validating/verify a step before going to the next
- incoming power failure

In case of big problem during the validating process, you will have to repair it before your next firmware restart. And we need to not fall to this situation

It can be well helpful if you can exit DOS and reboot to WDMarvel without getting a drive firmware restart, try to hear it at PC boot when you do CTRL+ALT+DEL. (and for the reverse also, from a Windows reboot to go to MHDD)
I will try avoid those risky reboot by verify under MHDD/DOS at least those modules we just write to confirm they were well written, but also doing a full check of all modules will be a good idea...

Anyone know what is the VSC about checksum verify?

So if you choose trying the CRC hide, begin by prepare an USB key with MHDD 4.5
https://hddguru.com/software/2005.10.02-MHDD/

[diybit]

Okay, I was too much alarmist...
We will done some tests firstly to be sure not doing write error.
But anyway it's more safe to choose the clear SMART option...

[Oungawak]

Okay thanks for the info!

Yeah I agree with you, clearing SMART might be the way to go. It's simpler and probably safer with just a few clicks and no module to write/move. I was worried about the consequences of losing previous SMART data, but as you said they don't seems to contains any important warning yet, so it doesn't matter that much. If a problem existed it would still manifest itself after anyway.

I will try this method when I have time, probably this weekend. I will test it on my WD Green first, and if everything is OK, it will be the WD Red's turn.

If everything works well... Well I suppose your time spent to rewrite those modules was for naught. Sorry! I hope it was fun or instructive for you at least. For me I sure learned a lot here.