Asus GTX780 ROG Poseidon : Réparation du système de refroidissement

Commercialisée par ASUS début 2014, la GTX780 ROG Poseidon est une carte graphique haut de gamme, dotée de 3 Go de VRAM, et d'un système de refroidissement hybride : celui-ci est en effet composé d'un large dissipateur, épaulé par 3 caloducs, et refroidit par 2 ventilateurs, mais intègre également un (court) circuit eau, permettant un refroidissement par watercooling.

Ce système de refroidissement est également muni d'un logo "Republic Of Gamer" rouge clignotant, jouant sans aucun doute un rôle extrêmement important dans le fonctionnement de la carte, tel que changer un PC en discothèque, ou pire encore ...

Et c'est justement ce système de refroidissement qui m'a donnée du fil à retordre, puisqu'un beau jour, les ventilateurs ont tout bonnement cessé de fonctionner. Si cela ne pose aucun problème visible en utilisation bureautique de la carte (la fréquence ainsi que la tension d'alimentation du GPU étant fortement réduites dans ce type d'utilisation, la faible dissipation thermique qui en résulte permet de maintenir le GPU dans une plage de température acceptable, même sans aucun ventilateur en fonction), lors d'une utilisation pour du rendu 3D (principalement en jeu), c'est une toute autre histoire, la température du GPU augmentant rapidement de manière alarmante, jusqu'à son arrêt pur et simple, provoquant une perte de l'affichage jusqu'au redémarrage de la machine.

J'ai donc entrepris d'en réparer le système de refroidissement ...

Les 2 ventilateurs ne démarrant pas, mais tournant cependant librement sur leur axe, ma première hypothèse fut que le contrôleur des ventilateurs, intégré à la carte, avait cessé de fonctionner. Pour vérifier cela, rien de plus simple, il suffit de démonter les ventilateurs, et de les tester indépendamment. Séparer les les ventilateurs du dissipateur n'est pas une mince affaire, et implique de se battre contre plusieurs clips plastiques, visibles après coup sur la photo ci dessous :

Les ventilateurs sont alors testés séparément, à l'aide d'une alimentation de laboratoire, réglée pour fournir 12V (1A max) via le connecteur 5 points qui les relie normalement à la carte graphique, et ...

Comment ça, rien ?? Enfin, pas exactement rien, l'alimentation de labo indique 0V, 1A, c'est un court circuit franc ! Fichtre, un des ventilateurs est sans doute décédé ...

Avant d'aller plus loin, observons le câblage des dits ventilateurs : comme écrit précédemment, ceux-ci sont raccordés à la carte graphique par le biais d'un connecteur 5 points, véhiculant les signaux suivants : Masse, +12V, commande PWM pour la vitesse, ainsi que 2 signaux de retour indiquant la vitesse effective de chaque ventilateur. De ce connecteur partent 2 séries de fils : l'une va sur un ventilateur, tandis que l'autre dessert un second connecteur, d'où partent également 2 séries de fils : l'une desservant le second ventilateur, et l'autre alimentant le logo ROG clignotant.

Et si ... ?

Essayons à nouveau avec le fameux logo ROG débranché :

Cette fois, les ventilateurs s'animent ! Plus de court circuit, qui provenait donc du logo clignotant.

En le démontant, on découvre un PCB relativement simple, comportant quelques leds, un jeu d'AOP LM324, ainsi que quelques composants génériques, rien de bien folichon :

Je n'ai pas pris le temps d'autopsier ce module, peu importe, son fonctionnement était agaçant de toute façon...

Ses ventilateurs réinstallés, la carte prend place dans mon PC, et c'est l'instant fatidique : démarrage !

Et les ventilateurs ne tournent toujours pas...

Ce qui, après réflexion, semble assez logique : un court circuit aussi franc que celui qui a eu lieu ici sur l'alimentation des ventilateurs à forcément endommagé le circuit d'alimentation des ventilateurs. Sans doute trouvera-t-on une piste brulée, ou un shunt grillé sur le PCB de la carte.

Cette recherche nécessite de séparer le système refroidissement du PCB de la carte, opération que j'avais jusqu'alors soigneusement évitée, étant précédemment en pénurie de pâte thermique, indispensable lors du ré-assemblage pour remplacer la pâte thermique d'origine, qui ne survit pas au démontage.

