mardi 15 octobre 2013

SSD m4 de Crucial : le bug de l'obsolescence programmée

J'ai la chance d'avoir un SSD dans mon ordinateur de travail, ce qui permet de gagner énormément de temps par rapport à un disque dur. Ça c'est pour la théorie, car j'ai perdu des heures la semaine dernière sur un bug assez curieux. Les symptômes étaient assez simples : le système perdait le contact avec le disque, rendant l'ordinateur totalement inutilisable et forçant un redémarrage électrique.

J'ai d'abord cru à un problème matériel, la connexion entre le disque et la carte mère n'étant pas très solide sur mon ordinateur portable. Un faux contact est vite arrivé (et s'était déjà produit), et j'ai ouvert et nettoyé tout ça. Sans changement. J'étais d'autant plus circonspect qu'un démarrage se déroulait toujours parfaitement bien, alors qu'un faux contact devrait se manifester dans toutes les situations.

J'ai donc ensuite songé à un problème logiciel, en constatant au passage que mon ordinateur plantait après 3600 secondes d'utilisation environ, soit une heure. Mais revenir sur un ancien noyau ne changeait rien, hormis que le système plantait encore plus violemment. Rien du côté de l'historique SMART, rien de clair dans les logs systèmes, aucun programme qui se lance une heure après le démarrage. J'ai testé beaucoup de choses.

Cette piste logicielle était pourtant la bonne, mais à un niveau en-dessous. Les SSD de Crucial sont en effet victimes d'un bug des 5184 heures. Il n'est pas précisé pourquoi 5184 heures (c'est 3 au cube multiplié par 2 puissance 6). Il est bien entendu impossible de savoir s'il s'agit de réelle incompétence, ou d'une volonté d'obsolescence programmée. Après tout, qui parmi le grand public va penser à aller chercher sur le site du constructeur les correctifs ? D'autant plus qu'aucun historique des versions n'est disponible, et que le site actuel du fabricant ne mentionne absolument pas ce bug ? Il faut fouiller les forums obscurs pour reconstruire l'historique des versions, et trouver l'annonce de la mise à jour 0309 (version qui suit la 0009, et précède la version 000F, histoire vraie...). Après avoir trouvé ça, il faut suivre la procédure de mise à jour qui est bien entendu surtout prévue pour un système WIndows. Quelle est donc la proportion de mise à jour par rapport au nombre de SSD vendus ?

C'est typique pour moi du risque de l'ajout d'intelligence dans les composants matériels. On se met à la merci du constructeur, qui fait ce qu'il veut dans son coin, avec du code complètement obscur. En allant chercher les annonces de chaque nouvelle version, c'est édifiant de voir des améliorations de performances et des corrections de bugs, pour un matériel qui lui ne change évidemment pas. Le genre de lignes d'historique que j'aimerai voir dans une nouvelle version du noyau Linux, pas sur le forum d'un fabricant de matériel. Jugez-vous même :

0309

  • Correct a condition where an incorrect response to a SMART counter will cause the m4 drive to become unresponsive after 5184 hours of Power-on time. The drive will recover after a power cycle, however, this failure will repeat once per hour after reaching this point. The condition will allow the end user to successfully update firmware, and poses no risk to user or system data stored on the drive.

000F

  • Improved compatibility with certain SAS expanders and peripheral RAID cards.
  • Improved throughput stability under extremely heavy workloads.
  • Improved data protection in the event of unexpected, asynchronous power loss.

010G

  • Improved Trim response time
  • Improved power-on-to-ready time (known as POR, or TTR for Time-to-ready)
  • Improved resume-time from low power modes, and improved reliability of warm reboot
  • Improved power consumption by disabling HIPM (Host Initiated Power Management)

040H

  • Improved robustness in the event of an unexpected power loss. Significantly reduces the incidence of long reboot times after an unexpected power loss.
  • Corrected minor status reporting error during SMART Drive Self Test execution (does not affect SMART attribute data).
  • Streamlined firmware update command for smoother operation in Windows 8.
  • Improved wear leveling algorithms to improve data throughput when foreground wear leveling is required.

070H

  • Resolved a power-up timing issue that could result in a drive hang, resulting in an inability to communicate with the host computer. The hang condition would typically occur during power-up or resume from Sleep or Hibernate. Most often, a new power cycle will clear the condition and allow normal operations to continue. The failure mode has only been observed in factory test. The failure mode is believed to have been contained to the factory. This fix is being implemented for all new builds, for all form factors, as a precautionary measure. The fix may be implemented in the field, as desired, to prevent occurrence of this boot-time failure. To date, no known field returns have been shown to be related to this issue. A failure of this type would typically be recoverable by a system reset.