[mesa] des crashs avec le duo mesa 11.0.3 - llvm-libs 3.7.0

[Elbarto]

Bonjour,

j'utilise archlinux 64 bits, cpu : pentium dual core E6800, ram : 4 Go, carte graphique : amd radeon HD4650 pcie, bureau : KDE 4.x

depuis que les paquets mesa ( 11.0.3 ) et llvm-libs ont été mis à jour je constate un problème :

- des applications openGL peuvent crasher avec l'erreur "illegal instruction" ( instruction non permise ), par exemple le programme "tunnel" du paquet mesa-demos

- l'erreur se produit notamment quand mesa veut utiliser le mode émulation software 100% ( cas où le driver de la carte graphique ne supporterait pas une fonction openGL ) et systématiquement quand on demande volontairement le mode 100% émulation software ( variable "export LIBGL_ALWAYS_SOFTWARE=1" )

le moyen de contournement que j'ai trouvé : downgrader llvm et llvm-libs vers la version 3.6.2, puis recompiler les paquets mesa 11.0.3 ( avec gcc ) afin que ces paquets soient linkés à la librairie llvm 3.6.2 ( indispensable de faire ça afin d'éviter qu'il ne cherche llvm 3.7.0 ), avec ce contournement il n'y a aucun bug, tout est ok,

j'arrive aussi à reproduire ce bug dans une machine virtuelle archlinux i686 avec qemu, dans cette machine virtuelle c'est le driver swrast_dri.so de mesa qui est utilisé ( émulation 100% software ), du coup tous les programmes openGL plantent,

j'ai fait un débogage avec gdb et il apparait que ça plante sur une fonction de glibc ( pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 )

Code : Tout sélectionner

(gdb) thread apply all bt full
 