Une fois le PCB entièrement accessible, on s’intéresse aux pistes menant au connecteur 5 pins qui alimente les ventilateurs. Et il ne faut pas longtemps pour identifier un coupable potentiel :

A proximité du connecteur, raccordé à la broche délivrant le +12V au système de refroidissement, une résistance marquée 0 (ayant donc un rôle de shunt ou de fusible) porte des traces de dommages. Elle est immédiatement remplacée :

Une fois la résistance remplacée, la carte est réassemblée, le GPU recouvert de pâte thermique Artic Silver MX2, et reprend place dans mon PC.

Démarrage, et les ventilateurs s'animent enfin !

Windows se lance sans problème, mais surtout, la carte reste en fonctionnement lors d'applications 3D, avec des températures honorables de l'ordre de 70 °C !

Bref, une franche réussite. Il est cependant dommage que cette panne soit causé par un élément aussi insignifiant (et inutile) que le logo clignotant ! Il aurait été sage de la part d'ASUS de lui fournir son propre rail 12V, ou encore plus simplement, de le doter de son propre fusible, afin que sa défaillance n'interfère pas avec le fonctionnement du système de refroidissement !

Un minitel comme terminal linux USB. Partie 3 : Et avec systemd ?

Il y a 2 ans déjà, je publiais 2 articles décrivant comme réutiliser un Minitel comme terminal linux USB :

• Un minitel comme terminal linux USB. Partie 1 : Hardware
• Un minitel comme terminal linux USB. Partie 2 : Software Raspberry Pi

Cependant, si le premier article est toujours aussi pertinent, avec la migration des distributions Linux vers systemd, le nouveau gestionnaire de démarrage, le second article ne permet plus de configurer les Linux moderne pour utiliser le Minitel comme terminal.

Cet article vise donc à décrire la procédure nécessaire pour réaliser cette opération avec systemd sur Raspberry Pi sous la distribution Raspbian, mais cette procédure devrait s'appliquer, éventuellement avec des modifications mineures, à tout autre matériel exécutant une distribution Linux dotée de systemd.

Tout d'abord, systemd n'utilise plus le fichier innitab et les scripts de démarrages, mais raisonne en terme de services, chaque service étant décrit par un fichier contenant la commande à exécuter, des diverses informations, telles que les dépendances du services.

Un service en particulier est dédié à la gestion des terminaux série : serial-getty@.service

Cependant, il ne comporte pas les bonnes options de configurations pour dialoguer avec un Minitel, nous allons donc créer notre propre service, adapté à cet effet. :

Commençons par créer une copie du service, qu'on modifie ensuite :

sudo cp /lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty-minitel@.service
sudo nano /etc/systemd/system/serial-getty-minitel@.service

Les modifications apportées au fichier concernent la ligne de commande exécutée (getty avec les options adéquats, à la place de agetty), et la suppression de l'attente de plymouth pour démarrer ( en gras ci-dessous)

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/getty -L -i -I "\033\143" %i 4800 minitel1b-80
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

Ensuite, il ne reste plus qu'à ajouter un lien sur ce fichier dans le répertoire getty.target.wants. Ce lien comporte une indication sur le périphérique concerné (ici ttyUSB0). systemd remplacera toutes les occurrences de %i dans le fichier serial-getty-minitel@.service par cette valeur.

sudo ln -s /etc/systemd/system/serial-getty-minitel@.service /etc/systemd/system/getty.target.wants/serial-getty-minitel@ttyUSB0.service

On redémarre le processus de systemd :

sudo systemctl daemon-reload

Puis on lance manuellement notre service (ou on redémarre le raspberry)

sudo systemctl start serial-getty-minitel@ttyUSB0.service

Et voilà, on retrouve le même fonctionnement obtenu précédemment en modifiant le fichier inittab

 

 

Pour plus d'info sur l'utilisation du minitel comme terminal sous Linux, voir les parties précédentes :

• Un minitel comme terminal linux USB. Partie 1 : Hardware
• Un minitel comme terminal linux USB. Partie 2 : Software Raspberry Pi

Source  : doc serial-getty@.service