Comme narré dans mon précédent article, je dispose à présent dans le salon d'un petit Brix de Gigabyte (un équivalent du NUC d'Intel) qui me sert principalement de HTPC. Il est relié à un moniteur Full-HD de 22" situé à deux mètre du canapé, donc parfaitement adapté en taille à son usage.
Si les choses n'ont pas été simples au début à cause des problèmes liés au EHCI/xHCI dans le BIOS, ce problème a finalement été résolu.
Restait un second problème très énervant et finalement bien plus grave au vu de l'utilisation de la machine : les freezes aléatoires - mais très réguliers - lors de la lecture de vidéos (crashes complets du système avec image figée sur l'écran).
Sans parler desdits freezes qui obligeaient à rebooter méchamment "au bouton", la lecture était soumise à de régulières coupures du son, saccades du flux des images, ou, la plupart du temps, les deux simultanément. Niveau confort pour une machine dédiée à la vidéo, on a déjà fait mieux.
J'ai tenté une analyse approfondie, en utilisant à peu près les mêmes techniques que pour le problème précédent :
- test de plusieurs lecteurs vidéo : VLC, SMPlayer, Totem, etc., mais même la lecture de vidéos Flash depuis Chromium pouvait planter le PC,
- inspection des logs à la recherche de fautes matérielles : pas la moindre trace de signes avant-coureurs,
- monitoring des capteurs de température : tous dans la normale, à peine une légère élévation des valeurs lors de la lecture de flux HD (normal jusque-là),
- suppression de tous les services d'arrière-plan/daemons inutiles,
- mise à jour vers le kernel du dépôt "testing" d'Arch (pour passer au kernel 4.0 à ce moment-là),
- invocations mystiques sur la ligne de commande du kernel (intel_pstate=disable et ses déclinaisons),
- mise à jour du BIOS,
- j'en passe sûrement...
Rien, absolument rien, n'a donné de résultats satisfaisants. Ce qui est évidemment pernicieux, c'est que les plantages sont aléatoires, donc parfois après un changement, tout semble mieux fonctionner pendant quelques heures... mais c'est juste pour que le retour à la réalité soit plus dur.
Heureusement là encore, après avoir expliqué mon problème sur le forum d'Arch, un membre m'a indiqué un fil de discussion sur FreeDesktop qui parlait justement de problèmes similaires avec un processeur Bay Trail (l'architecture de ce modèle), le driver i915 et un kernel récent. En lisant les échanges, il semblerait effectivement qu'un bug soit apparu dans le noyau à partir de la version 3.17 (octobre 2014) concernant la gestion de l'alimentation du GPU intégré.
Les CPU récents utilisent en effet des systèmes de mise en veille très complexes afin de minimiser leur consommation (et par conséquent, leur dégagement thermique). Ils alternent en permanence entre plusieurs états (les C-states) selon leur activité courante. Un CPU très sollicité va être alimenté en permanence (état C0). En idle à l'inverse, il passera la plupart de son temps sous-alimenté (ex : états C3, C4 et suivants) et ne se "réveillera" que pour accomplir une tâche, avant de se remettre en veille, dès que possible.
Les SoC de la famille Bay Trail disposent apparemment comme leurs cousins desktop depuis Sandy Bridge et Haswell des états C6 et C7 qui correspondent à des veilles très profondes où le CPU est presque entièrement désactivé. Afin que l'alimentation soit gérée de la manière la plus fine possible, le noyau doit savoir utiliser ces états. C'est notamment le rôle des pilotes qui sont inclus au fur et à mesure dans les différentes versions de Linux. Ceci explique notamment pourquoi une mise à jour du noyau peut apporter une augmentation notable de l'autonomie sur des PC portables (ou au contraire, une baisse, ce qui est moins cool). Une mauvaise gestion des C-states, que ce soit par la partie logicielle ou même matérielle peut conduire à des instabilités ou des plantages assez désagréables.
Les C-States sur la présentation de l'architecture Silvermont d'Intel (Bay Trail)
C'est donc en fait ce qui m'arrivait lors de la lecture de mes fameuses vidéos. En l'occurrence il s'agirait d'un problème lié à la fois au mode Turbo et au C-state C6, à cause d'une réduction excessive de l'horloge du CPU. L'utilisation intensive du GPU ne serait en fait qu'une manière "aisée" de produire le bug. J'ai effectivement pu observer des crashes sur ma machine sans lire de vidéos, mais c'était assez rare. Comme sur un SoC le CPU et le GPU sont étroitement liés, il n'est pas trop étonnant d'avoir des effets de bord de l'un affectant l'autre.
Un patch a été soumis sur la branche de développement du driver graphique Intel et devrait logiquement être intégré à la prochaine version du noyau (4.1 à l'heure où j'écris). En attendant, la manière que j'ai choisie pour éviter les plantages, c'est d'utiliser le noyau LTS (Long Terme Support) proposé par Archlinux, soit la version 3.14. Et là, tout marche sans problème depuis plusieurs jours.
Pour faire de même, sous Arch c'est très simple :
# pacman -Sy linux-lts
# grub-mkconfig -o /boot/grub/grub.cfg
Le noyau le plus récent est conservé mais devrait être positionné en deuxième option par GRUB. Il reste donc possible de tester régulièrement si le problème a été corrigé :)