Existe-t-il un moyen simple et sûr de déclencher un verrouillage GPU sur un ordinateur sensible?

8

Les réponses à ma question précédente, Ubuntu 12.04 a gelé, nécessitant un cycle de puissance. Que dois-je rechercher / grep dans les journaux? , m'ont amené à soupçonner que mon ordinateur connaît un blocage intermittent du GPU. Cela se produit environ une fois par semaine, généralement lorsque j'utilise Chrome. Aujourd'hui, c'est arrivé quand je créais un diagramme sur lucidchart

J'ai un Dell Optiplex 755 avec une ATI Radeon HD 2400 XT et deux moniteurs fonctionnant en mode Xinerama. J'utilise 12.04 avec le pilote ATI propriétaire installé.

Lorsque l'ordinateur se bloque, je peux toujours ssh. Et je voudrais suivre les instructions pour signaler cela fournies à https://wiki.ubuntu.com/X/Troubleshooting/Freeze

Existe-t-il un moyen (sûr) de provoquer un blocage du GPU afin que je puisse aller de l'avant et déposer un bogue, plutôt que d'attendre qu'il se reproduise?

Abe
la source

Réponses:

11

Excellente question.

Charges de travail

Le répertoire / usr / share / xdiagnose / workloads contient un ensemble de charges de travail conçues pour exercer votre système graphique pour déclencher des blocages.

$ ls /usr/share/xdiagnose/workloads/
README                       do_monitor_rotation_loop
do_chws_loop*                do_screensaver_loop*
do_cpu_spin_loop             do_video_loop*
do_disk_write_loop           do_vtswitch_loop*
do_glx_loop*                 repro.sh
do_kernel_compile_loop       run_workloads
do_monitor_disable_loop*     youtube-loop.html
do_monitor_resolution_loop*  youtube-reload.html

Notez que pour les exécuter, vous devez passer «exécuter». Par exemple:

$ do_glx_loop run

Sans arguments, les scripts afficheront l'utilisation. C'est en partie pour la sécurité (au cas où les gens exécuteraient simplement les scripts à l'aveugle), mais c'est surtout pour garder l'API des scripts en ordre.

Ceux que j'ai suivis sont probablement les meilleurs pour commencer. Je commencerais par exécuter un seul script à la fois et le laisserais partir quelques heures. Si votre système survit suffisamment bien, essayez d'en exécuter deux ou plus simultanément.

Notez que je n'ai pas testé ces super-moi-même, donc je ne peux pas promettre qu'ils sont exempts de bogues. Mais ce sont des scripts assez courts et simples, donc, espérons-le, faciles à corriger, et les correctifs sont les bienvenus.

Notez également qu'ils peuvent très probablement déclencher des blocages sans rapport avec celui que vous essayez de résoudre. Les blocages GPU semblent tous identiques à l'œil non averti car ils présentent plus ou moins exactement les mêmes symptômes.

Journaux

Si vous utilisez Intel Graphics, il y a un / sys / kernel / debug / dri / 0 / i915_error_state que vous voulez. Il s'agit d'un instantané de l'état du registre au moment du blocage, et le haut de celui-ci contient des codes d'erreur. IPEHR, PGTBL_ER, ESR, EIR. Faites correspondre ces codes pour voir si vous avez la même erreur ou une erreur similaire.

Si vous n'êtes pas sur Intel Graphics (comme dans ce cas, vous ne l'êtes pas), ou si vous ne voyez pas de fichiers i915_error_state générés, alors dmesg et /var/log/kern.log sont ce qu'il faut regarder. Parfois, avec les blocages GPU, ils indiquent la cause ou le blocage du GPU.

Le pilote open source -ati a radeontool et avivotool, qui capturent les états de registre. Ce sont principalement pour l'open source -ati, mais les outils devraient également fonctionner avec -fglrx. Je ne l'ai jamais vu demander un bogue -fglrx, mais cela ne peut certainement pas faire de mal.

Essai

Pour tous les pilotes, l'étape suivante consiste généralement à commencer à tester des versions plus récentes ou plus anciennes du pilote. Pour les pilotes propriétaires, vous pouvez vérifier le ppa x-updates mais vous devrez probablement télécharger et installer manuellement le pilote à partir du site Web du fournisseur (et gâcher l'emballage de votre système ce faisant). Pour les pilotes FOSS comme -intel, -nouveau, -ati, cela signifie tester soit des noyaux plus récents soit des mesa plus récents. Nous fournissons des versions packagées de noyaux plus récents sur http://kernel.ubuntu.com/~kernel-ppa/mainline/ . Pour mesa, il existe différents PPA tels que xorg-edgers. Je suis également en train de préparer une mise à jour 8.0.3 pour précise, qui, selon nous, corrige un certain nombre de blocages pour Intel Graphics.

