Disk families affected: Barracuda 7200.11, Barracuda ES.2 (SATA), DiamondMax 22, FreeAgent Desk, Maxtor OneTouch 4, Pipeline HD, Pipeline HD Pro, SV35.3, SV35.4
Barracuda ES.2 SAS drive is not affected All drives with a date of manufacture January 12, 2009 and later are not affected by this issue This condition was introduced by a firmware issue that sets the drive event log to an invalid location causing the drive to become inaccessible. The firmware issue is that the end boundary of the event log circular buffer (320) was set incorrectly. During Event Log initialization, the boundary condition that defines the end of the Event Log is off by one. During power up, if the Event Log counter is at entry 320, or a multiple of (320 + x*256), and if a particular data pattern (dependent on the type of tester used during the drive manufacturing test process) had been present in the reserved-area system tracks when the drive's reserved-area file system was created during manufacturing, firmware will increment the Event Log pointer past the end of the event log data structure. This error is detected and results in an "Assert Failure", which causes the drive to hang as a failsafe measure. When the drive enters failsafe further update s to the counter become impossible and the condition will remain through subsequent power cycles. The problem only arises if a power cycle initialization occurs when the Event Log is at 320 or some multiple of 256 thereafter. ======== Seagate says only on power up, but I'm pretty sure I have seen stories of rebooting causing bricking. Might be unrelated, but to play it safe I will continue to avoid reboots. So, we have confirmation of the number 320, and a formula for event counts past 320. We still need to find out if this "Event Log counter" is the error count reported by smartmontools, or some other counter. Ideally, I would like to find out how to read this "reserved-area system track", and how to set it to a safe value (I have seen zero, but this is not confirmed). If we can do this we don't need to update the firmware. And we still want to find out how to update the firmware from Unix.
