Reprise du message précédent :
C'est l'option pour activer le trim automatique

Ok, merci, j'essaierai ça.

Faut vérifier que ton SSD supporte le trim à la volée, c'est pas le cas de tous, et si c'est pas le cas, ça peut provoquer des pertes de données.

pour ceux qui ont des vieilles amd radeon HD ( genre 4xxx ) et un vieux CPU ( type intel dual core Exxxx ) avez-vous remarqué des anomalies avec la dernière version de mesa 11.0.2 compilée avec llvm 3.7 ?

j'ai détecté un bug qui provoque un crash de l'application openGL dans certaines conditions ( fonction openGL glRasterPos2i(), et lorsqu'on utilise le mode de rendu 100% software avec la variable d'environnement "LIBGL_ALWAYS_SOFTWARE=1" ),

pour savoir si vous êtes touchés par le bug : installez le paquet "mesa-demos" et tapez "tunnel" dans une console, si vous avez un crash avec le message d'erreur "illegal instruction" alors vous avez le bug,

autre manière de tester: dans une console tapez : "export LIBGL_ALWAYS_SOFTWARE=1" puis lancez une application openGL ou "glxgears" depuis cette console, ça doit aussi planter,

après un long debogage j'ai trouvé le coupable : c'était les paquets "llvm" et "llvm-libs", la version 3.7 qui a servi à compiler mesa 11 provoque ce plantage quand on a une vieille carte graphique et un CPU assez vieux qui ne supporte pas certaines extensions intel récentes,

le moyen de contournement : downgrader llvm et llvm-libs vers la version 3.6.2, puis recompiler les paquets mesa,

j'ai crée un rapport de bug sur le site de mesa, et sur celui de llvm mais pas encore de solutions trouvées

Et ça se vérifie comment, ça ? C'est pour un SSD Samsung et un Plextor.

tout est indiqué dans le wiki archlinux :
 
https://wiki.archlinux.org/index.ph [...] IM_Support

Ha oui je suis bête, je l'avais vu enplus. Merci.

Salut,
 
Hier, mise à jour ; après je n´avais plus de réponse du tableau de bord de XFCE, plus moyen de démarrer thunar, etc. Il fallait que je parte, j´ai donc éteint sans plus m´inquiéter.
 
Ce matin, « boot loop » là-dessus (écran noir, affichage, etc.) :

 
Je me connecte sur un autre tty > reboot, même chose. Dans le doute je fais un pacman -Syu, toujours pareil. Je lis un peu ce que l´autre tty me dit :

 
Du coup, je réinstalle xorg-server, nvidia-libgl, lib32-nvidia-libgl ; reboot, ouf, xfce4 se lance. Par contre, plank ne démarre plus. Après recherches, je décommente ces lignes dans ~/.xinitrc :

 
Reboot, plank démarre mais toutes les icônes en .svg ne s´affichent plus   . J´ai donc fait un sudo /usr/bin/gdk-pixbuf-query-loaders --update-cache et ça refonctionne    
 
Une idée de pourquoi ça a cassé ? Il n´y a rien de spécial d´affiché sur la page d´accueil de arch.

c'est le problème classique d'une distribution rolling release, on se prend en premier les bugs des paquets récemment mis à jour

il n'y a pas assez de recul ( malgré les bêta-testeurs, les subterfuges type dépôt testing ), il peut toujours y avoir un problème qui n'aura pas été détecté par les développeurs ou les bêta-testeurs,

