Reprise du message précédent :
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

pas de risques que le make foire sans un "make clean" si la révision à tester est trop différente de la précédente ?

n'oublie pas que je devrais ensuite recompiler mesa avec cette version de llvm compilée manuellement, le ./configure de mesa essaiera de chercher la version de llvm installée, il va falloir qu'il cherche dans le bon dossier,

je connais pas ce truc du "LD_PRELOAD", je connais que "LD_LIBRARY_PATH", ça me rappelle de mauvais souvenirs quand j'étais sous une vieille mandrake et que j'essayais d'installer des choses ailleurs que dans /usr, l'impression de bricoler,

avec un PKGBUILD et ccache ça fait beaucoup plus propre, quand j'utilisais cette technique pour "bisecter" le noyau linux ça allait très vite

Si le makefile est bien écrit, non ça marchera comme il faut même sans clean.
Si le nom de la lib llvm change pas, et que mesa va la chercher en dynamique, pour moi t'as pas à recompiler mesa.

ok je tenterai ta technique pour voir la différence  
 
 

 
tu as peut-être mis le doigt sur quelque chose d'important, visiblement tu fais référence au fichier "configure" de mesa 11.0.2, dedans on y trouve ce test où il fait un choix en fonction de la version de llvm,
 
ce test n'existe pas dans les versions précédentes de mesa ( comme la 10.6.7 ),
 
je vais essayer de modifier ce fichier configure de mesa 11.0.2 pour lui imposer 'r600' au lieu de "amdgpu"

bon si je modifie ce fichier configure pour forcer 'r600' ça ne marche pas avec llvm 3.7.0, la compilation de mesa 11.0.2 échoue avec cette erreur :

on dirait que dans llvm 3.7 il n'y a que la possibilité "amdgpu",

et quand je compile une version de mesa inferieure à la 11.x avec llvm 3.7 la compilation échoue vers la fin :

on dirait que les versions de mesa inférieures à la 11 ne se compilent qu'avec llvm inférieure à 3.7 ( comme la 3.6.2 )

Oui, débugger llvm/mesa c'est un casse-tête à cause de ça

llvm utilise cmake, ce qui implique que la configuration est mise dans un sous-repertoire "build" et tout est compilé là dedans,

à chaque compilation d'une nouvelle révision de llvm il faudra bien reéxecuter le cmake pour la configuration générale, il risque de gueuler si le sous-repertoire "build" est déjà occupé par des fichiers issus de la précédente compilation

Ca m'étonnerait que les devs puissent pas faire des builds incrémentales...
Doit y avoir moyen, faut juste trouver comment

voici le script que j'utilise pour compiler selon ta technique manuelle ( sans passer par le PKGBUILD ), je suis en train de le tester actuellement :
 

 
ensuite je vais dans le répertoire "build" pour faire mon "make -j2" ( ccache étant déjà activé ), puis plus tard le "make install", et ensuite si j'ai bien compris je dois modifier la variable d'environnement "LD_LIBRARY_PATH" ou LD_PRELOAD avant de lancer un programme openGL de test
       

Non, ne fais même pas de make install. Pointe directement les .so qui ont été buildés avec LD_PRELOAD ou dans le ld lib path.

C'est normal.
amdgpu est juste le nouveau nom de r600 dans llvm.
Tu ne peux donc pas faire cette modification

Bonjour,
 
J'utilise un disque dur externe branché en USB3 (avec une carte expresscard) sur un Thinkpad x200. (Arch, 4.2.3, xfce)
Je rencontre un problème lors de l'éjection du disque, je clique d'abord sur "démonter", j'ai une notification m'indiquant que le disque est prêt à être débranché en toute sécurité mais cela n'arrête pas la rotation du disque   Donc j'entends un petit "clac" lorsque je le retire. Il manque un package ou autre pour faire ça proprement ?  
Sur OSX, je ne rencontre pas ce probleme, lorsque je clique sur "éjecter", j'entends distinctement le disque s'arrêter.
 
Merci  

 
la compilation de chaque révision de LLVM est vraiment trop longue avec mon vieux PC, même en utilisant ccache ou ta technique manuelle ( sans construire de paquet et sans faire de make clean ), du coup j'ai perdu espoir de trouver le commit qui a introduit le bug, surtout que certaines révisions sont boguées car la compilation échoue,
 
