BIOS claims imminent failure but drive seems fine

[maximus]

Drive: WDC WD1001FAES-60Z2A0
The BIOS claims hard drive failure is imminent. I made a perfect image using ddrescue with no errors. A scan with MHDD showed no issues. To me the smart data does not show any media errors. Smart data from HDDSuperTool is below, and screenshots of BIOS message, MHDD smart data, and MHDD scan are attached. I need an opinion on what is going on here. Is there something in the smart data that indicates failure? Or is it possible that the BIOS on this computer is corrupt?

Code:

Smart structure version= 16
ID# FLAG   VALUE  WORST THRESH  DATA         ATTRUBITE NAME
1   0x2f    200    200    0     0x0 0x0     Read Error Rate
3   0x27    175    172    0     0x1091 0x0     Spin-Up Time
4   0x32    99    99    0     0x43a 0x0     Start/Stop Count
5   0x33    200    200    0     0x0 0x0     Reallocated Sectors Count
7   0x2f    200    200    0     0x0 0x0     Seek Error Rate
9   0x32    63    63    0     0x6aca 0x0     Power-On Hours Count
10   0x33    100    100    0     0x0 0x0     Spin Retry Count
11   0x32    100    100    0     0x0 0x0     Calibration Retries
12   0x32    100    100    0     0x37f 0x0     Power Cycle Count
184   0x33    97    97    0     0x3 0x0     End-to-End error
187   0x32    100    100    0     0x0 0x0     Reported Uncorrectable Errors
188   0x32    100    97    0     0x2c 0x0     Command Timeout
190   0x22    68    59    0     0x201f0020 0x0     Temperature
192   0x32    200    200    0     0x28 0x0     Power-Off Retract Cycles
193   0x32    200    200    0     0x411 0x0     Load/Unload Cycles
196   0x32    200    200    0     0x0 0x0     Reallocation Events
197   0x32    200    200    0     0x0 0x0     Current Pending Sectors
198   0x30    200    200    0     0x0 0x0     Off-line Uncorrectable
199   0x32    200    200    0     0x0 0x0     UDMA CRC Error Rate
200   0x8    200    200    0     0x0 0x0     Write Error Rate

Attachments

mhdd_scan.jpg (82.6 KiB) Viewed 8239 times

mhdd_smart.jpg (89.19 KiB) Viewed 8239 times

bios_message.jpg (82.54 KiB) Viewed 8239 times

[data-medics]

It doesn't look bad from what I'm seeing there, but I don't think all the S.M.A.R.T. parameters are being displayed there either. Maybe try checking it with Crystal Disk Info it might shed some more light on why it's giving the error.

[maximus]

It doesn't look bad from what I'm seeing there, but I don't think all the S.M.A.R.T. parameters are being displayed there either. Maybe try checking it with Crystal Disk Info it might shed some more light on why it's giving the error.

I HATE having to plug a drive into Windows. But since this is already recovered 100% and just needs to be assessed, I did it. Screenshot from CrystalDiskInfo attached. As you can see, it reports as good.

Attachments

[fzabkar]

BIOS is complaining because the End-To-End Error attribute has hit the threshold value of 97, as reported by CDI. However, the Super Tool has a bug in displaying these same SMART thresholds. Also the software is displaying two raw values instead of one, and "attribute" is incorrectly spelt as "attrubite".

[maximus]

BIOS is complaining because the End-To-End Error attribute has hit the threshold value of 97, as reported by CDI.

If I am reading it right, there have been 3 End-To-End Errors and 44 Command Timeouts. I have looked up the End-To-End Error and also the Command Timeout, and between the two I am unsure if the issue is the drive, or some other physical hardware issue. The computer's owner mentioned that the issue seemed to happen after a lightning storm. Knowing this, would it be a good recommendation for them to buy a whole new computer?

However, the Super Tool has a bug in displaying these same SMART thresholds. Also the software is displaying two raw values instead of one, and "attribute" is incorrectly spelt as "attrubite".

Spelling error will be fixed in next release (I sometimes have dyslexic fingers when typing).

The thresholds are exactly what data the drive provides. It would seem that on most newer drives that data is always 0. Other tools like CDI are getting the threshold value from some sort of list. Find me that list and I will put it in HDDSuperTool.

The second raw value is actually the high order 2 bytes, which is often not used and is not included in MHDD output. I don't have the link, but I did this because I read that the normal raw value was 4 bytes, and the other 2 bytes were optionally used. At first I had it as one value, but didn't like how it displayed sometimes. In reading up on the above errors, I came across information that the data is often 3 words (0x0000 0x0000 0x0000). My biggest problem is that I don't have a way to display leading 0's in the scripting, so it would end up 0x0 0x0 0x0. Actually I just now thought of a possible way to display leading 0's as I was typing this. If it works, would it be better to have the full raw value as all one number like CDI (0x000000000000)? I think I will work on doing it that way and see how it turns out.

[maximus]

The thresholds are exactly what data the drive provides. It would seem that on most newer drives that data is always 0. Other tools like CDI are getting the threshold value from some sort of list. Find me that list and I will put it in HDDSuperTool.

After some more looking into this, I have found that it would appear that there is a second method to get the threshold values- SMART READ ATTRIBUTE THRESHOLDS D1h. That doesn't seem to be in any of my ATA documentation. The only place I have found this info so far is in specific hard drive specification data sheets. I will work on adding this into the smartdata script. The information I had previously (which I still can't find again) listed the last byte in the smart attribute entry as the threshold value, which I thought I had a drive that did provide threshold information in that field.

Smart Attribute Data Structure:
byte 1 = ID
byte 2-3 = flags
byte 4 = current value
byte 5 = worst value
bytes 6-11 = raw value
byte 12 = threshold (this seems to be wrong)