et certaines configurations logicielles ( combinaisons de paquets ) ne sont pas toutes testées ( ton plank je ne sais même pas ce que c'est ), parfois le bug ne peut se produire qu'avec une certaine configuration matérielle ( cf mon problème avec llvm 3.7 ),

vérifie aussi la santé de ton disque dur ( ou celui de ton système de fichiers si c'est quelque chose de pas très finalisé ), et le contenu des fichiers logs ( dmesg, journalctl, xorg ) s'il y a des infos intéressantes vis à vis de ton problème,

dans ta capture écran je vois une erreur liée au fichier /usr/lib/mesa/libGL.so.1 ( ou son lien symbolique /usr/lib/libGL.so ), xfce4 n'arrive pas à trouver ce fichier, vérifie que les paquets mesa soient bien installés

et passer ta swappiness a 1 si tu as mis de la swap, encore que sur les ssd modernes je sais pas trop si ça joue beaucoup

Mes options en btrfs: defaults,ssd,noatime,compress=lzo,space_cache,autodefrag (a part ssd ce sont les memes pour le reste... et ssd n'est pas necessaire je crois).
Pas de discard, j'ai lu pas mal d'articles qui recommandent plus d'utiliser le service fstrim a la place, comme quoi que discard est mauvais pour les performances.

Je viens de tester et pas de bug. Peut-être parce que j'ai une Radeon Mobility HD 4xxx (PC portable oblige) et pas une simple Radeon HD. Ou que mon CPU est un C2D P7450.

 
   
 
Plank, c´est le dock par défaut de elementary OS.
 
Le paquet mesa est bien installé. Par contre, en jetant un œil dans journactl, j´ai pu corriger deux erreurs : un mauvais paramètre pour fstab (j´avais mis auto et noauto sur un disque de sauvegarde qui n´est pas branché) et j´avais une erreur avec shadow.service qui cherchait l´utilisateur deluge alors que je n´ai pas deluge d´installé. Merci.
 
Sinon, le journalctl du boot loop c´était ça en incrémentant à chaque fois New session cXX :

 
edit : mon journalctl faisait 366Mo (les premiers logs dataient de mars), je l´ai amputé avec un coup de journalctl --vacuum-time=2weeks et limité en mettant SystemMaxUse=50M dans /etc/systemd/journald.conf comme indiqué dans le wiki.

 
AMHA, c'est un autre fichier car il dit shared library.
Donc ldd sur libgl pour voir ce qu'il manque.

Ça ressemble plus à des hooks mal exécutés... Mais c'est un peu flou cette histoire.

 
Voici la sortie de ldd /usr/lib/libGL.so (je ne connaissais pas cette commande) :

 
Pas de message d´erreur, tout est bon ?
 
Ça refonctionne, donc ne vous prenez pas trop la tête là-dessus, mais j´aurais aimé comprendre ce qui c´est passé.

On dirait oui.

dans le doute regarde les infos smart de ton disque dur avec smartmontools, et s'il te reste de la place dans ta partition "/"

 
J´ai encore 49% de libre sur / et smartctl short et long me disent que c´est OK, rien d´alarmant dans les smart (c´est un SSD au passage).
Il a 6056h de fonctionnement depuis juin 2011, il est tout neuf  

vous avez peut-être remarqué au fil du temps que pacman mettait un temps fou pour consulter les fichiers de sa base de données sur le disque ( notamment si vous avez un disque dur, je mets de coté le cas du SSD ), le délai entre le moment où on tape le "pacman -Syu" et celui où il affiche les paquets à mettre à jour peut être long,

il existe une astuce pour minimiser le problème :

https://wiki.archlinux.org/index.ph [...] ess_speeds

car tout est stocké dans /var/lib/pacman/, des simples fichiers textes et des fichiers textes compressés, d'où la lenteur, une solution peut-être serait que pacman utilise un SGBD comme base de données afin d'optimiser les accès, ou un système binaire pour stocker les infos plutôt que de s'appuyer sur des tonnes de fichiers texte qui ont l'inconvénient d'être sensibles à la fragmentation du système de fichiers,

une article de 2012 existe à ce sujet :

http://allanmcrae.com/2012/12/adva [...] se-format/

j'ai testé aussi sur un matériel encore plus ancien : un portable de 2003 avec un pentium 4 2.4 Ghz et une carte graphique radeon AGP M9 : pas d'erreur avec LLVM 3.7,

ça merde donc pour l'instant que sur mon PC de 2010 qui a un pentium dual core E6800 ( 3.33 ghz ) et une radeon HD4650 Pcie ( pilote libre : radeon, pilote mesa : r600 ),

j'ai testé aussi la version SVN de llvm ( revision 249579, c'est à dire la version 3.8 ), ça merde aussi sur la fonction glRasterPos2i(),

conclusion : je vais devoir sortir l'artillerie lourde : faire une sorte de git-bisect pour trouver dans quelle révision ce bug a été introduit, pour ensuite créer un patch qui annule cette modification, ça fera peut-être bouger les développeurs de llvm ( car toujours pas de réponse à mon rapport de bug )

Ton probleme est peut etre vraiment dans llvm mais une petite note:
Certaines fonctions dans mesa ne fonctionnent qu'avec une certaine version de LLVM minimales (pour AMD pas les autres), il n'est pas impossible que ton soucis viennent d'une de ses fonctions et qu'il te faut donc regarder mesa et non pas LLVM.
A tout hasard, as tu essaye une plus vieille version de mesa (ou git)?

oui j'ai essayé mesa 10.6 :

- mesa 10.6 + llvm 3.7 : le bug est là
- mesa 10.6 + llvm 3.6.2 : pas de bug, tout est ok

puis ensuite mesa 11.0.2 ( ainsi que la version git plus récente )

- mesa 11.0.2 + llvm 3.7 : le bug est là
- mesa 11.0.2 + llvm 3.6.2 : pas de bug, tout est ok

quand je dis "bug", ça veut dire bug à l’exécution d'un programme openGL, pas durant la compilation de mesa, et la machine où le bug se produit c'est avec ma radeon hd4650 pcie qui utilise le pilote r600 de mesa et avec un pentium dual core E6800,

quand le bug apparait il y a le message d'erreur "illegal instruction"

Mouais, ca peut toujours etre le couple llvm/mesa et pas juste llvm.
Quid d'un truc plus vieux genre 10.3 ou avant?
(de nouveau je note que je n'en sais rien, je dis juste que les 2 me paraissent faisable)

J'avais compris
Aussi vu que tu as une vieille carte sur r600g, as-tu le meme soucis avec sb?
D'ailleurs a quoi sert llvm pour r600g? je ne me rappelle plus trop.

qu'est ce que "sb" ?
 
j'essaierai une version encore plus ancienne de mesa pour voir s'il y a une différence

sb est pour est un autre backend pour shaders, pas d'AMD a la base, mais de si bonne qualite qu'inclu dans mesa. Je ne sais plus comment s'appele ce qu'il remplace.

à priori on peut activer SB via cette variable d'environnement :
 
export R600_DEBUG=sb
 
je vais faire le test

C'est ca.
 
Sinon sur ton bug, par rapport a la suggestion de Roland, as tu le paquet intel-ucode? Si non et que son idee est la bonne, ca pourrait peut etre aider.

oui j'ai bien le paquet intel-ucode,
 
je viens d'essayer le "export R600_DEBUG=sb", ça ne change rien avec mesa 11.0.2 + LLVM 3.7, il y a toujours le bug

Desole
Tente toujours 10.3, si toujours rien, j'acquiesce pour llvm.

de toutes façons dès que j'aurai trouvé le commit qui a introduit ce bug ça permettra d'en savoir un peu plus,

ce que je sais c'est que la version 3.6.2 ( compilée le 7 septembre dernier dans le dépôt archlinux ) est ok et que la version 3.7.0 a le bug ( version compilée le 29 septembre ), le commit fautif se trouve donc quelque part dans ce log :

https://github.com/llvm-mirror/llvm/commits/master

ok j’essaierai la 10.3 demain

C'est ce genre de choses auquelles je faisais allusion:

mais je n'arrive pas a trouver un truc du genre pour ta fonction opengl donc aucune idee.

Ah j'ai une autre idee pour toi, mais je ne sais pas si ca sera facile.
Compile llvm en 3.7.0 mais fais le passer pour 3.6.0 (aucune idee ou la version est inscrite mais surement dans peu d'endroits). De ce fait la, mesa ne devrait pas faire quoi que ce soit qui necessite plus de llvm 3.6.0 (meme si tu l'as en realite).
 
Enfin, j'espere que tu auras une reponse des devs, tu peux toujours ajouter Tom Stellard sur le bug llvm, c'est surement une des meilleurs personnes pour t'aider.

sb est activé par défaut. Essaie justement avec nosb.

je viens de tester avec "nosb", le bug est toujours là,
 
j'ai essayé aussi de recompiler glibc en supprimant l'option "--enable-lock-elision" pour vérifier l'hypothèse de Roland, peine perdue, le bug est toujours là,
 
la compilation de llvm est très longue, beaucoup plus longue que le noyau linux, ça rend donc le bisect très lent

Faut pas clean/recréer un paquet à chaque fois hein
Tu compiles à la main toi même et tu te démerdes avec le ldpath ou un preload pour charger ton llvm à la place du système entre chaque essai.
Sinon tu vas y passer la semaine...

j'utilise ccache et un PKGBUILD dans lequel je modifie la revision SVN à extraire

c'est un peu plus propre comme ça ( et plus simple ) et je pense que ça revient au même par rapport à ta technique

Bah non puisque tu dis que ça prend un temps fou à chaque fois.

je n'ai qu'un pentium dual core 3.33 Ghz, c'est pas un foudre de guerre, et pas de SSD,
 
ccache permet d’accélérer les choses mais uniquement lorsque la révision à compiler n'est pas très éloignée de la précédente compilation

non tu ferais
 
git bisect start xxxx
make
LD_PRELOAD=xxx test
git bisect good/bad
make
LD_PRELOAD=xxx test
 
Ca irait bien plus vite, que de devoir refaire la compilation entièrement, même si tu utilises ccache. Enfin bon c'est juste un conseil