Journal Comment mieux gérer les plantages de carte graphique

Posté par  .
Étiquettes : aucune
0
20
août
2007
Un article sur un site de matériel ( http://www.hardware.fr/news/9012/1-plantages-vista-5-dus-x-g(...) ) m'a appris que Windows Vista sait détecter et récupérer un plantage de la carte graphique ( au niveau pilotes ou matériel ). Vu la complexité croissante de cet élément périphérique, qui est passé en quelques années d'une zone mémoire à lire ou écrire à un ensemble de calcul complet (processeur indépendant plus mémoire), cette approche me semble importante : de même qu'on fait de la gestion d'erreurs dans un flux ethernet entre deux machines, pourquoi ne pas profiter de l'indépendance de X pour migrer les applications ouvertes vers une nouvelle instance.

Ma question à 2 balles :
- est-ce possible à l'heure actuelle? (De migrer une fenêtre d'un DISPLAY :0 vers :1 par exemple)

L'intérêt serait de faire un Ctrl+Alt+Backspace et de tout retrouver sans problème ;-)
  • # rediriger le DISPLAY

    Posté par  . Évalué à 2.

    • [^] # Re: rediriger le DISPLAY

      Posté par  . Évalué à 4.

      en fait il existe un protocole X pour faire ça, c'est utilisé par teleport:

      > apt-cache show teleport
      [...]
      Description: moves running applications between displays
      Teleport allows some applications to be moved between X displays without
      being closed and restarted. It uses X properties to request that applications
      which support the display migration protocol move to another display.


      Seul hic, il faut donc que l'application (généralement le toolkit sous-jacent: gtk, qt, ...) supporte ça. Personnellement sur Feisty je ne l'ai pas vu fonctionner (ayant 2 display: 0.0 et 0.1).
  • # xmove NOW !

    Posté par  (site web personnel) . Évalué à 2.

    est-ce possible à l'heure actuelle? (De migrer une fenêtre d'un DISPLAY :0 vers :1 par exemple)

    Je connais xmove qui est sensé pouvoir faire cela.
    En fait il s'agit d'un "proxy" Xwindow qui s'intercale entre ton appli et les "vraix" serveurs X. Tu as aussi un programme permettant de contrôler et déplacer les fenêtres (xmovectrl je crois)

    J'ai un peu joué avec à un moment, j'avais même dvlp une petite appli graphique pour faire cela facilement. Ca marchait pas trop mal, mais j'ai vite abandonné à cause de bugs génants. (si je me souviens bien je n'arrivais pas à identifier les fenêtres des que j'en avait plus de deux, ce qui est gênant pour savoir laquelle déplacer)

    Cela dit, mes tests étaient en ubuntu dapper cela a peut-être changé depuis. Mais ce n'est pas sur vu que le dev est arrêté.
    • [^] # Re: xmove NOW !

      Posté par  . Évalué à 10.

      L'idéal serait que les gars de Xorg reprennent le code de Xmove pour en faire un truc bien intégré à Xorg.

      En attendant, ça pourrait être aussi le boulot des distrib de proposer l'intégration de cette fonctionnalité en tant que proof of concept en attendant que ça se standardise (comme ça s'était fait chez Novel il y a un an et demi pour Xgl et Compiz, par exemple).
      En tout cas ce serait un plus indéniable pour la distrib qui le fera en premier.
      • [^] # Re: xmove NOW !

        Posté par  . Évalué à 2.

        Ce qui c'est passé avec Novell et Xgl/Compiz, c'est que Novell a décidé d'embaucher le développeur de Xgl et de faire bosser sur un dépôt interne jusqu'à ce que le produit soit présentable, et le présenter avec autant de force marketing que possible.
        Novell n'est pas à l'origine de Xgl et Compiz.
        Sinon, pour les plantages, y'a des trucs qui rendent ça impossible ou presque :
        1- les applis utilisant GLX ou XVideo (ou tout ce qui fait du rendu direct) : à mon avis Xmove marche pas pour ça et marcherait pas pour ça avant un bout de temps...
        2- l'absence de gestion des modes de l'écran dans le noyau pour lui permettre de remettre la carte graphique dans un état potable avant de relancer X.

        (Le deuxième problème est en cours de résolution, mais ça va prendre un certain temps...)
        • [^] # Re: xmove NOW !

          Posté par  . Évalué à 2.

          Pour le 1, cela fait partie de ce que j'entendais par "intégration". Donc ça veut sûrement dire modifier du code dans GLX et XVideo et consorts. C'est le genre de trucs pour lesquels je ne fais pas trop confiance aux distribs, mais plutôt aux gars de Xorg (exemple: AIGLX beaucoup mieux "intégré" que Xgl).

          Pour le 2... moui, ce serait l'idéal. M'enfin, nombre de plantages n'imposent pas de réinitialiser la carte video pour relancer X. Et puis, après tout, pourquoi la réinitialisation ne se ferait-elle pas en userland ?
          Bon, je n'y connais pas grand chose, à part la théorie, mais j'ai l'impression que le problème n'est pas tellement où ça se passe, mais plutôt ce qu'il faut faire exactement (quelles instructions, quels registres toucher ?).
          • [^] # Re: xmove NOW !

            Posté par  . Évalué à 2.

            La gestion de certains trucs graphiques dans le noyau ça peut déjà aider à retourner dans un état potable sans X, puis relancer X derrière sans soucis.
            Sinon, pour GLX et XVideo, ça m'étonnerait que ça soit faisable. Il faudrait au minimum faire une sauvegarde de la mémoire vidéo utilisée par un programme, la restaurer de la bonne façon, s'occuper des shaders et de toutes les joyeusetés disponibles... Bref, truc bien lourd.
  • # Violence des plantages versus leur fréquence.

    Posté par  . Évalué à 4.

    J'ai que très rarement eu des plantages sous linux (typiquement une fois tous les quatre à six mois), mais ils étaient tous particulièrement violent, c'est à dire un freeze total, où on voyait toujours le bureau mais plus rien ne répondait, même pas un CTRL+ALT+F1 pour accéder à la console. Je pense qu'ils étaient dû au driver proprio nvidia, mais sous windows quand ça venait de la cg (cette fois c'était une ATi) ça me faisait juste un black screen pendant quelques secondes, suivi d'un message avec vpu recover, mais le systeme ne freezait pas. Par contre je plantais bien plus souvent mais c'est une autre histoire.
    • [^] # De l'intérêt des Magic system Request Key

      Posté par  (site web personnel) . Évalué à 8.

      Ca existe depuis pas mal de temps mais bizzarement c'est assez méconnu et assez peu utilisé (vu le nombre de plantages d'un linux... on comprend pourquoi)
      Ces commandes permettent de redemarrer un linux planté de façon clean.

      Les Magic Keys requièrent l'emploi d'une combinaison de trois touches à la fois.
      La touche "ALT" (à gauche de la barre d'espacement, à ne pas confondre avec la touche "ALT Gr"), la touche "SysRq" (System Request), cette touche n'est rien d'autre que la touche appelée et désignée par "Impr écran syst" (en haut à droite des touches F1 à F12), et enfin d'une troisième touche parmi les lettres suivantes :

      * R : Raw Met le clavier en mode "raw" (brut). Essayez d'accéder à nouveau à votre clavier.
      * S : Sync Synchronisation du disque. Essaie d'écrire toutes les données non sauvegardées.
      * E : tErm SIGTERM. Envoie un signal de terminaison à tous les processus, sauf à init.
      * I : kIll SIGKILL. Envoie un signal de fin à tous les processus, sauf à init.
      * U : Umount Remonte tous les systèmes de fichiers en mode lecture seule. Empêche une vérification du système de fichiers au redémarrage
      * B : reBoot Redémarre le système. Plus propre que l'appui sur "reset".
      * O : Out Arrête le système.
      * L : kilL SIGKILL. Envoie un signal de fin à tous les processus, y compris à init.
      * K : Key Envoie un signal de fin à tous les processus de la console virtuelle courante.
      * P : Print Affiche le contenu des registres et des drapeaux (flags) dans la console.
      * M : Memory Affiche le contenu de la mémoire dans la console.
      * T : Task Affiche le contenu des tâches en cours d'exécution et des informations qui les concernent.
      * 0-9 : Number Paramètre le niveau de la console de log.
      * H : Help Affiche une aide sur les codes touches.
      • [^] # Re: De l'intérêt des Magic system Request Key

        Posté par  . Évalué à 2.

        question bete est-ce normal que cela ne fonctionne pas avec un ordi portable IBM? Parceque j'ai ma carte ATI qui decide de m'embetter de temps en temps et bon Magic Keys (bien que compile dans le kernel) ne fonctionne pas. Est-ce du au fait que pour avoir SysR il faut presser la touche Fn aussi et que comme le systeme est mort il a perdu aussi l'acces a cette touche un chouilla particuliere?
      • [^] # Re: De l'intérêt des Magic system Request Key

        Posté par  . Évalué à 2.

        Problème : ces "magic key" ne fonctionnent pas toujours en cas de freeze total ...

        Et je les connais bien : http://forum.ubuntu-fr.org/viewtopic.php?id=12149 (sujet similaire au tien mais moins complet)
      • [^] # Re: De l'intérêt des Magic system Request Key

        Posté par  (site web personnel) . Évalué à 4.

        Cette fonctionnalité n'est pas toujours activée dans le noyau standard des distributions, ce qui peut en partie expliquer sa méconnaissance. Mandrake/Mandriva le fait depuis longtemps, pour les autres je ne sais pas.

        Ça permet 'facilement' de savoir si c'est X qui est planté et 'bloque' le clavier ou bien si c'est vraiment le kernel qui déconne.
        • [^] # Re: De l'intérêt des Magic system Request Key

          Posté par  . Évalué à 2.

          C'est aussi le cas de Debian et d'Ubuntu. Ça commence à faire du monde ;-).
          • [^] # Re: De l'intérêt des Magic system Request Key

            Posté par  (site web personnel) . Évalué à 1.

            Et Ubuntu veut le gicler tout comme le raccourcis ctrl-alt-back pour fermer X.
            Au motif de l'userfriendly.
            Hum ...
            • [^] # Re: De l'intérêt des Magic system Request Key

              Posté par  . Évalué à 2.

              En même temps la dernière fois que j'ai voulu recompiler un noyeau Linux (ça date d'il y a quelques années) l'option Magic Keys était dans une rubrique d'options avancées et dangereuses avec plein de warnings partout.

              Je n'ai pas d'avis sur le sujet, mais si les développeurs du noyeau me disent de bien faire attention avant d'activer une option du noyeau et de ne le faire que si je suis sur de moi, je préfère m'abstenir.

              BeOS le faisait il y a 20 ans !

              • [^] # Re: De l'intérêt des Magic system Request Key

                Posté par  (site web personnel) . Évalué à 2.


                config MAGIC_SYSRQ
                bool "Magic SysRq key"
                depends on !UML
                help
                If you say Y here, you will have some control over the system even
                if the system crashes for example during kernel debugging (e.g., you
                will be able to flush the buffer cache to disk, reboot the system
                immediately or dump some status information). This is accomplished
                by pressing various keys while holding SysRq (Alt+PrintScreen). It
                also works on a serial console (on PC hardware at least), if you
                send a BREAK and then within 5 seconds a command keypress. The
                keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
                unless you really know what this hack does.


                Ce n'est effectivement pas définis par default.
                Mais il n'y a rien de vraiment dangereux avec cette option.
                il faut juste eviter de l'activer sur une machine en libre accés.
              • [^] # Re: De l'intérêt des Magic system Request Key

                Posté par  . Évalué à 2.

                En même temps recompiler son noyau c'est pas très user-friendly ;-)
                sans rire, ces touches posent un gros problème de sécurité quand la machine est d'accès semi-public, parce qu'en gros n'importe qui peut alors faire un DoS local.

                Mandriva, dans les petits livrets qui accompagn(ai)ent les boîtes indiquait, comme tout constructeur de matériel, une petite procédure à suivre en cas de panne, et les Magic Keys en faisaient partie (un peu comme "l'appareil ne s'allume pas -> vérifiez qu'il est bien branché").
                C'était amusant (mes premiers pas sous Linux... souvenirs, souvenirs...), ça donnait vraiment l'impression que ça doit marcher comme le matériel, c'est à dire sans problèmes récurrents et out of the box !
                • [^] # Re: De l'intérêt des Magic system Request Key

                  Posté par  . Évalué à 2.

                  En même temps si j'ai envie de faire un DoS local j'ai plein d'autres moyen pour le faire, genre débrancher le clavier et la souris (la plupart des gens se font avoir), débrancher l'écran ou la prise de courant ...
                  • [^] # Re: De l'intérêt des Magic system Request Key

                    Posté par  . Évalué à 1.

                    le clavier et la souris


                    Le must à mon avis reste quand même d'inverser la souris et le clavier (quand ils sont tous les deux en PS2, ce qui est de plus en plus rare)
                    • [^] # Re: De l'intérêt des Magic system Request Key

                      Posté par  (site web personnel) . Évalué à 3.

                      c'est sûr que les échanger quand ils sont en usb ça fait beaucoup moins d'effet.....
                    • [^] # Re: De l'intérêt des Magic system Request Key

                      Posté par  (site web personnel) . Évalué à 3.

                      On m'avait refilé un vieux 286 IBM où on pouvait intervertir la souris et le clavier sur le PS2... comment se fait-il que sur les machines que j'ai vu ensuite cela n'était plus possible ?
                      • [^] # Re: De l'intérêt des Magic system Request Key

                        Posté par  . Évalué à 1.

                        A bon? j'ai eu l'occasion de tester sur des bécanes beaucoup plus récentes et c'est possible. (Combien de fois j'ai du faire de reset après un branchement en aveugle du clavier et de la souris)
                    • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                      Posté par  (site web personnel) . Évalué à 2.

                      (quand ils sont tous les deux en PS2, ce qui est de plus en plus rare)

                      Toi aussi, vote non aux souris de base dell qui prennent un port USB pour rien, alors qu'elles méritent à peine un port ps2.
                      • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                        Posté par  (site web personnel) . Évalué à 2.

                        On peut considérer que si la souris et le clavier sont USB, il y a plus de port USB sur la machine.

                        Je suis pour le clavier et la souris USB, cela simplifie la machine qui ne parle que USB et plus le PS2. Je ne vois pas l'intérêt du PS2 alors que l'USB fait la même chose. C'est même moins cher de ne faire que de l'USB car tu n'as qu'un jeu de composant électronique et qu'une pile logiciel (USB) à gérer.

                        Bref, vive l'USB, je trouve que DELL à raison d'avoir supprimer le PS2.
                        • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                          Posté par  . Évalué à 2.

                          "parler" le PS2 est trivial et meme si ta CM n'a plus de connecteur, il a toujours un bout de circuit non branché dans un des puces de ta CM qui est capable de "parler" le PS2.

                          Pas besoins de "pile" logicielle. Il suffit d'envoyer des octets sur un port et de faire 2/3 configs sur un autre.

                          "parler" l'usb est beaucoup, beaucoup plus compliqué.
                          Maintenant qu'il est si répandu, c'est pas trop un problème. Mais devans la simplicité du PS2 ca ne me choque pas du tout d'en voir persister.
                          • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                            Posté par  . Évalué à 2.

                            Juste comme ça, le but de l'USB quand même c'est bien de prendre tout les périphs pas rapide existant et d'inventer un connecteur et un protocole qui essayerai de se débrouiller pour s'adapter à tout. Dans le monde USB on aurai nos écrans, notre souris, notre clavier, nos disques internes et externes, nos lecteurs disquettes, nos lecteurs/graveurs CD/DVD interne/externe, nos cartes son et autres qui serai reliés en USB.

                            Avec tout les problèmes que pose l'USB sous windows (drivers des contrôleurs foireux) et sous linux (lorsque l'implémentation acpi est buggé), sans compter les ''mon matériel n'est reconnu qu'une fois sur deux'' (qui ont plus l'air d'être des problèmes d'électronique), les ''erreur : vos ports USB ne peuvent pas fournir plus de courant, débranchez des périphériques'' ...

                            • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                              Posté par  . Évalué à 2.

                              Dans le monde USB on aurai nos écrans,[...] nos disques internes et externes,[...]nos lecteurs/graveurs CD/DVD interne/externe[...]

                              Chez moi, tout ces périphériques sont rapides.
                              • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                                Posté par  . Évalué à 2.

                                Bien sur, mais ils peuvent très bien être ralentis un peu, juste pour pouvoir ''simplifier la connectique'' et faciliter la vie à l'utilisateur lambda (qui ne sait jamais comment brancher les cables, et qui de toute façon préfère payer une installation à domicile). et je suis bien heureux que ça ne soit pas arrivé ;)

                                Dans la spécification de l'USB 1.1 il était explicitement indiqué que cette norme à pour but de simplifier la vie à l'utilisateur et que pour que ça soit efficace il faut que ça soit massivement utilisé (dommage la spec n'est plus en ligne, mais ça devait être ça en gros)
                                • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                                  Posté par  . Évalué à 2.

                                  l'écran ca va etre dur de la ralentir. Surtout l'utilisateur qui vas raler.

                                  Pour le dd, pour du stockage on peut le ralentir, pour le système l'utilisateur va rler a nouveau ;)

                                  Je suis d'accord que le but de l'usb est bien de simplifier la vie et qu'en ce sens il est très bien.

                                  Mais pour des dd externes, rien ne vaut l'esata, pour les écrans du dvi/hdmi/displayport/ ...

                                  Dire qu'il y a 10 ans, tu brancher juste l'écran au secteur et l'uc (qui avait le clavier) à l'écran et voila ca marcher:D
                            • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                              Posté par  (site web personnel) . Évalué à 2.

                              Juste pour dire que le BUS écran n'est pas un bus lent mais plutôt rapide et qu'il faut un câble de type ethernet pour faire passer la vidéo dessus. Et encore, elle ne passe pas en trame ethernet dessus donc ne peut être commutée par un switch du commerce.
                          • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                            Posté par  (site web personnel) . Évalué à 1.

                            Je suis d'accord pour dire que le PS2 est trivial et un dérivée du RS232.

                            Cela n'empêche qu'avoir tous les composants en USB simplifie pas mal les choses. On peut brancher sa souris sur un hub USB...

                            En pratique, cela signifie 2 prises USB de plus à l'arrière du PC et non deux prises USB de moins. Voila pourquoi je n'étais pas d'accord avec le premier argumentaire.

                            Au niveau matériel, même si le PS2 est trivial, il faut continuer à avoir des périphériques parlant le PS2. Alors qu'avec l'effet de volume, avoir un composant parlant USB n'est pas beaucoup plus cher et permet d'unifier tout cela.

                            C'est comme ethernet comme bus rapide qui est en train de bouffer petit à petit les autres. Je trouve cela bien. Cela limite le nombre de câble. Par exemple, on a pour le stockage l'iSCSI ou le PoE et de plus en plus de caméra rapide sont connecté en ethernet et plus en firewire. Ne plus avoir de câble SCSI ne me dérange pas, au contraire. Avoir du RJ45 à la place du firewire non plus.

                            Cette simplification me semble une bonne chose.
                        • [^] # Re: De l'intérêt des souris qui squatent les ports usb

                          Posté par  (site web personnel) . Évalué à 3.

                          Quand tu te retrouve avec un shell en single user avec kernel minimal, si tu n'a que des peripherique USB, tu es mal !
                          Alors qu'en PS/2, ca passe vraiment dans n'importe quelle situation (du moment que Bios et la CM sont intactes).

                          Par contre, pourquoi retrouve-t-on encore de l'ISA sur des cartes mére pour AMD64 ?
                          Qu'est-ce qui tourne uniquement en ISA et qui impose ce bridge PCI->ISA ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.