il est possible aussi que le problème ne soit pas lié à LLVM 3.7 mais plutôt à mesa 11.0.2 si ces développeurs utilisent mal les fonctions de LLVM ( erreurs avec des pointeurs par exemple ),
 
j'ai demandé alors sur le rapport de bug l'aide de quelqu'un qui s'y connait au niveau du pilote mesa r600, on a déjà un backtrace, on connait la manière de reproduire le problème, un développeur mesa spécialisé en pilote r600 devrait pouvoir trouver rapidement ce qui cloche

Arch c'est quand même pas toujours très clair. Je me suis rendu compte vendredi que j'utilisais encore l'ancienne version de la suite Kdepim (avec Akonadi, Kmail et toute l'usine), celle en "4.14". Or dans les dépôts, il y a les deux : la 4.14 et la 15.08, mais séparés. Exemple avec Kmail :  
 

 
Du coup je suis passé aux nouvelles versions versions (il y a un paquet "kde-kdepim-meta" qui contient tous les softs Kdepim en 15.08, mais pourquoi est-ce qu'il y a les 2 versions en parallèle ?
 
En plus, Kmail ne fonctionne pas super bien, il passe son temps à synchroniser mes dossiers Imap, en continu...

Tu le vois dans le nom du paquet: il y en a un qui appartient à KDE 4, et l'autre pour "KDE 5", qui est séparé en plusieurs projets ( https://en.wikipedia.org/wiki/KDE_S [...] rth_series ).

Oui mais je croyais qu'Arch avait droppé tout support de KDE 4 et ses dépendances... Voila pourquoi je m'étonnais de trouver ça dans les dépôts.
 
SInon, j'ai un autre souci, cette fois sur le portable de ma copine qui est sous Arch / Plasma 5 ; son ventilo souffle constamment. En faisant un "sensors" ça m'affiche que le CPU n'est jamais en-dessous de 55°C, même en idle, ce que je trouve un peu élevé quand même... J'ai essayé Powertop, laptop-tools, thermald, fancontrol, bref j'ai essayé tout ce que j'ai pu, pas moyen de faire descendre la température du CPU... C'est bizarre non ? Le dernier moyen à envisager est de démonter le laptop pour voir si les aérations sont bouchées...

La version 4 n'est plus maintenue depuis août (dernière version LTS sortie).

il y a probablement encore un paquet de monde qui reste sous KDE4 par choix personnel ( esthétique, ergonomie, les habitudes ) ou pour des raisons de stabilité/fiabilité ( mauvais échos sur le duo plasma5/KF5 )

peut-être que les fonctionnalités d'économie d'energie du CPU ne sont pas activées ( type intel speedstep où c'est le système d'exploitation qui ajuste à la volée la fréquence CPU ),

essaie de suivre le wiki pour vérifier si tout est ok à ce niveau :

https://wiki.archlinux.fr/Cpupower
https://wiki.archlinux.org/index.ph [...] cy_scaling

J'ai fait tout ça.
 
Le CPU, en idle, est à 933 Mhz (alors qu'il monte à plus de 2 Ghz en fréquence max). Et pourtant, même à 933 Mhz après 5 minutes sans rien faire, la température ne descend jamais en-dessous des 50 - 55°...

En plus le laptop est censé moins chauffer qu'avant, j'ai remplacé le HDD par un SSD...

c'est peut-être le module sensors qui a un bug, une mauvaise gestion de la sonde thermique, un mauvais étalonnage, du coup il t'affiche une température sur-estimée ?

sinon comme tu l'as évoqué c'est peut-être un excès de poussière qui empêche un bon refroidissement du processeur

 
Oui mais que faire, dans ce cas-là ?

dans le passé la température était correctement rapportée sous archlinux ?

ou le problème  existe depuis le début de l'installation d'archlinux ?

peut-être downgrader un paquet pour voir si le bug disparait, si oui tu pourrais alors ouvrir un rapport de bug

Je crois que c'est depuis le début. EN REVANCHE avant Arch, il y avait ElementaryOS sur cette machine, et il me SEMBLE que le portable était souvent silencieux, donc la témpérature était mieux gérée. Il me semble en effet que dès le boot, arrivé au Login Manager d'eOs, le portable devenait complètement silencieux. Il faudrait que je reteste avec un LiveCD EOS.

ou peut-être essayer la version LTS du noyau linux

je patauge toujours avec mon problème mesa/llvm-libs 3.7.0, la solution n'a toujours pas été trouvée,

ce qui m'arrangerait c'est de savoir si je suis le seul ou pas à avoir ce bug,

les conditions du bug :

1) installer mesa 11.0.3 ( llvm-libs 3.7.0 sera installé comme dépendance )

2) utiliser le pilote r600, pour le savoir tapez dans une console : cat /var/log/Xorg.0.log | grep r600

