Customer reported this problem and we thought we would post the solution here to help other users.
Symptoms:
While running BurnInTest v8.1 1024 we are seeing HDD temperature spikes on most 2.5" Seagate HDD but we have seen it mainly on the ST500LM021.
The temp spikes from the Seagate drives are exactly 100C.
We suspect the drive might be failing to respond to the SMART data temperature query some of the time, or responding with nulls. The value returned via SMART are likely not a direct temperature reading, but an offset from 100C. So a zero value upon a failed request might look like 100C.
In the past similar problems were seen with Intel SSDs where the SATA SMART commands failed if the drive was under load.
Solution:
The problem was only observed to happen when rapid temperature sampling was taking place. Typically 1 sample per second could cause a problem.
Reducing the sampling frequency to 5 seconds or 10 seconds in the BurnInTest preferences window works around the problem. Very likely there is an underlying bug in the hard disk device drivers however. For this reason we have the default sampling period 10 sec. In V9 of BurnInTest we are also going to limit the fastest sampling rate to 5 sec. (Does anyone really need 1 sample per second? Let's hope not)
Symptoms:
While running BurnInTest v8.1 1024 we are seeing HDD temperature spikes on most 2.5" Seagate HDD but we have seen it mainly on the ST500LM021.
The temp spikes from the Seagate drives are exactly 100C.
We suspect the drive might be failing to respond to the SMART data temperature query some of the time, or responding with nulls. The value returned via SMART are likely not a direct temperature reading, but an offset from 100C. So a zero value upon a failed request might look like 100C.
In the past similar problems were seen with Intel SSDs where the SATA SMART commands failed if the drive was under load.
Solution:
The problem was only observed to happen when rapid temperature sampling was taking place. Typically 1 sample per second could cause a problem.
Reducing the sampling frequency to 5 seconds or 10 seconds in the BurnInTest preferences window works around the problem. Very likely there is an underlying bug in the hard disk device drivers however. For this reason we have the default sampling period 10 sec. In V9 of BurnInTest we are also going to limit the fastest sampling rate to 5 sec. (Does anyone really need 1 sample per second? Let's hope not)