anakin a écrit 256 commentaires

Et le coupable semble être l'appli "Affichage" de XFCE car hier je suis allé dedans pour vérifier certains paramètres (et curieusement j'avais toujours un moniteur CRT qui apparaissait) et là au boot suivant, idem, écran noir. Du coup j'ai refait la manip de rebuild du driver et cette fois j'ai viré les sections screen, device et monitor du CRT dans le xorg.conf. Bizarre tout ça…

Visiblement, le problème s'est résolu tout seul…lorsque j'ai rebuildé les pilotes catalyst (via catalyst_build_module)…. chose que j'ai du faire en montant le disque dur sur un autre ordi pour démarrer (car GDM s'était cassé suite à une mise à jour récente de libpng).

Pour en revenir à cette histoire de CRT dans les logs. Je suis remonté à de vieux log de Xorg.x.log et effectivement, c'est depuis récemment que j'ai cette suite de message :
Un grep EDID Xorg.0.log (du dernier boot donc) renvoie :

[    22.967] (II) fglrx(0): Display0 EDID data ---------------------------
[    22.967] (II) fglrx(0): EDID Version: 1.3
[    22.967] (II) fglrx(0): EDID (in hex):
[    22.967] (II) fglrx(0): End of Display0 EDID data --------------------
[    22.967] (II) fglrx(0):  Display1: Failed to get EDID information. 
[    23.030] (II) fglrx(0): EDID for output LVDS
[    23.030] (II) fglrx(0): EDID Version: 1.3
[    23.030] (II) fglrx(0): EDID (in hex):
[    23.031] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    23.031] (II) fglrx(0): EDID for output DFP1
[    23.031] (II) fglrx(0): EDID for output DFP2
[    23.031] (II) fglrx(0): Cannot get EDID information for CRT1
[    23.031] (II) fglrx(0): EDID for output CRT1
[    28.214] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    28.292] (II) fglrx(0): Cannot get EDID information for CRT1
[    29.794] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    29.872] (II) fglrx(0): Cannot get EDID information for CRT1
[    60.009] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    60.088] (II) fglrx(0): Cannot get EDID information for CRT1
[    61.942] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    62.021] (II) fglrx(0): Cannot get EDID information for CRT1
[    64.588] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    64.944] (II) fglrx(0): Cannot get EDID information for CRT1
[    65.897] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    68.852] (II) fglrx(0): Cannot get EDID information for CRT1
[    68.967] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    69.048] (II) fglrx(0): Cannot get EDID information for CRT1
[    69.464] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    69.632] (II) fglrx(0): Cannot get EDID information for CRT1
[    70.215] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    70.427] (II) fglrx(0): Cannot get EDID information for CRT1
[    76.542] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    76.624] (II) fglrx(0): Cannot get EDID information for CRT1
[    76.985] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    77.466] (II) fglrx(0): Cannot get EDID information for CRT1
[    77.695] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[    77.782] (II) fglrx(0): Cannot get EDID information for CRT1
[   664.999] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[   665.077] (II) fglrx(0): Cannot get EDID information for CRT1
[   665.107] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[   665.187] (II) fglrx(0): Cannot get EDID information for CRT1
[   665.210] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[   665.289] (II) fglrx(0): Cannot get EDID information for CRT1
[  1199.519] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[  1199.598] (II) fglrx(0): Cannot get EDID information for CRT1

Alors que sur un plus vieux log :
grep EDID Xorg.2.log

[ 13036.536] (II) fglrx(0): Display0 EDID data ---------------------------
[ 13036.536] (II) fglrx(0): EDID Version: 1.3
[ 13036.536] (II) fglrx(0): EDID (in hex):
[ 13036.536] (II) fglrx(0): End of Display0 EDID data --------------------
[ 13036.649] (II) fglrx(0): EDID for output LVDS
[ 13036.649] (II) fglrx(0): EDID Version: 1.3
[ 13036.649] (II) fglrx(0): EDID (in hex):
[ 13036.649] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13036.649] (II) fglrx(0): EDID for output DFP1
[ 13036.649] (II) fglrx(0): EDID for output DFP2
[ 13036.650] (II) fglrx(0): EDID for output CRT1
[ 13038.856] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13040.206] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13083.619] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13084.715] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13084.736] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13086.697] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13086.937] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13087.101] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13088.581] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13089.906] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13090.343] (II) fglrx(0): EDID vendor "LGD", prod id 55297
[ 13090.785] (II) fglrx(0): EDID vendor "LGD", prod id 55297