Device Attribute Thresholds Data Structure:
byte 1 = ID
byte 2 = threshold
bytes 3-12 = reserved

[maximus]

FYI
New output from HDDSuperTool below. This will be available in the next release.

Code:

Smart structure version= 16
ID#   FLAG  VALUE WORST THRESH   RAW DATA        ATTRIBUTE NAME
  1  0x002f  200  200     51   0x000000000000   Read Error Rate
  3  0x0027  175  172     21   0x000000001089   Spin-Up Time
  4  0x0032   99   99      0   0x00000000043c   Start/Stop Count
  5  0x0033  200  200    140   0x000000000000   Reallocated Sectors Count
  7  0x002f  200  200     51   0x000000000000   Seek Error Rate
  9  0x0032   63   63      0   0x000000006aca   Power-On Hours Count
10  0x0033  100  100     51   0x000000000000   Spin Retry Count
11  0x0032  100  100      0   0x000000000000   Calibration Retries
12  0x0032  100  100      0   0x000000000381   Power Cycle Count
184  0x0033   97   97     97   0x000000000003   End-to-End error
187  0x0032  100  100      0   0x000000000000   Reported Uncorrectable Errors
188  0x0032  100   97      0   0x00000000002c   Command Timeout
190  0x0022   75   59     40   0x000019190019   Temperature
192  0x0032  200  200      0   0x000000000029   Power-Off Retract Cycles
193  0x0032  200  200      0   0x000000000412   Load/Unload Cycles
196  0x0032  200  200      0   0x000000000000   Reallocation Events
197  0x0032  200  200      0   0x000000000000   Current Pending Sectors
198  0x0030  200  200      0   0x000000000000   Off-line Uncorrectable
199  0x0032  200  200      0   0x000000000000   UDMA CRC Error Rate
200  0x0008  200  200      0   0x000000000000   Write Error Rate


Edit: The real output is completely aligned. This code box did some adjustments of its own and slightly broke the alignment.

[maximus]

If I am reading it right, there have been 3 End-To-End Errors and 44 Command Timeouts. I have looked up the End-To-End Error and also the Command Timeout, and between the two I am unsure if the issue is the drive, or some other physical hardware issue. The computer's owner mentioned that the issue seemed to happen after a lightning storm. Knowing this, would it be a good recommendation for them to buy a whole new computer?

To get back away from the scripting issues, this is still my main concern. At this point in time I am thinking that the response to the owner will be that while replacing the hard drive will clear the error message, it may or may not solve the overall problem. The drive has reported communication issues between itself and the computer, and while it may likely be the fault of the drive, it could also be an issue with the computer itself. I cannot be sure that replacing the hard drive will solve the problem. Due to the nature of the issue and the possible cause (power surge from lightning), I would recommend replacing the whole computer.

If anyone thinks this is incorrect, please respond with the reason why.

[chinopk]

If I am reading it right, there have been 3 End-To-End Errors and 44 Command Timeouts. I have looked up the End-To-End Error and also the Command Timeout, and between the two I am unsure if the issue is the drive, or some other physical hardware issue. The computer's owner mentioned that the issue seemed to happen after a lightning storm. Knowing this, would it be a good recommendation for them to buy a whole new computer?

To get back away from the scripting issues, this is still my main concern. At this point in time I am thinking that the response to the owner will be that while replacing the hard drive will clear the error message, it may or may not solve the overall problem. The drive has reported communication issues between itself and the computer, and while it may likely be the fault of the drive, it could also be an issue with the computer itself. I cannot be sure that replacing the hard drive will solve the problem. Due to the nature of the issue and the possible cause (power surge from lightning), I would recommend replacing the whole computer.

If anyone thinks this is incorrect, please respond with the reason why.

you can rule out whether or not the problem is with computer hardware.
first take s.m.a.r.t from a different computer of any hard drive then take s.m.a.r.t from the suspected computer and compare it against End-to-End Errors and Command Timeout, just a though

[fzabkar]

The SMART READ ATTRIBUTE THRESHOLDS command (B0h/D1h) was present in ATA-3 but has been obsoleted in recent versions of the standard. However, it appears that HDD manufacturers have opted to retain support for this command in current firmware, probably because of all the software that would be broken if they were to drop it.

As for the raw attribute values, I believe that the full 56 bits are available for storing these data. In fact ISTR that some Seagate firmware actually uses the uppermost 8 bits (48 - 55) for storing the seconds count for Head Flying Hours or Power-On-Hours. Furthermore, there is no standard that governs whether the raw data are presented as bytes, words, or dwords. For example, Seagate's Seek Error Rate attribute stores the lifetime seek count in the lowest 32 bits and the seek error count in the upper 16 (or 24) bits. BTW, HDDScan reports 56 bits for the raw value, although it hyphenates the lower 16 bits, presumably because the author believes (erroneously) that these have some universal significance. Some authors also "interpret" the attributes without displaying the raw data, with the result that they sometimes get it wrong. IMHO, reporting all 56 bits as a single hexadecimal number, without adding your own interpretations, would be preferable.

I can't answer your question in respect of the End-To-End Errors, except to say that these should be detectable AND correctable, with the affected data being retransmitted. That said, the threshold is set very high, so this would suggest that only 3 such errors are acceptable during the life of the drive.

As for the 12th byte storing the attribute threshold, I haven't seen this, but I have always thought that it, or the leading, apparently unused (?) flag byte, would have been the most logical place for it.

One more thought that occurred to me in the past was whether any HDD manufacturers utilise the reserved area within the thresholds data block. Perhaps they could use it to "park" attribute information prior to calculating their normalised values.