[Bug 194522] smartmontools misbehaving (self-test timestamps do not match reality)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Nov 27 22:57:04 UTC 2014


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194522

Jeremy Chadwick <jdc at koitsu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
         Resolution|---                         |Overcome By Events

--- Comment #4 from Jeremy Chadwick <jdc at koitsu.org> ---
Okay, strike that.  It appears I was witnessing two separate issues
simultaneously, which sounds crazy but seems to be the case after some further
analysis.

The first issue related to SMART attributes and self-test log entries affecting
all drives in the system (Samsung SSD and several WD MHDD drives).  That issue
was rectified by power-cycling the system.  This seems to imply the AHCI
controller was experiencing some oddity/bug/quirk brought on by who-knows-what.
 After power-cycling, everything seemed fine -- except for the Samsung SSD. 
Which leads me to:

The second issue relates to the Samsung drive and SMART attribute 9 vs. what
the "LifeTime(hours)" field shows in a SMART self-test log entry.  And I
believe I've figured out what's going on there[1]:

I recently updated my Samsung 840 EVO's firmware to fix a performance-related
bug[2][3][4] that Samsung and many review sites found.  It appears that after
doing the firmware update, SMART attributes did not get reset back to
zero/factory defaults, but "internal counters" used for calculating the
power-on hour count within self-tests **did** get reset to 0.  So there's now a
permanent delta between SMART attribute 9 and the hour shown in a self-test log
entry because of this mistake on Samsung's part.

[1]: http://www.dslreports.com/forum/r29694516-
[2]:
http://www.computerworld.com/article/2836082/samsung-delivers-fix-for-ssd-slowdowns.html
[3]:
http://www.anandtech.com/show/8617/samsung-releases-firmware-update-to-fix-the-ssd-840-evo-read-performance-bug
[4]: http://beta.slashdot.org/story/208795

So, we can close this out.  There's nothing I can do about this newly-induced
quirk in the Samsung firmware, and it obviously has nothing to do with FreeBSD.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list