On Fri, 5 Mar 2004 12:38:59 -0700, Pat LaVarre <[EMAIL PROTECTED]> wrote:
This message is from the T13 list server.
> Date: February 22, 2004 8:32:31 AM MST
Did this thread end?
Can any of us easily nutshell what kinds of stuck hi/ stuck lo/ cut to float corruption of the op xEC/A1 Identify data we will actually overcome by implementing checksums as specified?
At present, AFAICT most stuck hi / stuck lo corruption will probably knock out checksums because unless you're lucky and happen to set the 'checksum valid' bit and you have a checksum. The checksum therefore only works to check that the data provided internally within the device is correct; it doesn't check for a hardware error or failure further along the line, which it probably should do.
What I /think/ we should be doing is using one of the reserved bits from the data blocks to indicate that a checksum is present. That way, the failure point is only if the registers don't accept data correctly, which would obviously be catastrophic and would be picked up by the driver as the register outputs would not match those expected.
My proposal is that we then use the final word in the block - ie. word 255 in ALL cases, to represent the checksum. CRC checking could probably be improved too, although I'm no expert in CRC algorhythms. I would recommend we seek advice from people on CRCs prior to implementation. I'd also recommend we deprecate the current implementation of checksums from ATA-7 in preference to an improved implementation, as its use is extremely limited.
Would anyone comment on this? Does this sound sensible? Are there any foreseeable problems with this approach? I'm aware that the register flags are valuable, but from my experience I suggest that checking the consistency of this data is actually very valuable.
Best wishes,
Drew