J'ai l'impression que la carte graphique "croit" qu'un moniteur CRT est connecté. En faisant un grep Connected Xorg.* on voit clairement un Display1 qui apparaît…et pourtant aucun écran n'est branché…

Xorg.0.log:[    22.967] (II) fglrx(0): Connected Display0: LVDS
Xorg.0.log:[    22.967] (II) fglrx(0): Connected Display1: CRT1
Xorg.0.log.old:[    24.460] (II) fglrx(0): Connected Display0: LVDS
Xorg.0.log.old:[    24.461] (II) fglrx(0): Connected Display1: CRT1
Xorg.1.log:[   126.330] (II) fglrx(0): Connected Display0: LVDS
Xorg.1.log:[   126.331] (II) fglrx(0): Connected Display1: CRT1
Xorg.1.log.old:[  8442.982] (II) fglrx(0): Connected Display0: LVDS
Xorg.2.log:[ 13036.536] (II) fglrx(0): Connected Display0: LVDS
Xorg.2.log.old:[  2506.041] (II) fglrx(0): Connected Display0: LVDS
Xorg.3.log:[  4312.576] (II) fglrx(0): Connected Display0: LVDS
Xorg.3.log.old:[  8849.325] (II) fglrx(0): Connected Display0: LVDS
Xorg.4.log:[  9196.693] (II) fglrx(0): Connected Display0: LVDS
Xorg.5.log:[ 27079.174] (II) fglrx(0): Connected Display0: LVDS
Xorg.5.log.old:[ 13581.341] (II) fglrx(0): Connected Display0: LVDS

Bizarre oui…mais je n'arrive plus à avoir ces logs là maintenant…;
Effectivement, ça ressemble à un problème semi matériel, un truc corrompu dans le BIOS de la carte graphique peut être…mais j'ai encore espoir étant donné que l'écran fonctionne toujours en mode normal….c'est juste que ça va devenir très gênant lorsqu'il faudra accéder au BIOS et ou démarrer en mode de secours.

En tout cas, en branchant un moniteur externe sur la prise VGA, impossible d'étendre le bureau sur les deux écrans…pourtant l'écran est bien détecté, mais il reste vide tout le temps, comme si le signal envoyé sur la sortie VGA n'était pas bon.

Lorsque j'essaye d'accéder à un TTY, l'écran s'éteint…
Il me semble que c'est en vrai mode texte car j'utilise les pilotes proprio de toute façon. Comment savoir ?
Voici les logs du Xorg.0.log lorsque je switch vers un tty et que je reviens vers l'écran de X :

[ 23885.701] (II) fglrx(0): Cannot get EDID information for CRT1
[ 26856.597] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 26856.619] (II) fglrx(0): Backup framebuffer data.
[ 26856.681] (II) fglrx(0): Backup complete.
[ 26867.753] (II) AIGLX: Resuming AIGLX clients after VT switch
[ 26867.897] (II) fglrx(0): User Preference Output LVDS using refresh rate 60.0 Hz.

En fait j'arrive bien à changer de résolution via xrandr..

N'oublions pas que soutenir SFR/Vivendi/Universal c'est soutenir le financement du DPI proposé par Vivendi et son président qui tient des propos complètement aberrant.