Thread 2 (Thread 0x7fffee4c6700 (LWP 11292)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x00007ffff22fe04a in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
No symbol table info available.
#2  0x00007ffff22fd787 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
No symbol table info available.
#3  0x00007ffff3d74464 in start_thread (arg=0x7fffee4c6700) at pthread_create.c:334
        __res = <optimized out>
        pd = 0x7fffee4c6700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737191372544, -3511726595263618993, 0, 140737488345551, 3,
                140737488348064, 3511694852238942287, 3511735595139276879}, mask_was_saved = 0}}, priv = {pad = {0x0,
              0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#4  0x00007ffff704d13d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
 

Thread 1 (Thread 0x7ffff7f9a740 (LWP 11286)):
#0  0x00007fffedaa55eb in ?? ()
No symbol table info available.
#1  0x000000000076a320 in ?? ()
No symbol table info available.
#2  0x00007fffffffd630 in ?? ()
No symbol table info available.
#3  0x0000000000000007 in ?? ()
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#4  0x0000000000000000 in ?? ()
No symbol table info available.

j'ai crée un rapport de bug sur le site de mesa :

https://bugs.freedesktop.org/show_bug.cgi?id=92214

mais aucune solution n'a été trouvée et on dirait que je suis le seul à avoir ce problème

peut-être est-ce un bug de glibc 2.22-3 qui ne se produit que sur les CPU pentium dual core E6800 ?

[benjarobin]

Bonsoir,
Comme idée j'ai ceci à proposer Microcode
Peux tu donner la sortie de, il n'est pas nécessaire que tu installes intel-ucode, je pourrais te dire si tu as besoin d'une mise à jour

Code : Tout sélectionner

dmesg | grep microcode

[Elbarto]

Bonsoir Benjarobin,

j'utilise déjà le paquet intel-ucode, et à une époque j'avais même incorporé dans mon bios la dernière version du microcode pour le processeur pentium dual core E6800, puis reflashé le bios avec cette version modifiée, tout s'était bien passé, l'écran du bios m'affichait bien la dernière revision du microcode

la sortie dmesg | grep microcode

Code : Tout sélectionner

$ dmesg | grep microcode
[    0.226517] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[    0.226520] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b
[    0.226615] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

à noter que mon processeur date de 2010, je ne sais pas si intel continue encore à proposer des mises à jour de microcode pour ce processeur

[Elbarto]

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

avec la machine virtuelle qemu que j'utilise 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 :

Code : Tout sélectionner

-cpu core2duo -enable-kvm  -machine type=pc,accel=kvm -smp 2

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 :

Code : Tout sélectionner

-cpu Penryn -enable-kvm  -machine type=pc,accel=kvm -smp 2 \

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,

faudrait que quelqu'un reproduise mon test avec qemu pour confirmer mon hypothèse,

je rappelle que j'ai aussi le bug au niveau du host ( mon PC sous archlinux 64 bits ), et là le seul moyen de contournement est de downgrader les paquets llvm vers la version 3.6.2 et de recompiler mesa pour qu'il soit lié à la version 3.6.2 de llvm-libs ( tout en commentant la ligne "sed -i 's/LLVM_SO_NAME=.*/LLVM_SO_NAME=LLVM/' configure" du PKGBUILD de mesa pour que ça puisse compiler avec llvm-libs 3.6.2, ce patch est présent uniquement pour la version 3.7.0 qui utilise un nom de librairie différent d'où le "sed" )

[benjarobin]

J'ai vu la suite de ton rapport de bug, c'est un peu dommage de "gaspiller" autant d'énergie pour résoudre le problème. Il y a personne pour t'indiquer quoi faire, et désolé mais tu pars un peu dans tous les sens, sur des hypothèses plus folle les une que les autres...
Alors que c'est relativement simple pour trouver le bug. Tu dois faire 2 choses sur la lib llvm : un bisect et compiler avec les symboles de debug

PS : Tu es bien à jour question ucode

[Elbarto]

Tu dois faire 2 choses sur la lib llvm : un bisect et compiler avec les symboles de debug

plus facile à dire qu'à faire,

créer une version debug de llvm nécessite un espace disque gigantesque ( plusieurs giga-octets ) et un temps fou de compilation,

avec mon vieux PC faire un bisecting sur llvm est une terrible épreuve car la structure du projet llvm est une vraie usine à gaz, chaque compilation d'une révision SVN de llvm prend un temps fou, même en utilisant ccache ou en évitant de faire un make clean ( quasiment 2 à 3 heures sur mon PC le temps de compilation ), d'une révision à l'autre les différences sont telles au niveau des fichiers que ccache n'est guère utile,

de plus une révision SVN est parfois boguée au point de crasher à la compilation, ou même carrément au moment du "./configure" car certaines options de compilation ( les --enable-machin ) disparaissent ou fonctionnent mal d'une révision à une autre, nécessitant alors d'utiliser un patch ( regarde l'actuel PKGBUILD de llvm, il est rempli de patchs et de bidouilles diverses ),

de plus llvm est composé de plusieurs sous-projets qui ont chacun leur numéro de révision SVN distinct de l'autre ( ils ne sont pas synchronisés ), si on compile qu'un seul sous-projet en ignorant les autres ( compiler-rt, clang, clang-tools, cfe, lldb ) cela peut provoquer des plantages à la compilation, ou bien ne produire que certains fichiers et pas d'autres ( absence de fichiers so indispensables dans le dossier lib ),

au début je me suis lancé dans cette procédure de bisecting mais j'ai compris que cela allait prendre des semaines et beaucoup trop d’énergie pour un résultat aléatoire,

le bisect ça marche quand le projet est homogène, et rapide à compiler, avec des fichiers cmake/configure qui ne nécessitent pas d'être patchés

[benjarobin]

Tu n'as pas besoin de compiler les autres : compiler-rt, clang, clang-tools, cfe, lldb, ce ne sont que des outils, nous on veut juste la lib.
Tu n'as donc besoin que de compiler la lib. Après il est vrai que je n'ai jamais essayé de compiler cette lib en debug, mais cela ne sevrait pas être pire que la compile en debug de Qt
Mais en effet il y a plus simple...

[Elbarto]

j'avais essayé de ne compiler que le projet "llvm" pour voir si c'était possible afin de gagner du temps, en récupérant que la partie "llvm" ( sans les autres sous-projets ),

par exemple la révision 238586 ( là pour cet exemple je raisonne avec svn, mais il existe aussi un dépôt git pour lequel ça marche aussi ) :

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm -r 238586

puis définir certaines variables pour le script ( en m'inspirant du PKGBUILD de la version svn de llvm disponible sur aur ), et en faisant ensuite la création du sous-dossier "BUILD" pour faire dedans le CMAKE avec les options qui vont bien,

je lance ensuite "make", ça compile un peu plus vite mais le résultat est aléatoire selon la révision SVN :

- soit ça marche et j'ai mon fichier libLLVM.so dans le sous-dossier lib
- soit ça marche mais il manque ce fichier libLLVM.so ( il n'y a alors que des fichiers à extension *.a dans le répertoire lib )
- soit ça échoue à un moment dans la compilation ( le compilateur qui se plaint de quelque chose par exemple, ou un fichier manquant )
- soit ça échoue dès l'étape de la configuration avec CMAKE

j'ai alors fini par comprendre que pour éviter ces problèmes il fallait extraire aussi les autres sous-projets, comme s'il y avait des dépendances entre projets, les erreurs de compilation sont alors beaucoup moins fréquentes ( mais en contrepartie ça prend nettement plus de temps à compiler ),

quand ça plante c'est parfois la révision SVN qui est boguée ( un commit douteux fait par un développeur, une option de compilation qui ne marche plus, c'est alors résolu à la version suivante ),

la difficulté c'est que chaque sous-projet a son propre dépôt SVN/git, je ne sais pas s'il existe un moyen de bisecter en utilisant qu'un seul numéro de révision unifié pour les 3 projets, je ne suis pas assez calé en git, je connais que les bases,

en faisant une recherche google j'ai vu que quelqu'un a essayé de contourner le problème via un script mais j'ai pas testé :

http://lists.cs.uiuc.edu/pipermail/llvm ... 74514.html

[brunoo]

Bonsoir,
Juste pour signaler que j'ai le même problème depuis la mise à jour des paquets mesa ( 11.0.3 ) et llvm-libs.
j'utilise openbox ou compiz, compiz ne fonctionne plus (instruction non permise(core dumped)).
Suite à ton post, j'ai downgradé les paquets mesa et llvm-libs, ça refonctionne avec quelques soucis.
Archlinux 32 bits - pentium dual-core cpu E5300 - carte graphique radeon ati hd 4670.
Voilà.

[benjarobin]

Je confirme faire un bisect est juste impossible... La compilation de juste la lib n'est pas très longue (~8 min : j'adore mon "petit" core i7).
Pour information la dernière version du svn/git build sans aucun souci, comme un boulet j'ai tout supprimé... Tu devrait essayé juste pour voir si cela ne corrige pas le souci. Par contre tu risque de devoir rebuild tout ce qui utilise cette lib...

Sinon je n'ai pas pris le temps de voir ce que cela donnerais une build avec les symboles de debug, tu es sûre que c'est infaisable ? Je pense que c'est ce qu'il y a de plus rapide à faire, il faut juste un peu d'espace disque et pas mal de mémoire vive...
Tu fais la build avec les symboles de debug, tu remplaces les lib (il n'y en a que 3) du système par un lien symbolique pointant vers les fichiers avec le debug et tu tests

[Elbarto]

je n'ai pas dit que c'est infaisable, c'était juste que lors de ma dernière tentative mon /home n'avait que 10 Go d'espace disponible, lorsque j'ai lancé la compilation ça s'est arrêté au bout de 2 heures car l'espace disque de la partition devenait insuffisante ( 223 Mo d'espace disque ),

je vais retenter le coup de créer cette version debug de llvm en faisant la compilation sur une autre partition d'un disque dur beaucoup plus grande

sinon j'avais testé la dernière version svn-git de llvm il y a quelques jours, ça n'avait pas résolu le bug,

à noter que j'ai aussi à ma disposition une version debug de mesa 11.0.3, on sait que le bug est en rapport avec le composant llvmpipe de mesa dont le but est de générer à la volée du code binaire à destination du CPU lorsque la carte graphique est incapable matériellement d’exécuter des fonctions openGL récentes ou celles dites "raster" ( vieille carte graphique ),

il serait alors intéressant d'isoler la portion de code de mesa qui utilise llvm, en utilisant par exemple le débogueur gdb en mettant des "breakpoints", j'avais espéré une aide de la part des développeurs mesa sur le rapport de bug à ce sujet, mais visiblement ils n'ont pas le temps ou ne sont pas intéressés par ce bug, c'est dommage

edit : je leur ai donné aussi un bon moyen de reproduire le bug à l'aide d'une machine virtuelle ( qemu ), j'ai oublié d'ajouter que si on ne précise aucun type de CPU dans les paramètres de qemu alors cela affole complétement llvm 3.7.0 qui affiche alors un message d'erreur " LLVM ERROR: Do not know how to split the result of this operator!" et il fait stopper l’exécution du programme openGL ( lorsque le mode 100% software est utilisé ),

avec la version 3.6.2 ce problème n'existe pas, quelque soit le CPU défini dans qemu il ne bronche pas et fait correctement son travail

[Elbarto]

Salut

Suite à ton post, j'ai downgradé les paquets mesa et llvm-libs, ça refonctionne avec quelques soucis.
Archlinux 32 bits - pentium dual-core cpu E5300 - carte graphique radeon ati hd 4670.
Voilà.

en fait en plus de downgrader les paquets llvm et llvm-libs vers la version 3.6.2 il faut aussi soit downgrader les paquets mesa en version 10.6.x, soit recompiler les paquets mesa 11.0.3 afin qu'ils soient "linkés" avec la bibliothèque libLLVM-3.6.2.so,

si tu choisis cette dernière option il faut en plus modifier le PKGBUILD de mesa 11.0.3 ( commenter la ligne où il y a un sed qui modifie le fichier configure ) sinon ça ne compilera pas,

sinon je vois qu'on a presque la même configuration ( le même type de CPU, et une carte graphique assez proche )

[brunoo]

Salut

Suite à ton post, j'ai downgradé les paquets mesa et llvm-libs, ça refonctionne avec quelques soucis.
Archlinux 32 bits - pentium dual-core cpu E5300 - carte graphique radeon ati hd 4670.
Voilà.

en fait en plus de downgrader les paquets llvm et llvm-libs vers la version 3.6.2 il faut aussi soit downgrader les paquets mesa en version 10.6.x, soit recompiler les paquets mesa 11.0.3 afin qu'ils soient "linkés" avec la bibliothèque libLLVM-3.6.2.so,

si tu choisis cette dernière option il faut en plus modifier le PKGBUILD de mesa 11.0.3 ( commenter la ligne où il y a un sed qui modifie le fichier configure ) sinon ça ne compilera pas,

sinon je vois qu'on a presque la même configuration ( le même type de CPU, et une carte graphique assez proche )

Ok merci.
Effectivement on a une configuration assez proche, je me demandai si ce n'était pas lié.

[Elbarto]

je commence à comprendre de mieux en mieux ce qui se passe au niveau de ce bug,

avec cette commande on peut connaitre comment llvm identifie le CPU :

Code : Tout sélectionner

$ llc --version | grep CPU

avec la version 3.6.2 ( qui n'a pas le bug ) ça me sort ça :

Code : Tout sélectionner

Host CPU: core2

mais avec la version 3.7.0 j'ai une toute autre identification :

Code : Tout sélectionner

Host CPU: penryn

or souvenez-vous de mon test sous qemu : ça plante systématiquement avec llvm 3.7.0 quand on met "Penryn" comme CPU dans les paramètres de qemu,

on peut donc se demander pourquoi llvm 3.7.0 identifie mon CPU comme un "penryn" alors que dans la version 3.6.2 il l'identifiait comme un "core2",

Brunoo tu pourrais essayer de taper cette commande "llc --version | grep CPU" quand le paquet llvm-libs 3.7.0 est installé, puis la même commande quand c'est la version 3.6.2 qui est installée, logiquement tu devrais avoir les mêmes résultats que moi

[benjarobin]

Euh, comment dire, c'est un peu normal...
Tu pars dans des conclusions tellement étranges et erronées que cela fait, je pense, fuir du monde. J'ai en tête le rapport de bug, en effet quand je l'ai lu, j'ai pensé que tu faisais n'importe quoi et que c'était juste une erreur de ta part... Après avoir trié ce que tu disais, il faut se rendre à l'évidence que le bug existe très certainement...

Bref, pour en revenir à ce que tu viens de dire, c'est un peu normal que llc indique que ton CPU est un penryn car ... il est de la famille ... Penryn ...
Voir ici : http://ark.intel.com/products/42811/Int ... z-1066-FSB
Le Intel Pentium E6800 est un dual core Wolfdale, qui fait partie de la famille Penryn

Bref, il n'y a pas de souci dans la détection, "juste" très certainement un bug dans llvm avec les processeurs de la famille Penryn
Pour compléter le support complet de la famille Penryn à très certainement été rajouté dans la version 3.7 de llvm (pas vérifié), c'est pour cela que maintenant ton CPu est correctement identifié, mais il y a surement du y avoir l'ajout d'un bug dans l'ajout du support de la famille Penryn

[brunoo]

Brunoo tu pourrais essayer de taper cette commande "llc --version | grep CPU" quand le paquet llvm-libs 3.7.0 est installé, puis la même commande quand c'est la version 3.6.2 qui est installée, logiquement tu devrais avoir les mêmes résultats que moi

J' ai seulement le paquet llvm-libs, la commande llc ne fonctionnait pas. J' ai installé le paquet llvm 3.7.0.
Résultat:Host CPU: penryn
Je n'ai pas llvm 3.6.2.

[Elbarto]

benjarobin je pense que c'est plus compliqué que ça,

sur ce lien il est indiqué que les CPU penryn peuvent avoir l'extension SSE4, alors que mon pentium E6800 ne l'a pas :

http://www.cpu-world.com/Compare/588/In ... E6800.html

sur mon E6800 au niveau SSE ça va que jusqu'au SSE3,

supposons que llvm 3.7.0 le considère comme un penryn et envoie du coup des instructions SSE4 --> mon pentium va pas aimer,

après j'avoue c'est vrai que j'ai tendance à multiplier les hypothèses, mais néanmoins cela a permis d'avancer un peu malgré l'absence d'aide des développeurs

[benjarobin]

Hum, je crois que tu as mit le doigt sur le problème...
Pour le coup bien que la conclusion de tes investigations sur la détection du processeur soit je pense fausse, cela t'a permit de te mettre sur la voie / et sur un éclaircissement du problème

As tu fais un rapport de bug sur llvm ?
Et je crois avoir compris la raison de l'erreur : https://en.wikipedia.org/wiki/Penryn_%2 ... tecture%29
La famille Penryn comprend plusieurs processeurs : Wolfdale (dual-core) et Yorkfield (quad-core), Harpertown, Dunnington, et Penryn...
Penryn est un modèle de processeur mais aussi une famille...

[Elbarto]

oui j'ai ouvert un rapport de bug sur le site de llvm, mais il est resté sans réponse :

https://llvm.org/bugs/show_bug.cgi?id=25021

[benjarobin]

Je pense ton rapport de bug ne possède pas les bonnes informations, trop vague ? Je ne sais pas...
Mais maintenant je pense que tu as toutes les informations pour expliquer clairement la raison la plus probable du problème. Je crains que tous les CPU de cette page https://en.wikipedia.org/wiki/Penryn_%2 ... tecture%29 qui ne supporte pas le SSE4 soient touchés