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
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
_______________________________________________
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!
|