J'ai une interrogation par rapport à SIP. SIP permet chez certains opérateurs d'appeler des numéros de téléphones classiques (d'où son utilisation dans les box des FAI ?). Est-ce qu'il serait techniquement possible un jour de pouvoir faire la même chose avec jingle ?

Aussi que penser de P2P SIP (http://www.p2psip.org/) et de GNU Free Call (http://www.gnutelephony.org/index.php/GNU_Free_Call_Announcement) ?

Bon certains caractères sont passé à la trappe, la correction :
*351*<numéro>#

Sur une Freebox, il suffit de faire 351# pour insérer un numéro ou un préfixe à la liste de filtrage des appels entrants. Il y a peut être l'équivalent chez SFR ?

Il y aussi ce site http://www.securite-informatique.gouv.fr/autoformations/signature_elec/co/mod01_chap01.html qui est pas mal je trouve, avec des animations bien faites et claires pour expliquer aux débutants les principes de base.

Sera-t-il possible un jour de pouvoir éditer un commentaire posté sur le forum ?

Sauf que si une clé est perdue dans la chaîne tout est mort....
Alors qu'avec le code de Shamir, on peut tolérer la "mort" de certaines clés.

Pas mal ce Shamir Code, en plus d'après ce que j'ai lu, l'idée derrière est vraiment élégante et simple (interpolateur de Lagrange).
Donc en gros, ca servirait plutôt à découper la phrase de passe de la clé privée (car la clé privée en elle même ce serait trop gros).

Ne serait-il pas possible d'avoir des certificats de plusieurs autorités de confiance (indépendantes entre elles naturellement) ? Ainsi la vérification se ferait sur plusieurs autorité ce qui réduit le risque de compromission.
Ou alors, c'est comme lorsqu'on on chiffre un message avec les clés publiques des destinataires, il suffit que la clé d'un seul destinataire soit compromise pour pouvoir lire le message. Je ne sais pas d'ailleurs si cela existe, le fait de pouvoir chiffrer un message avec des clés publiques et ne pouvoir les déchiffrer que simultanément avec les clés privés de tous les destinataires (mais encore faudrait-il pouvoir réunir les clés privés à un instant donné pour le déchiffrage) ; un peu comme si c'était un coffre avec plusieurs clés répartis chez plusieurs personnes, ainsi l'information ne pourrait s'obtenir qu'avec la compromission de TOUS les possesseurs de clés alors que maintenant, il suffit d'UN seul possesseur de clé pour déchiffrer.

Je viens de voir que g et GG fonctionne comme dans vim sur les pages...pas mal ;)

Ok c'est bon ca marche, en fait le Makefile utilisait sa propre variable pour gcc, EXTRA_CFLAGS. Du coup, j'ai cherché l'initialisation de cette variable, elle apparaît dans le Makefile principal (qui appelle ensuite les autres en cascade, donc la variable est bien transmise), un coup de sed pour rajouter le -D'printk(...)=' et plus aucun printk n'apparaît dans les binaires .o (et donc je suppose à l'exécution que ca n'apparaîtra pas non plus, je testerai ça plus tard).
Merci

Oui ça doit être ça, car je viens de voir qu'il y a plusieurs Makefile et que des flags sont définis aussi ailleurs dans les Makefile, du coup le la variable CFLAGS n'est peut être pas prise en compte. J'essaye de tout comprendre là pour essayer de voir où je pourrais modifier...

Tu veux peut être parler de faire un grep sur les binaires intermédiaires .o ?

Attend, je n'ai pas très bien saisi là.

Mon exemple concret justement c'était qu'au niveau de l'exécution, les printk s'affichaient toujours après avoir rajouté CFLAGS=`echo $CFLAGS`" -D'printk(...)='" dans mon PKGBUILD juste avant le make.

Mais là tu m'expliques tu as un fichier source généré ?
C'est à dire que ta commande
gcc -D'printk(...)='
tu l'exécutes sur du code source et tu obtiens un autre fichier source sur lequel tu fais un grep et qui n'affiche plus les printk ?

Comment utilises-tu ta commande sur le fichier exemple que j'avais donné ?

Essaye sur le code du driver complet : http://www.nd.edu/~pbui/scratch/aur/rtl8192se_linux_2.6.0019(...)

Mais il faut une carte wifi compatible pour voir si ca marche ou pas (en regardant la sortie /var/log/kernel.log)

Essaye peut être sur l'ensemble du code du driver http://www.nd.edu/~pbui/scratch/aur/rtl8192se_linux_2.6.0019(...) Mais pour voir si ca marche ou pas, il faut avoir une carte wifi compatible et regarder les messages de /var/log/kernel.log

Ne marche pas sur le code complexe du driver malheureusement...
Peut être pour les mêmes raisons qui fait que spatch ne marche pas non plus.

Voici un fichier ( http://pastebin.toile-libre.org/?show=608376 ) sur lequel je n'arrive pas à trouver de règle spatch qui matche tous les printk, et je ne comprend pas pourquoi ca fait ça, car parfois il matche une ligne et pas une autre et rien ne diffère....
Au mieux (avec les règles citées au dessus) il ne trouve que 5 printk sur 20...

Ah pas bête merci, si j'ai bien compris, ca veut dire qu'une "ligne" est redéfini par ce qu'il y a entre 2 ";" et donc dans ce cas, si on trouve une "ligne" contenant printk, on est sûr qu'elle ne contient qu'une seule instruction ?
Mais est-ce que ça "résiste" au retour à la ligne ?