vous aurez cette sortie avec la mention "r600", le fichier "/usr/lib/xorg/modules/dri/r600_dri.so" sera utilisé, ce fichier utilise libLLVM.so ( on peut le voir en utilisant la commande ldd )

certains pilotes ( r200, i915 ) n'utilisent pas libLLVM, donc vous n'aurez pas le bug avec ces pilotes ( mon PC portable pentium 4 2.4 Ghz qui utilise une vieille radeon 9000 AGP n'a pas ce bug )

3) avoir de préférence une vieille carte graphique type radeon HD4650, et peut-être un CPU ancien type pentium dual core E6800

4) le bug se produit avec flightgear 3.4 ( dès les premières secondes ), sur le programme "tunnel" du paquet mesa-demos, les programmes qui utilisent la fonction openGL glRasterPos2i(), et lorsqu'on active volontairement l'émulation 100% software ( export LIBGL_ALWAYS_SOFTWARE=1 ), une erreur "illegal instruction" ( opération non permise ) sera affichée, le programme va se crasher

5) si mesa 11.0.3 est compilé pour être linké avec LLVM 3.6.2 alors pas de bugs, tout sera ok, mais si c'est la version 3.7.0 alors le bug va se produire

à noter que j'utilise KDE4 ( qui n'est plus maintenu ), dans le doute pour écarter la possibilité d'un bug de KDE4 j'ai essayé dans un environnement hors KDE avec une session xterm --> le bug est toujours présent,

le backtrace du débogueur gdb s'arrête sur cette fonction de glibc ( ici le programme débogué est "tunnel" de mesa-demos ) :

4 possibilités :

- le bug est dans mesa 11.0.3 ( mauvaise initialisation de LLVM 3.7.0 )
- le bug est dans LLVM 3.7.0
- le bug dans glibc
- le bug est dans le PKGBUILD de LLVM d'archlinux ( une option de compilation inadéquate pour le ./configure, des patchs hasardeux car dans le PKGBUILD on voit plein de patchs qui sont utilisés )

le feuilleton continue donc, j'espère que la solution finira quand même par être trouvée

j'ai réussi à reproduire le bug mesa/llvm 3.7.0 dans une machine virtuelle qemu, l'OS guest est archlinux, cette fois en version i686,

dans cette machine virtuelle ce n'est pas le driver mesa r600 qui est utilisé, mais le driver swrast_dri.so ( ici pas d'acceleration 3D, mais uniquement du 100% software ),

dans cette machine virtuelle tous les programmes openGL plantent avec la même erreur ( illegal instruction ), c'est donc encore pire que dans mon OS host archlinux 64 bits,

le backtrace de gdb est similaire :

si je downgrade vers LLVM 3.6.2 et que je recompile mesa alors le bug disparait,

qu'en pensez-vous ?

peut-être un problème purement archlinux, ou un bug de glibc ?

Tu peux toujours installer les paquets dbg et voir dans quelle(s) fonction(s) ca plante et regarder les commits qui l(es) affectent.

Pour les bt de gdb c'est souvent la 1ere chose a faire

j'ai déjà utilisé la version debug de mesa et glibc ( c'est dans le rapport de bug sur le site de mesa ),
 
pour les breakpoints je ne sais pas où les placer dans le code source de mesa,
 
tout ce que je sais c'est que le programme crash quand il arrive dans une fonction de glibc lié à la gestion des processus :
 
#1  0xb7a7da2b in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
 
ce qui me gène c'est que je suis le seul à avoir ce bug ( qui se déclenche notamment en utilisant le mode 100% software, "export LIBGL_ALWAYS_SOFTWARE=1" ),  
 
