Bonjour, Le démarrage problématique me semble suivre le schéma suivant: 1. Démarrage avec xorg.conf, création d'un fichier log et crash 2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log. Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe. Eric
C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé.
Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log: This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2) Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 Build Date: 13 June 2008 01:08:21AM [...] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008 (==) Using config file: "/etc/X11/xorg.conf.failsafe" (==) ServerLayout "Default Layout" [...]
Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse.
--- En date de : *Mer, 22.10.08, Eric Buist /buisteri@iro.umontreal.ca/* a écrit :
De: Eric Buist <buisteri@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca>, semaphore45@yahoo.com Date: mercredi 22 Octobre 2008, 22 h 43 Bonjour, Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci: cd /etc/X11 mv xorg.conf.failsave xorg.conf.failsafe.BACKUP ln xorg.conf xorg.conf.failsafe De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :) Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant. Eric C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, *fglrx* est installé, ainsi que *ATI Catalyst* (en fait, ils n'ont pas bougé depuis un mois). Un passage avec /aticonfig --initial -f/ sur un *xorg.conf* vide donne un *xorg.conf* certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un *fsck -y* en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée. Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN --- En date de : *Mer, 24.9.08, Pascal Lamblin /<lamblinp@iro.umontreal.ca>/* a écrit : De: Pascal Lamblin <lamblinp@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." <semaphore45@yahoo.com> Cc: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca> Date: mercredi 24 Septembre 2008, 10 h 06 On Tue, Sep 23, 2008, C.T. wrote: > eh bien, ce changement de "virtual" size dans xorg.conf ne semble > pas très concluant. Certes la résolution est montée jusqu'à > 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en > 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, > ce qui n'est pas possible sur cet écran. Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ? Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage. Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres. Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes. Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr. Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode > J'ai tenté de reconstruire xorg.conf à partir de la version > .failsafe en ajoutant petit à petit les sections pertinentes à la > résolution, ça n'a rien changé; on dirait qu'il démarre tantôt avec > xorg.conf.failsafe, tantôt avec xorg.conf. Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème. Bonne chance, -- Pascal ------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/> ------------------------------------------------------------------------ _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
Découvrez les photos * les plus intéressantes du jour!* http://www.flickr.com/explore/interesting/7days/
Afficher les réponses par date
Une question rapide avant que j'entreprenne les tests ce soir, comment force-t-on un démarrage en runlevel 3?
--- En date de : Jeu, 23.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit : De: Eric Buist buisteri@iro.umontreal.ca Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." semaphore45@yahoo.com, "Membres actifs du GULUM" gulum-team@iro.umontreal.ca Date: jeudi 23 Octobre 2008, 13 h 28
Bonjour,
Le démarrage problématique me semble suivre le schéma suivant:
1. Démarrage avec xorg.conf, création d'un fichier log et crash
2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès
Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log.
Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe.
Eric
C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé.
Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log:
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686
Build Date: 13 June 2008 01:08:21AM
[...]
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008
(==) Using config file: "/etc/X11/xorg.conf.failsafe"
(==) ServerLayout "Default Layout"
[...]
Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse.
--- En date de : Mer, 22.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit :
De: Eric Buist buisteri@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca, semaphore45@yahoo.com
Date: mercredi 22 Octobre 2008, 22 h 43
Bonjour,
Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci:
cd /etc/X11
mv xorg.conf.failsave xorg.conf.failsafe.BACKUP
ln xorg.conf xorg.conf.failsafe
De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :)
Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant.
Eric
C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, fglrx est installé, ainsi que ATI Catalyst (en fait, ils n'ont pas bougé depuis un mois). Un passage avec aticonfig --initial -f sur un xorg.conf vide donne un xorg.conf certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un fsck -y en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée.
Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN
--- En date de : Mer, 24.9.08, Pascal Lamblin lamblinp@iro.umontreal.ca a écrit :
De: Pascal Lamblin lamblinp@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "C.T." semaphore45@yahoo.com
Cc: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca
Date: mercredi 24 Septembre 2008, 10 h 06
On Tue, Sep 23, 2008, C.T. wrote:
eh bien, ce changement de "virtual" size dans xorg.conf ne
semble
pas très concluant. Certes la résolution est montée jusqu'à 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, ce qui n'est pas possible sur cet écran.
Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ?
Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage.
Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync
À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres.
Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes.
Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr.
Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode
J'ai tenté de reconstruire xorg.conf à partir de la version .failsafe en ajoutant petit à petit les sections pertinentes à la résolution, ça n'a rien changé; on dirait qu'il
démarre tantôt avec
xorg.conf.failsafe, tantôt avec xorg.conf.
Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème.
Bonne chance,
Bonjour, La façon la plus simple est de modifier les arguments passés au noyau. Il faut pour cela, sous GRUB, choisir la ligne correspondant à Linux et appuyer sur une touche comme a ou e. À la fin de cette ligne, il faut ajouté 3, séparé du reste par un espace. Cette technique a pour avantage que rien n'est modifié dans les paramètres du système, mais il faut la répéter à chaque fois qu'il est nécessaire de démarrer sur le niveau 3. Mais cela fait longtemps que je l'ai utilisée. Je m'en servais de temps en temps sous Fedora, mais je ne suis pas sûr de l'avoir employée depuis que je suis sous Ubuntu. Eric
C.T. a écrit :
Une question rapide avant que j'entreprenne les tests ce soir, comment force-t-on un démarrage en runlevel 3?
--- En date de : *Jeu, 23.10.08, Eric Buist /buisteri@iro.umontreal.ca/* a écrit :
De: Eric Buist <buisteri@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." <semaphore45@yahoo.com>, "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca> Date: jeudi 23 Octobre 2008, 13 h 28 Bonjour, Le démarrage problématique me semble suivre le schéma suivant: 1. Démarrage avec xorg.conf, création d'un fichier log et crash 2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log. Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe. Eric C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé. Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log: This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2) Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 Build Date: 13 June 2008 01:08:21AM [...] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008 (==) Using config file: "/etc/X11/xorg.conf.failsafe" (==) ServerLayout "Default Layout" [...] Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse. --- En date de : *Mer, 22.10.08, Eric Buist /<buisteri@iro.umontreal.ca>/* a écrit : De: Eric Buist <buisteri@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca>, semaphore45@yahoo.com Date: mercredi 22 Octobre 2008, 22 h 43 Bonjour, Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci: cd /etc/X11 mv xorg.conf.failsave xorg.conf.failsafe.BACKUP ln xorg.conf xorg.conf.failsafe De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :) Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant. Eric C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, *fglrx* est installé, ainsi que *ATI Catalyst* (en fait, ils n'ont pas bougé depuis un mois). Un passage avec /aticonfig --initial -f/ sur un *xorg.conf* vide donne un *xorg.conf* certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un *fsck -y* en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée. Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN --- En date de : *Mer, 24.9.08, Pascal Lamblin /<lamblinp@iro.umontreal.ca>/* a écrit : De: Pascal Lamblin <lamblinp@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." <semaphore45@yahoo.com> Cc: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca> Date: mercredi 24 Septembre 2008, 10 h 06 On Tue, Sep 23, 2008, C.T. wrote: > eh bien, ce changement de "virtual" size dans xorg.conf ne semble > pas très concluant. Certes la résolution est montée jusqu'à > 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en > 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, > ce qui n'est pas possible sur cet écran. Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ? Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage. Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres. Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes. Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr. Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode > J'ai tenté de reconstruire xorg.conf à partir de la version > .failsafe en ajoutant petit à petit les sections pertinentes à la > résolution, ça n'a rien changé; on dirait qu'il démarre tantôt avec > xorg.conf.failsafe, tantôt avec xorg.conf. Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème. Bonne chance, -- Pascal ------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/> ------------------------------------------------------------------------ _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
------------------------------------------------------------------------ Découvrez les photos * les plus intéressantes du jour!* <http://www.flickr.com/explore/interesting/7days/>
Découvrez les photos * les plus intéressantes du jour!* http://www.flickr.com/explore/interesting/7days/
Bonjour à tous,
alors voici comment j'ai résolu le problème d'affichage et d'accélération 3D pour le HP dc5750, un des ordinateurs normalisés de l'UdeM, plus quelques petites choses apprises en passant.
En suivant les instructions d'Éric, j'ai d'abord fait appel aux exécutables adaptés avant de tenter les solutions plus violentes.
En premier, j'ai exécuté EnvyNG et le laisser faire le sale travail d'installation des pilotes propriétaires ATI, initialisé comme indiqué avec la commande sudo aticonfig --initial -f qui s'est exécutée sans erreur, puis redémarré. C'est revenu en mode failsafe à 800x600@60Hz. Le fichier xorg.0.log indiquait avoir utilisé xorg.conf.failsafe. Conséquemment, le centre de contrôle ATI Catalyst refusait de se lancer puisqu'il détectait que le pilote fglrx n'était pas utilisé (avec raison).
En second, désinstallation, reboot, téléchargement du pilote officiel directement de chez ATI, puis installation selon leurs instructions (http://www2.ati.com/drivers/linux/linux_cat810-inst.html), sans oublier l'initialisation du xorg.conf avec sudo aticonfig --initial -f. Un reboot plus tard, toujours pas d'utilisation du pilote fglrx, utilisation du xorg.conf.failsafe.
En troisième, j'ai tenté la solution du runlevel 3, qui malheureusement n'existe pas sous Ubuntu, remplacé qu'il est par le "Recovery mode" de GRUB. J'ai sélectionné console root pour la suite, et tapé startx. Comme prévu, X n'a pas démarré, mais laissé une petite trace indiquant qu'une des sections de xorg.conf avec l'écran était incomplète ("no usable screen", qqch comme ça). Je n'ai pas plus de détails, n'ayant pas réussi à enregistrer le standard output dans un fichier texte, désolé. Comme Éric le pensait, ce log avorté est éliminé au boot suivant. J'ai donc rentré, en console root, aticonfig --initial -f, qui s'est terminée sans erreur, puis entré startx. Un bureau root est apparu (en anglais), et j'ai pu modifier la résolution avec ATI Catalyst. Ça a planté quand j'ai voulu redémarrer avec la GUI, j'ai redémarré en force, donc, puis refait la même manipulation sans lancer X, et redémarré de la console.
En quatrième, je me suis loggué normalement et changé la résolution avec ATI Catalyst. L'accélération 3D est revenue, le cube de bureau aussi. C'est résumé et paraît court comme ça, mais jai fait beaucoup d'erreurs, et probablement un tas de redémarrages inutiles.
Problèmes recontrés en cours de route: la désinstallation des pilotes officiels selon les instructions d'ATI empêche de se logguer au redémarrage suivant. C'est un problème qui arrive tant qu'on n'ajoute pas xforcevesa comme paramètre de boot. L'autre manière est d'installer Ubuntu en spécifiant le mode vidéo sans échec. Cette fois, xforcevesa était toujours là, mais ça ne logguait quand même pas. Il a fallu sélectionner la "Session de secours GNOME", qui ne lit aucun script de démarrage. Là, la résolution est passé à 1024x768@75Hz, mais toujours sans accélération.
Toutes les manipulations avec EnvyNG 1.1.1 (installations, désinstallations, manuellement ou automatiquement) ont échoué. L'installation de EnvyNG lui-même ne donne pas les mêmes résultats avec apt-get et Synaptic.
L'installation de paquets générés par le script-archive de ATI pour Ubuntu a aussi échoué.
La seule conclusion que je vois est un manque flagrant de coopération entre le script-archive d'ATI et le fait qu'il s'attende probablement à être exécuté en session root, ce qui n'est pas normalement possible dans Ubuntu, que quelqu'un me corrige si je me trompe.
En espérant que ça aide d'autres contraints à utiliser cette machine retorse sous Ubuntu et que ATI tienne enfin compte des réalités de la distro la plus utilisée..
--- En date de : Jeu, 23.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit : De: Eric Buist buisteri@iro.umontreal.ca Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." semaphore45@yahoo.com, "Membres actifs du GULUM" gulum-team@iro.umontreal.ca Date: jeudi 23 Octobre 2008, 13 h 28
Bonjour,
Le démarrage problématique me semble suivre le schéma suivant:
1. Démarrage avec xorg.conf, création d'un fichier log et crash
2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès
Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log.
Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe.
Eric
C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé.
Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log:
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686
Build Date: 13 June 2008 01:08:21AM
[...]
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008
(==) Using config file: "/etc/X11/xorg.conf.failsafe"
(==) ServerLayout "Default Layout"
[...]
Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse.
--- En date de : Mer, 22.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit :
De: Eric Buist buisteri@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca, semaphore45@yahoo.com
Date: mercredi 22 Octobre 2008, 22 h 43
Bonjour,
Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci:
cd /etc/X11
mv xorg.conf.failsave xorg.conf.failsafe.BACKUP
ln xorg.conf xorg.conf.failsafe
De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :)
Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant.
Eric
C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, fglrx est installé, ainsi que ATI Catalyst (en fait, ils n'ont pas bougé depuis un mois). Un passage avec aticonfig --initial -f sur un xorg.conf vide donne un xorg.conf certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un fsck -y en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée.
Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN
--- En date de : Mer, 24.9.08, Pascal Lamblin lamblinp@iro.umontreal.ca a écrit :
De: Pascal Lamblin lamblinp@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "C.T." semaphore45@yahoo.com
Cc: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca
Date: mercredi 24 Septembre 2008, 10 h 06
On Tue, Sep 23, 2008, C.T. wrote:
eh bien, ce changement de "virtual" size dans xorg.conf ne
semble
pas très concluant. Certes la résolution est montée jusqu'à 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, ce qui n'est pas possible sur cet écran.
Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ?
Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage.
Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync
À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres.
Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes.
Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr.
Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode
J'ai tenté de reconstruire xorg.conf à partir de la version .failsafe en ajoutant petit à petit les sections pertinentes à la résolution, ça n'a rien changé; on dirait qu'il
démarre tantôt avec
xorg.conf.failsafe, tantôt avec xorg.conf.
Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème.
Bonne chance,
Bonjour, C'est vraiment étrange tout ça. En tout cas, je vais continuer à éviter les cartes graphiques ATI! D'après l'erreur obtenue avec startx, je dirais que aticonfig a modifié la section Device de xorg.conf sans adapter correctement la section screen. Dans xorg.conf, il y a une section Device relative à la carte graphique. aticonfig doit avoir fait en sorte que cette section référait au driver fglrx. Mais si aticonfig a aussi changé l'identifiant de cette section sans mettre à jour la section Screen du fichier, cela pourrait fort bien causer le bogue. Il se peut aussi que le pilote fglrx soit plus méchant que les autres quant au contenu du xorg.conf. Par exemple, peut-être s'attend-il à avoir des résolutions explicites dans la section screen tandis que le pilote libre peuvent s'en passer et auto-détecter. Aussi, la section Monitor pourrait être nécessaire tandis qu'elle ne le serait pas avec d'autres pilotes. En bref, tant que ça fonctionne, ne touche plus, mais si ça niaise de nouveau, tu auras quelques pistes avec lesquelles travailler. Eric
C.T. a écrit :
Bonjour à tous,
alors voici comment j'ai résolu le problème d'affichage et d'accélération 3D pour le HP dc5750, un des ordinateurs normalisés de l'UdeM, plus quelques petites choses apprises en passant.
En suivant les instructions d'Éric, j'ai d'abord fait appel aux exécutables adaptés avant de tenter les solutions plus violentes.
En premier, j'ai exécuté EnvyNG et le laisser faire le sale travail d'installation des pilotes propriétaires ATI, initialisé comme indiqué avec la commande sudo aticonfig --initial -f qui s'est exécutée sans erreur, puis redémarré. C'est revenu en mode failsafe à 800x600@60Hz. Le fichier xorg.0.log indiquait avoir utilisé xorg.conf.failsafe. Conséquemment, le centre de contrôle ATI Catalyst refusait de se lancer puisqu'il détectait que le pilote fglrx n'était pas utilisé (avec raison).
En second, désinstallation, reboot, téléchargement du pilote officiel directement de chez ATI, puis installation selon leurs instructions (http://www2.ati.com/drivers/linux/linux_cat810-inst.html), sans oublier l'initialisation du xorg.conf avec sudo aticonfig --initial -f. Un reboot plus tard, toujours pas d'utilisation du pilote fglrx, utilisation du xorg.conf.failsafe.
En troisième, j'ai tenté la solution du runlevel 3, qui malheureusement n'existe pas sous Ubuntu, remplacé qu'il est par le "Recovery mode" de GRUB. J'ai sélectionné console root pour la suite, et tapé startx. Comme prévu, X n'a pas démarré, mais laissé une petite trace indiquant qu'une des sections de xorg.conf avec l'écran était incomplète ("no usable screen", qqch comme ça). Je n'ai pas plus de détails, n'ayant pas réussi à enregistrer le standard output dans un fichier texte, désolé. Comme Éric le pensait, ce log avorté est éliminé au boot suivant. J'ai donc rentré, en console root, aticonfig --initial -f, qui s'est terminée sans erreur, puis entré startx. Un bureau root est apparu (en anglais), et j'ai pu modifier la résolution avec ATI Catalyst. Ça a planté quand j'ai voulu redémarrer avec la GUI, j'ai redémarré en force, donc, puis refait la même manipulation sans lancer X, et redémarré de la console.
En quatrième, je me suis loggué normalement et changé la résolution avec ATI Catalyst. L'accélération 3D est revenue, le cube de bureau aussi. C'est résumé et paraît court comme ça, mais jai fait beaucoup d'erreurs, et probablement un tas de redémarrages inutiles.
Problèmes recontrés en cours de route: la désinstallation des pilotes officiels selon les instructions d'ATI empêche de se logguer au redémarrage suivant. C'est un problème qui arrive tant qu'on n'ajoute pas xforcevesa comme paramètre de boot. L'autre manière est d'installer Ubuntu en spécifiant le mode vidéo sans échec. Cette fois, xforcevesa était toujours là, mais ça ne logguait quand même pas. Il a fallu sélectionner la "Session de secours GNOME", qui ne lit aucun script de démarrage. Là, la résolution est passé à 1024x768@75Hz, mais toujours sans accélération.
Toutes les manipulations avec EnvyNG 1.1.1 (installations, désinstallations, manuellement ou automatiquement) ont échoué. L'installation de EnvyNG lui-même ne donne pas les mêmes résultats avec apt-get et Synaptic.
L'installation de paquets générés par le script-archive de ATI pour Ubuntu a aussi échoué.
La seule conclusion que je vois est un manque flagrant de coopération entre le script-archive d'ATI et le fait qu'il s'attende probablement à être exécuté en session root, ce qui n'est pas normalement possible dans Ubuntu, que quelqu'un me corrige si je me trompe.
En espérant que ça aide d'autres contraints à utiliser cette machine retorse sous Ubuntu et que ATI tienne enfin compte des réalités de la distro la plus utilisée..
--- En date de : *Jeu, 23.10.08, Eric Buist /buisteri@iro.umontreal.ca/* a écrit :
De: Eric Buist <buisteri@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." <semaphore45@yahoo.com>, "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca> Date: jeudi 23 Octobre 2008, 13 h 28 Bonjour, Le démarrage problématique me semble suivre le schéma suivant: 1. Démarrage avec xorg.conf, création d'un fichier log et crash 2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log. Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe. Eric C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé. Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log: This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2) Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 Build Date: 13 June 2008 01:08:21AM [...] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008 (==) Using config file: "/etc/X11/xorg.conf.failsafe" (==) ServerLayout "Default Layout" [...] Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse. --- En date de : *Mer, 22.10.08, Eric Buist /<buisteri@iro.umontreal.ca>/* a écrit : De: Eric Buist <buisteri@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca>, semaphore45@yahoo.com Date: mercredi 22 Octobre 2008, 22 h 43 Bonjour, Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci: cd /etc/X11 mv xorg.conf.failsave xorg.conf.failsafe.BACKUP ln xorg.conf xorg.conf.failsafe De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :) Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant. Eric C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, *fglrx* est installé, ainsi que *ATI Catalyst* (en fait, ils n'ont pas bougé depuis un mois). Un passage avec /aticonfig --initial -f/ sur un *xorg.conf* vide donne un *xorg.conf* certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un *fsck -y* en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée. Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN --- En date de : *Mer, 24.9.08, Pascal Lamblin /<lamblinp@iro.umontreal.ca>/* a écrit : De: Pascal Lamblin <lamblinp@iro.umontreal.ca> Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." <semaphore45@yahoo.com> Cc: "Membres actifs du GULUM" <gulum-team@iro.umontreal.ca> Date: mercredi 24 Septembre 2008, 10 h 06 On Tue, Sep 23, 2008, C.T. wrote: > eh bien, ce changement de "virtual" size dans xorg.conf ne semble > pas très concluant. Certes la résolution est montée jusqu'à > 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en > 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, > ce qui n'est pas possible sur cet écran. Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ? Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage. Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres. Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes. Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr. Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode > J'ai tenté de reconstruire xorg.conf à partir de la version > .failsafe en ajoutant petit à petit les sections pertinentes à la > résolution, ça n'a rien changé; on dirait qu'il démarre tantôt avec > xorg.conf.failsafe, tantôt avec xorg.conf. Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème. Bonne chance, -- Pascal ------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/> ------------------------------------------------------------------------ _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
------------------------------------------------------------------------ Découvrez les photos * les plus intéressantes du jour!* <http://www.flickr.com/explore/interesting/7days/>
Découvrez les photos * les plus intéressantes du jour!* http://www.flickr.com/explore/interesting/7days/
Si ça intéresse quelqu'un, j'ai pas mal de copies de fichiers qui ne marchaient pas. J'ai fais une copie du bon xorg.conf quelque part.
Par contre, l'hypothèse d'Éric n'explique pas pourquoi aticonfig --initial -f, finalement, initialise correctement xorg.conf mais seulement dans une session root, et ferait bugguer dans un simple sudo.
--- En date de : Ven, 24.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit : De: Eric Buist buisteri@iro.umontreal.ca Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300 À: "C.T." semaphore45@yahoo.com, "Membres actifs du GULUM" gulum-team@iro.umontreal.ca Date: vendredi 24 Octobre 2008, 13 h 20
Bonjour,
C'est vraiment étrange tout ça. En tout cas, je vais continuer à éviter les cartes graphiques ATI!
D'après l'erreur obtenue avec startx, je dirais que aticonfig a modifié la section Device de xorg.conf sans adapter correctement la section screen.
Dans xorg.conf, il y a une section Device relative à la carte graphique. aticonfig doit avoir fait en sorte que cette section référait au driver fglrx. Mais si aticonfig a aussi changé l'identifiant de cette section sans mettre à jour la section Screen du fichier, cela pourrait fort bien causer le bogue.
Il se peut aussi que le pilote fglrx soit plus méchant que les autres quant au contenu du xorg.conf. Par exemple, peut-être s'attend-il à avoir des résolutions explicites dans la section screen tandis que le pilote libre peuvent s'en passer et auto-détecter. Aussi, la section Monitor pourrait être nécessaire tandis qu'elle ne le serait pas avec d'autres pilotes.
En bref, tant que ça fonctionne, ne touche plus, mais si ça niaise de nouveau, tu auras quelques pistes avec lesquelles travailler.
Eric
C.T. a écrit :
Bonjour à tous,
alors voici comment j'ai résolu le problème d'affichage et d'accélération 3D pour le HP dc5750, un des ordinateurs normalisés de l'UdeM, plus quelques petites choses apprises en passant.
En suivant les instructions d'Éric, j'ai d'abord fait appel aux exécutables adaptés avant de tenter les solutions plus violentes.
En premier, j'ai exécuté EnvyNG et le laisser faire le sale travail d'installation des pilotes propriétaires ATI, initialisé comme indiqué avec la commande sudo aticonfig --initial -f qui s'est exécutée sans erreur, puis redémarré. C'est revenu en mode failsafe à 800x600@60Hz. Le fichier xorg.0.log indiquait avoir utilisé xorg.conf.failsafe. Conséquemment, le centre de contrôle ATI Catalyst refusait de se lancer puisqu'il détectait que le pilote fglrx n'était pas utilisé (avec raison).
En second, désinstallation, reboot, téléchargement du pilote officiel directement de chez ATI, puis installation selon leurs instructions (http://www2.ati.com/drivers/linux/linux_cat810-inst.html), sans oublier l'initialisation du xorg.conf avec sudo aticonfig --initial -f. Un reboot plus tard, toujours pas d'utilisation du pilote fglrx, utilisation du xorg.conf.failsafe.
En troisième, j'ai tenté la solution du runlevel 3, qui malheureusement n'existe pas sous Ubuntu, remplacé qu'il est par le "Recovery mode" de GRUB. J'ai sélectionné console root pour la suite, et tapé startx. Comme prévu, X n'a pas démarré, mais laissé une petite trace indiquant qu'une des sections de xorg.conf avec l'écran était incomplète ("no usable screen", qqch comme ça). Je n'ai pas plus de détails, n'ayant pas réussi à enregistrer le standard output dans un fichier texte, désolé. Comme Éric le pensait, ce log avorté est éliminé au boot suivant. J'ai donc rentré, en console root, aticonfig --initial -f, qui s'est terminée sans erreur, puis entré startx. Un bureau root est apparu (en anglais), et j'ai pu modifier la résolution avec ATI Catalyst. Ça a planté quand j'ai voulu redémarrer avec la GUI, j'ai redémarré en force, donc, puis refait la même manipulation sans lancer X, et redémarré de la console.
En quatrième, je me suis loggué normalement et changé la résolution avec ATI Catalyst. L'accélération 3D est revenue, le cube de bureau aussi. C'est résumé et paraît court comme ça, mais jai fait beaucoup d'erreurs, et probablement un tas de redémarrages inutiles.
Problèmes recontrés en cours de route:
la désinstallation des pilotes officiels selon les instructions d'ATI empêche de se logguer au redémarrage suivant. C'est un problème qui arrive tant qu'on n'ajoute pas xforcevesa comme paramètre de boot. L'autre manière est d'installer Ubuntu en spécifiant le mode vidéo sans échec. Cette fois, xforcevesa était toujours là, mais ça ne logguait quand même pas. Il a fallu sélectionner la "Session de secours GNOME", qui ne lit aucun script de démarrage. Là, la résolution est passé à 1024x768@75Hz, mais toujours sans accélération.
Toutes les manipulations avec EnvyNG 1.1.1 (installations, désinstallations, manuellement ou automatiquement) ont échoué. L'installation de EnvyNG lui-même ne donne pas les mêmes résultats avec apt-get et Synaptic.
L'installation de paquets générés par le script-archive de ATI pour Ubuntu a aussi échoué.
La seule conclusion que je vois est un manque flagrant de coopération entre le script-archive d'ATI et le fait qu'il s'attende probablement à être exécuté en session root, ce qui n'est pas normalement possible dans Ubuntu, que quelqu'un me corrige si je me trompe.
En espérant que ça aide d'autres contraints à utiliser cette machine retorse sous Ubuntu et que ATI tienne enfin compte des réalités de la distro la plus utilisée..
--- En date de : Jeu, 23.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit :
De: Eric Buist buisteri@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "C.T." semaphore45@yahoo.com, "Membres actifs du GULUM" gulum-team@iro.umontreal.ca
Date: jeudi 23 Octobre 2008, 13 h 28
Bonjour,
Le démarrage problématique me semble suivre le schéma suivant:
1. Démarrage avec xorg.conf, création d'un fichier log et crash
2. Tentative #2 avec xorg.conf.failsafe, création d'un fichier log et succès
Le fichier xorg.0.log correspond à ton démarrage fructueux d'où l'absence d'erreurs. Essaie de voir s'il n'y aurait pas d'autres fichiers xorg.log.
Si tu n'as pas le log, essaie de démarrer sur le niveau d'exécution 3 pour que GDM et X.Org ne démarrent pas. Ensuite, tu te branches en console et tu tapes startx. On va espérer que startx va essayer de démarrer avec xorg.conf, crasher et te laisser un fichier log puis NE PAS démarrer avec xorg.conf.failsafe. Je suppose ici que c'est un script dans GDM ou dans Ubuntu qui démarrent avec xorg.conf.failsafe; on va essayer de court-circuiter pour voir ce qui se passe.
Eric
C.T. a écrit :
Résumé court: X.org fait le zombie. J'ai fait cette manipulation, redémarré, et xorg.conf.failsafe a repoussé.
Y a-t-il une ligne précise dans les logs qui indiquerait ce qui se passe? Il n'y a pas d'erreur dans Xorg.0.log, il se contente de charger tout de suite .failsafe. Un extrait des premières lignes de log:
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
Current Operating System: Linux usager-AppMot2 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686
Build Date: 13 June 2008 01:08:21AM
[...]
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 23 08:38:13 2008
(==) Using config file: "/etc/X11/xorg.conf.failsafe"
(==) ServerLayout "Default Layout"
[...]
Je ne crois pas aux solutions hardcore, car cela a bien fonctionné pendant un bon moment! Je sais que les pilotes ATI sont loin d'être les meilleurs, mais ça fonctionnait néanmoins. Aucune raison que ça cesse.
--- En date de : Mer, 22.10.08, Eric Buist buisteri@iro.umontreal.ca a écrit :
De: Eric Buist buisteri@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca, semaphore45@yahoo.com
Date: mercredi 22 Octobre 2008, 22 h 43
Bonjour,
Le problème me semble lié à X.Org lui-même qui se mélange entre un fichier de configuration xorg.conf.failsafe qu'il ne devrait pas charger. Le plus simple me semble dans ce cas ceci:
cd /etc/X11
mv xorg.conf.failsave xorg.conf.failsafe.BACKUP
ln xorg.conf xorg.conf.failsafe
De cette façon, xorg.conf et xorg.conf.failsafe pointent exactement sur le même contenu. Si X.Org veut vraiment s'entêter à charger un fichier de configuration qui n'a pas de sens, eh bien on lui laisse faire ainsi, mais on ne va pas, nous, s'entêter à tenir en parallèle deux fichiers de configuration! :)
Si cela ne fonctionne pas, il ne reste plus que les solutions hard core. Le xorg.conf.failsafe étant peut-être un truc spécifique à Ubuntu, il faudrait essayer de recompiler et d'installer une version officielle de X.Org. J'avoue que c'est une solution qui n'a pas d'allure si bien que j'essaierais de changer de distribution avant.
Eric
C.T. a écrit :
Bonjour à tous encore, après des mises à jour (dont une de noyau) et un plantage, un mois après, le problème est revenu: la machine se sert toujours de xorg.conf.failsafe, et le recrée lorsqu'il n'est pas présent. Même en tentant de restaurer un des xorg.conf qui fonctionnait, il continue à utiliser la version failsafe. De son côté, fglrx est installé, ainsi que ATI Catalyst (en fait, ils n'ont pas bougé depuis un mois). Un passage avec aticonfig --initial -f sur un xorg.conf vide donne un xorg.conf certainement valide (tout comme xfix, normalement), mais que X refuse d'utiliser. Connaissant les problèmes souvent à la source de bugs mystérieux, j'ai passé un fsck -y en mode de récupération, puis redémarré en mode de récupération pour tenter un xfix. Toujours avec comme résultat une résolution trop basse, non accélérée. La partition système n'est pas pleine, ni le /home; il reste plusieurs Gio de libres. La première fois, ça s'est résolu d'une manière que je n'ai pas du tout comprise, malheureusement, d'où mon absence de réponse. Par contre, ça marchait très bien, avec le cube de bureau et tout. Comme ça marchait bien avec le pilote propriétaire, je pense que partir de là n'est pas une mauvaise idée.
Le problème n'a pas tant l'air d'être le contenu de xorg que son type... Après le plantage j'ai vérifié la date de modification de xorg.conf; elle n'avait pas changé (datée du 24 septembre), et pourtant, X ne l'utilise plus. Toute aide est bienvenue, même "hands on" (c'est au CEPSUM), que Pascal me pardonne cet anglicisme ;). Merci à tous PN
--- En date de : Mer, 24.9.08, Pascal Lamblin lamblinp@iro.umontreal.ca a écrit :
De: Pascal Lamblin lamblinp@iro.umontreal.ca
Objet: Re: [Gulum-team] Vid?o bugg?e sur ATI X300
À: "C.T." semaphore45@yahoo.com
Cc: "Membres actifs du GULUM" gulum-team@iro.umontreal.ca
Date: mercredi 24 Septembre 2008, 10 h 06
On Tue, Sep 23, 2008, C.T. wrote:
eh bien, ce changement de "virtual" size dans xorg.conf ne
semble
pas très concluant. Certes la résolution est montée jusqu'à 1280x1024 (1600x1200 étant bien trop élevé pour un 17" ;)), en 60Hz, mais la seule résolution inférieure est un 1024x768 à 85Hz, ce qui n'est pas possible sur cet écran.
Est-ce que tu connais le mode que tu préfèrerais et que ton écran supporte (celui que tu avais sous Windows, par exemple) ?
Dans la section "Monitor", tu peux définir différents modes, avec des paramètres qui provoqueront différentes fréquences d'affichage.
Exemple : modeline "1280x768@60" 80.14 1280 1344 1480 1680 768 769 772 795 -hsync +vsync
À partir des références de ton écran (ou de caractéristiques génériques), une page comme http://xtiming.sourceforge.net/cgi-bin/xtiming.pl devrait t'aider à trouver les bons paramètres.
Le nom de ta modeline devrait ensuite se retrouver dans Section "Screen" / SubSection "Display" / Modes.
Pendant ta phase de test, pour ne pas avoir à redémarrer X à chaque fois, tu peux aussi ajouter dynamiquement des modelines, et en changer, avec xrandr.
Exemple : xrandr --newmode "1400x1050@60" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 -q # Correspond à l'ajout dans "Monitor" xrandr --addmode VGA "1400x1050@60" # Correspond à l'ajout dans "Modes" xrandr --output VGA --mode "1400x1050@60" # Sélectionne ce mode
J'ai tenté de reconstruire xorg.conf à partir de la version .failsafe en ajoutant petit à petit les sections pertinentes à la résolution, ça n'a rien changé;
on dirait qu'il démarre tantôt avec
xorg.conf.failsafe, tantôt avec xorg.conf.
Est-ce que c'est non déterministe ? Parce que sinon ça ne m'étonne pas : quand il démarre avec xorg.conf, c'est que c'est bon ; quand il démarre avec xorg.conf.failsafe, c'est que tu viens d'ajouter un problème dans le xorg.conf. C'est ça qui devrait te permettre de détecter quels sont les ajouts dans xorg.conf qui posent problème.
Bonne chance,