MHDD: "dco integrity checksum error"

[NRA]

Hi there)

A friend of mine brought me Samsung HD321KJ for testing, but there were no visible problems: 16 rellocates and no pendings or other critical errs --pretty fine for made in 2008. Only Mhdd command "config" showed

dco integrity checksum error

I understand that different software may treat and name it differently, yet my question is still the same: what's wrong and how to solve it?

TY

[fzabkar]

I don't think anything is wrong. Some firmware doesn't bother checksumming the DCO Identify info block, or the Identify Device info block.

If you have MHDD ver 4.5, place the following code in a script file (eg DCOIDENT) in the SCRIPTS subdirectory and execute it as ".DCOIDENT". I haven't tested the code, but I believe you should end up with a 512-byte file. I can't recall if there is an MHDD command that retrieves the same info.

Code:

; ATA DCO Identify (B1h / C0h)

reset
waitnbsy
regs = $c0 $00 $00 $00 $00 $a0 $b1
waitnbsy
sectorsto = dcoident.bin

IIRC, the integrity byte is the lower byte of the last word. Normally the whole block should checksum to 0x00 (8-bit).

[NRA]

Thank you, fzabkar.

So, neither HDD, nor software cares for DCO (and HPA?), right?
It makes sense, as far as there were no evident err messages.
But if something is altered improperly (not updating the checksum), then there must be something wrong.
However, there's still that random coincidence factor to consider.

How do you think, should one reset/update the DCO values or even bigger issuer could arrive then?
TY

[Spildit]

I don't think anything is wrong. Some firmware doesn't bother checksumming the DCO Identify info block, or the Identify Device info block.

If you have MHDD ver 4.5, place the following code in a script file (eg DCOIDENT) in the SCRIPTS subdirectory and execute it as ".DCOIDENT". I haven't tested the code, but I believe you should end up with a 512-byte file. I can't recall if there is an MHDD command that retrieves the same info.

Code:

; ATA DCO Identify (B1h / C0h)

reset
waitnbsy
regs = $c0 $00 $00 $00 $00 $a0 $b1
waitnbsy
sectorsto = dcoident.bin

IIRC, the integrity byte is the lower byte of the last word. Normally the whole block should checksum to 0x00 (8-bit).

I've just tested this on my IBM-Hitachi 3.5 drive (AVV2) and it didn't produce any data on the buffer.

1.png (14.72 KiB) Viewed 7263 times

On my case there is no data transference request at all but the drive reply with some register status as shown on the images.

[fzabkar]

So, neither HDD, nor software cares for DCO (and HPA?), right?
It makes sense, as far as there were no evident err messages.
But if something is altered improperly (not updating the checksum), then there must be something wrong.
However, there's still that random coincidence factor to consider.

How do you think, should one reset/update the DCO values or even bigger issuer could arrive then?
TY

The Device Configuration Overlay is explained very well by Wikipedia:
http://en.wikipedia.org/wiki/Device_con ... on_overlay

The only reason you would want to edit the DCO is if you wish to enable or disable the reporting of the existence of certain feature sets. However, this does not give you access to the checksum/integrity byte, AFAICT. That is under the control of the drive's firmware. You could try disabling a particular feature and then enabling it again. Maybe this will force the firmware to recalculate the checksum.

[fzabkar]

I've just tested this on my IBM-Hitachi 3.5 drive (AVV2) and it didn't produce any data on the buffer.

On my case there is no data transference request at all but the drive reply with some register status as shown on the images.

Maybe the command isn't supported.

This document (Sept 2000) is the initial proposal for the DCO feature set:

http://t13.org/Documents/UploadedDocume ... 0140r1.pdf

AIUI, DCO is now obsolete.

[fzabkar]

Here is an example of an ATAPI Identify Device output from an LG DVD burner. It also has zeros for the checksum byte. There is nothing wrong with the drive.

Code:

*******************************************************************************
HDAT2 v4.7.1 (c) 2009 CBL  02.05.2015 05:50:35.064
*******************************************************************************
Device Information [HL-DT-ST DVDRAM GSA-4040B]
*******************************************************************************
Device model [ATA/PATAPI]                           HL-DT-ST DVDRAM GSA-4040B
Manufacturer                                        unknown
Detect mode                                         PCI
ATA I/O port Base/Control/IRQ                       01F0h/03F6h/14
-------------------------------------------------------------------------------
ATA/ATAPI Identify Device
-------------------------------------------------------------------------------
Integrity word (optional)
   -> Signature: BAD [reported 00h, should be A5h]
   -> Checksum : BAD [reported 00h, should be 90h]

[NRA]

Thank you, guys.

Hmm, so the SMART is clean, the SATA cable is ok, the surface is ok, and the DCO integrity fault is not really an issue for possible HDD slowdowns. As far as I reformatted and repartitioned the HDD several times and tried XP/W7/Slax, what else it might be?

I'm still reluctant about resetting the DCO and my friend said that a company officer who installed corporate OS also told her something about alignment, so I'm still in a doubt. Is any of it really possible to make the HDD stumble or should I check something else?

TY