si je suis le seul alors c'est peut-être un bug de glibc qui ne se produit qu'avec un certain type de CPU, le genre de bug qui existe déjà pour certains processeurs Haswell, il y a plein de rapports de bug de ce type dans le bugzilla de glibc
 
https://sourceware.org/bugzilla/show_bug.cgi?id=18729
https://sourceware.org/bugzilla/show_bug.cgi?id=17013
 
mais j'ai aucun moyen de le prouver, j'ai voulu downgrader la version de glibc vers la version 4.9, ça semble impossible, car il faudrait aussi downgrader gcc-multilibs et plein d'autres paquets, avec pacman qui gueule à chaque fois en disant qu'il y a des problèmes de dépendances insolvables    
 
 
 

glibc c'est assez galere oui, tu peux toujours installer une iso d'arch plus ancienne dans ta VM, mais je ne sais pas si tu pourras mettre a jour tous les paquets sans mettre a jour glibc...

J'ai relu ton bug mesa, la phrase d'Alex me parait pertinente.
Et ta reponse encore plus:

Es-tu sur d'utiliser le pilote radeon?
llvmpipe c'est come swrast, c'est uniquement le CPU.

oui c'est sûr j'utilise le pilote radeon,

le "OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)" c'est uniquement quand j'active le mode "100% emulation software" ( export LIBGL_ALWAYS_SOFTWARE=1 ),

fais le test en modifiant cette variable d'environnement, tu verras que tu auras la même chose quand tu retapes "glxinfo", c'est dans ce mode quand le bug apparait notamment ( l'autre cas où le bug apparait chez moi c'est avec le programme "tunnel" et flightgear et là je n'ai pas activé le mode 100% software )

si je ne tape pas "export LIBGL_ALWAYS_SOFTWARE=1" alors dans le glxinfo je peux lire ça :

dans le feu de l'action j'ai dû me tromper dans la réponse à Alex en faisant un mauvais copier coller,

enfin dans la machine virtuelle qemu c'est le mode 100% software qui est utilisée vu qu'il utilise le driver swrast, d'où le "OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)"

Oh je vois.
 
Ca me parait un brin bizarre tout de meme, car si j'ai bien compris tu as le meme soucis avec:
- radeon
- llvmpipe
- swrast
 
Mais le 1er et le dernier n'utilisent pas llvm pour la 3d (enfin je crois).
Bonne chance!

d'après la réponse sur le rapport de bug le pilote r600 utilise quand même llvm pour certaines choses :

le "few extremely rare things like GL_SELECT" explique peut-être pourquoi ça plante sur la fonction "glRasterPos2i()" si le pilote r600 appelle llvm pour réaliser cette fonction ( cas où ma carte graphique radeon hd4650 pcie ne supporterait pas cette fonctionnalité )

flightgear utilise cette fonction openGL "glRasterPos2i() et c'est pour ça que ça plante,

les autres jeux 3D ne plantent pas sur mon PC avec le pilote r600 ( Xonotics, Nexuiz, et un jeu windows qui tourne sous wine : LFS, une jeu de course de voitures ), ils n'utilisent probablement pas la fonction glRasterPos2i() ou des trucs qui feraient appel à llvm,

et bien sûr dès qu'on active volontairement le mode 100% software là ça plante à tous les coups,

conclusion : ça peut être llvm 3.7.0 qui merde si dedans il y a du code spécialisé bogué pour les pentium dual core ( vu que llvm 3.6.2 ne plante pas du tout ),

ou bien glibc ( mais ça ne colle pas vu qu'il devrait planter aussi sur d'autres applications, et il ne plante pas avec le duo mesa/llvm en version 3.6.2 )  

Oh je ne savais pas pour GL_SELECT.
J'ai regarde vite fait, mais je ne sais pas trop de quelle version d'OGL date cette fonction, donc impossible de savoir si ta carte la supporte ou pas.
Remarque avec Raster dans le nom... peut etre est-ce toujours software...

dans mon grenier j'ai un vieux PC de marque que j'ai récupéré, il a un CPU amd athlon 64 ( mono core ), une carte mère de 2006 avec un slot Pcie pour carte graphique,
 
il pourrait servir de test en installant ma carte radeon HD4650 dessus, puis archlinux, ce qui permettrait de savoir si le bug est reproductible avec un CPU amd,
 
un test à réaliser en dernier recours si les développeurs de mesa ne trouvent pas l'origine du bug ( la flemme de remonter ce PC )
 

Pas une mauvaise idee!

j'ai encore fait une découverte intéressante :

dans qemu on peut préciser le type de CPU à émuler, jusqu'ici j'utilisais l'option "-cpu host" qui permettait de reproduire exactement le CPU de l'OS host ( mon pentium dual core E6800 ),

par curiosité j'ai alors changé le type de CPU en mettant dans mon script qemu :

Et bingo ! Le bug a disparu quand je relance ma machine virtuelle, mesa/llvm 3.7 ne plante plus,

j'ai ensuite fait un autre test en mettant cette fois comme cpu :

Penryn est le nom de code d'un autre type de cpu core 2 duo : Intel Core 2 Duo P9xxx (Penryn Class Core 2 ), et là cette fois ça plante avec mesa/llvm 3.7, le bug est de retour,

je pense donc que le problème vient de la librairie llvm 3.7.0, c'est une sorte de générateur de code machine en fonction du CPU, il est probable que dans le code source de llvm 3.7.0 il y ait un bug pour certains CPU,

c'est cohérent quand j'y réfléchis, j'ai regardé la doc de mesa et leur driver llvmpipe leur sert à générer du code binaire à la volée en fonction du CPU, ou alors c'est mesa qui initialise mal la librairie llvm 3.7.0,

edit : un tutoriel intéressant ici pour apprendre à utiliser la librairie llvm :
https://pauladamsmith.com/blog/2015 [...] c-api.html

le code source indiqué n'est plus adapté à llvm 3.7 ( les noms des fonctions ont un peu changé ) mais c'est intéressant pour comprendre le principe,

pour en revenir à mesa 11.0.3 il est possible que l'API llvm ait changé depuis la 3.7.0 et qu'il faille ajouter quelques instructions pour être sûr que la cible ( le CPU ) soit bien identifiée ( genre des fonctions   LLVMInitializeNativeTarget() et  LLVMInitializeNativeAsmPrinter() ), c'est ce que disait un peu Roland dans le rapport de bug mais sans trop s'avancer

Vu que llvm est compile avec gcc, ca peut aussi etre un bug gcc ou glib
Faudrait voir en compilant llvm avec clang, si c'est mieux (ca serait plus rapide d'ailleurs) mais je ne sais pas si on peut compiler mesa avec clang...
Mais dans tous les cas, felicitations pour le progres!