Dans tous les cas, ne vous arrêtez pas seulement lorsque vous trouvez une version qui fonctionne. Essayez d'autres versions entre votre version de travail et celle cassée. Si vous pouvez restreindre le support à deux versions adjacentes, cela peut être extrêmement utile aux développeurs pour isoler le correctif à l'origine de la régression.

Contribuant

Au fur et à mesure que vous dépannez, vous pouvez détecter des erreurs ou proposer des améliorations pour les scripts ou les documents. Les contributions à l'un de ces projets sont les bienvenues. Avec les documents wiki, allez-y et modifiez-les! J'essaie de les mettre à jour au moins une fois par an, mais je n'y arrive pas toujours, et le prochain gars à visiter la page appréciera certainement vos efforts pour les améliorer.

Pour les modifications apportées aux scripts eux-mêmes, également très appréciés. Envoyez-moi les modifications comme vous vous sentez à l'aise - comme des correctifs, une branche bzr ou git, ou même simplement des copies du script. Si vous prévoyez de faire beaucoup de changements, une branche bzr avec une proposition de fusion est le moyen préféré; des didacticiels sur la façon de le faire sont disponibles sur code.launchpad.net, ou n'hésitez pas à me rattraper sur IRC si vous avez des questions.

Ou, si vous n'êtes pas prêt à creuser dans le codage mais que vous souhaitez signaler les erreurs ou les zones où plus de fonctionnalités sont nécessaires, vous pouvez déposer des rapports de bogues de la manière habituelle ( ubuntu-bug xdiagnose).

Réparations rapides

Si vous n'êtes pas intéressé par le débogage ci-dessus, voici quelques conseils aléatoires:

Pour les pilotes propriétaires, essayez de les désinstaller et de les purger complètement de votre système, puis de les réinstaller à partir de zéro. Cela "résout" malheureusement beaucoup de bugs ...

Pour les pilotes FOSS, il existe différents commutateurs de noyau avec lesquels vous pouvez jouer. Pour les bugs 3D / mesa, il y a aussi driconf pour modifier divers paramètres.

finalement

Enfin, une demande ... s'il vous plaît ne déposez pas de rapports de bogues sur Launchpad à propos des "blocages aléatoires" avant d'avoir fait au moins un petit détour tel que décrit ci-dessus. Sinon, vous ajouteriez simplement du bruit.

Nous essayons de repérer des rapports de bogues bien documentés; nous trouvons que ceux-ci donnent un meilleur rapport qualité-prix et sont beaucoup plus susceptibles de se retrouver avec un correctif réel pour la distribution.

Bryce
la source
Merci pour vos réponses. Êtes-vous l'auteur du wiki de dépannage lié au gel ? Il semble que les scripts xdiagnose / workloads devraient y être mentionnés - je modifierais, mais je ne suis pas sûr de le faire aussi bien que vous. De plus, vous ne mentionnez pas l'utilisation de radeontool ici, mais cela est mentionné dans le wiki. Dois-je toujours utiliser radeontool dans mon cas?
Abe
de plus, un script qui exécutait tous les scripts dans xdiagnose / workloads, en commençant séquentiellement par ceux que vous aviez marqués d'un astérisque, serait-il utile? Enfin, où puis-je apprendre à soumettre des modifications?
Abe
Voici le premier bogue que j'ai trouvé (je pense): do_chws_loop et do_glx_loop nécessite wmctrl, do_glx_loop nécessite glxgears, mais aucun script "n'inclut de fonctionnalité pour tester et installer ce dont il a besoin." comme décrit dans README. Je pourrais probablement commencer à ajouter une telle fonctionnalité, mais dois-je d'abord soumettre un bogue, puis le corriger? Et, ça va si ça me prend cinq lignes de si ... sinon ...? Ou existe-t-il une «méthode préférée» ... et cela signifie-t-il que les scripts doivent être exécutés en tant que root? ... pourquoi exiger un argument "run"? Désolé pour toutes les questions, je veux juste pouvoir vous aider si je le peux.
Abe
Bien sûr, pas de problème, je mettrai à jour ma réponse pour couvrir ces points.
Bryce
Quant à votre troisième série de questions. Oui, le fait que les scripts testent ce dont ils ont besoin figure sur ma liste TODO. si ... sinon les blocs sont certainement un bon point de départ. En fin de compte, j'aimerais pouvoir permettre aux utilisateurs d'exécuter les scripts à partir d'une interface graphique, donc je voudrais qu'ils "communiquent" leurs exigences à l'interface graphique afin qu'il puisse les griser si l'utilisateur n'a pas les exigences. Mais je suis loin d'être en mesure de le faire, donc de simples vérifications de la ligne de commande sont le bon endroit pour commencer.
Bryce