j'ai justement compilé llvm avec clang en guise de test il y a quelques jours
et j'avais malheureusement toujours le bug,
 
puis j'ai essayé de compiler mesa avec clang mais ça plante au niveau du ./configure, un patch existe pour pouvoir compiler mesa avec clang mais j'ai pas encore testé, apparemment sur le bugzilla de mesa les développeurs n'aiment pas trop qu'on compile mesa avec clang, ils disent que clang n'est pas encore très mature et que des bugs peuvent apparaitre sur les programmes compilés par clang,
 
il est possible que le bug soit lié à glibc ou gcc, le souci c'est que le bug devrait alors être aléatoire ou se produire avec d'autres programmes, de plus ça toucherait beaucoup plus de monde vu la position centrale qu'occupe glbic/gcc dans l'écosystème linux
 
ceci dit dès que les distros linux grand public type ubuntu/fedora auront dans leurs dépôts officiels les dernières versions de llvm/mesa/glibc/gcc il est possible que je ne sois alors plus le seul à être touché par ce bug
 
ubuntu a une plus grande part de marché qu'archlinux, ce qui augmente la probabilité d'avoir des gens qui ont à peu près la même config que la mienne ( un cpu ancien )

Petit update : en fait, je me suis rendu compte hier soir que les ventilos, après avoir booté sur Arch, se calment, le laptop devient silencieux, c'est parfait. Et la température au démarrage est à 30° plus ou moins.

Le problème, c'est que le portable chauffe, petit à petit, au fur et à mesure et même en idle. Pour finir sur 55  - 60° et ne plus refroidir. Je pense que c'est l'agencement même du laptop qui le fait chauffer, tout bêtement. C'est un HP G62 qui date de ~2010 avec un Core i3 de 1e génération, ceci expliquant peut-être cela...