
                           Le problme du signal 11

Rogier Wolff ( R.E.Wolff@BitWizard.nl)
(traduit par Nat Makarvitch nat@linux-france.com)

   Version 19970716fr
     _________________________________________________________________

   _Cette FAQ dresse liste des causes possibles d'un problme que
   connaissent ces derniers temps certains utilisateurs de Linux : la
   compilation d'un important ensemble logiciel _

     (par exemple le noyau)

   choue  cause d'un _signal 11_. Ce problme peut tre caus par un
   dysfonctionnement d'ordre matriel (cas le plus frquemment observ)
   ou logiciel.
     _________________________________________________________________

1.  propos de ce document

   La version originale de ce document est  prsent intgre  la
   collection des "Mini-Howto" de Linux.
   La version publie sur le Web tait consulte 300 fois par semaine en
   juin 1996 (augmentation : facteur 3 en 3 mois).

   La plus rcente version de ce texte, librement utilisable s'il n'est
   pas modifi, sur trouve sur son site de rfrence
   <URL:http://www.linux-france.com/>

   Tout commentaire et compte-rendu d'exprience intresse l'auteur (
   Rogier Wolff <R.E.Wolff@BitWizard.nl>) mais les suggestions d'ajouts
   techniquement sans valeur seront rejetes.
   Expdier  nat@linux-france.com les commentaires concernant cette
   adaptation franaise.

   Note : le problme dtaill ici concerne aussi les autres systmes un
   tant soit peu exigeants : Windows 3.1, FreeBSD, Windows NT,
   NextStep...

   Cette adaptation franaise doit beaucoup  J. Chion.

2. Question cl

   Voici la question-cl traite par ce document :
Lorsque je compile un noyau Linux la procdure avorte avec un message:
      gcc: Internal compiler error: program cc1 got fatal signal 11
Que se passe-t-il ?

2.1 Rponse succincte

   Le problme est vraisemblablement caus par un dysfonctionnement du
   matriel. De nombreux composants de l'ordinateur peuvent tre
   impliqus et diverses manires de rsoudre le problme existent.

3. Comment s'assurer que le matriel est en cause ?

   Sitt aprs l'chec du make, invoquez-le  nouveau.

   Si la machine parvient  compiler quelques autres fichiers, nous
   pouvons penser que le matriel est dfaillant.

   Si, par contre, la compilation cesse tout de suite (message "nothing
   to be done for xxxx" avant nouvel chec au mme endroit), il faudra
   dterminer si le contenu de la mmoire vive est toujours bien
   prserv. Pour cela :
        dd if=/dev/DISQUE_DUR of=/dev/null bs=1024k count=MEGAS

   _DISQUE_DUR_ remplace ici le nom du fichier spcial associ au disque
   dur stockant les sources. Pour connatre son nom, rester dans le
   rpertoire abritant les sources et introduire df  . ("df" suivi d'un
   espace puis un point).
   _MEGAS_ remplace ici le nombre de Mo de mmoire vive dont la machine
   dispose (indiqu par free).

   Cette commande va obliger Linux  lire les informations places au
   dbut du disque de faon  "gaver" le contenu du cache disque
   ("buffer-cache"). Il devra donc, par la suite, relire les fichiers
   source  compiler ainsi que les binaires de gcc.

   Invoquer make.

   Si la compilation choue toujours au mme "endroit", le problme est
   probablement d'ordre logiciel. tudier en ce cas la section consacre
   aux autres causes possibles.

   Si la compilation choue  un autre stade, nous pouvons conclure que
   les transferts de donnes entre le disque et la mmoire vive ne sont
   pas assurs correctement.

4. Que signifie ce "signal 11" ?

   Linux avorte grce au "signal 11" tout programme tentant d'accder 
   une adresse mmoire ne lui appartenant pas. Parmi les nombreuses
   causes possibles, nous ne pouvons retenir dans l'absolu que deux
   possibilits, dans le cas o cela concerne une version stable de gcc
   utilise sur une machine trs commune : problme matriel ou bien
   inadquation de certaines composantes des utilitaires logiciels du
   systme.

   Lorsque ce problme survient sur une machine sans dfaut matriel, il
   ne peut tre caus que par une erreur de programmation ou de
   compilation (en l'occurrence du binaire de gcc). Mais lorsque le
   matriel est dfaillant, et que des valeurs stockes en mmoire vive
   changent plus ou moins alatoirement, un programme exigeant tel que
   gcc ne parviendra pas  mener  bien sa mission car il tentera tt ou
   tard de drfrencer un pointeur au contenu ainsi modifi.

   Un pointeur, sur une machine  processeur Intel, s'tend sur 32 bits
   et permet donc d'accder  4 Go. Peu de machines Intel disposent
   d'autant de mmoire vive dont la majeure partie serait alloue  gcc !
   Une adresse de 32 bits alatoire est donc trs probablement illgale
   et Linux tuera le programme qui tente avec elle, selon lui, de
   manipuler des donnes ne lui appartenant pas.

5. Quel composant incriminer ?

   Voici une liste des diverses causes de dysfonctionnement du matriel :

     * Composants trop lents. De mauvaises surprises sont  craindre si
       l'une des "barrettes" de mmoire vive ne fonctionne pas
       convenablement. Mme une carte mre capable de contrler par test
       de parit ne dtectera pas les erreurs survenant lors des cycles
       d'criture.
       Inventaire des causes et solutions :
          + Latence des composants trop importante ("mmoire trop lente")
            Le contrleur de bus ne parvient pas toujours en ce cas 
            obtenir  temps la donne requise par le processeur car la
            mmoire "ragit" trop lentement. Solution :augmenter le
            nombre de cycles d'attente ("wait states") grce au SETUP de
            la machine. Problme frquent sur les machines 486 cadenc 
            plus de 80 MHz quipes d'un BIOS de marque AMI. (Pat V.)
            Il est parfois ncessaire de remplacer les composants pour
            diminuer la latence. Les systmes ayant un bus cadenc  33
            MHz (P100, P133...) ne doivent pas employer de RAM avec plus
            de 60ns de latence, surtout si la carte mre est de marque
            ASUS. L'ensemble peut sembler fonctionner avec des composants
             70ns mais une petite erreur est alors toujours possible
            (Andrew Eskilsson).
          + Composant dfecteux
            Dmonter une barrette (ou changer temporairement la seule
            barrette employe) puis relancer le systme et tester.
            Recommencer autant de fois que ncessaire afin d'isoler le
            (ou les !) composants dfectueux. Prendre garde, le cas
            chant, lors de la manipulation des mmoires statiques, car
            une dcharge _d'lectricit statique_ peut les _condamner_.
            Tmoignage (kettner@cat.et.tudelft.nl) : nous avons prouv
            de grandes difficults avec une machine dont il s'avra que
            les quatre barrettes taient dfectueuses et modifiaient 
            peu prs un bit par heure de fonctionnement. La machine
            "plantait" environ une fois par jour et les compilations de
            noyau chouaient environ une fois par heure. Cette machine a
            pu excuter le test mmoire durant 2300 cycles complets sans
            erreur, puis dtecta environ 10 erreurs et continua ensuite
            sans problme durant plusieurs centaines de cycles. La
            compilation de noyau s'avra le test le plus efficace car
            mme le cas le plus favorable ne permettait pas de compiler
            plus de 14 noyaux  la suite. Nous avons donc chang ces
            barrettes.
          + Convertisseurs dfectueux
            De nombreux supports de mmoire, permettant de monter des
            composants 32 bits sur des supports 72 points, ne sont pas
            conus de faon correcte, en particulier les plus anciens.
            Tmoignages : nous avons trs longtemps utilis sans problme
            un jeu de composants sans support de ce type. Mais ils ne
            furent pas utilisables avec un convertisseur (Naresh Sharma
            (n.sharma@is.twi.tudelft.nl)).
            Paul Gortmaker (paul.gortmaker@anu.edu.au) indique que les
            convertisseurs doivent tous comporter au moins quatre
            condensateurs de rgulation du courant.
          + Mode de rafrachissement de la mmoire vive inadquat
            Les composants "perdent" alors peu  peu les donnes
            stockes. Causes (Hank Barta (hank@pswin.chi.il.us), Ron
            Tapia (tapia@nmia.com)) : certaines cartes mre donnent la
            possiblit de rarfier les cycles de rafrachissement en vue
            d'augmenter la bande passante utile du bus (option "hidden
            refresh" du SETUP). Un programme, souvent appel dram, offre
            le moyen de configurer le jeu de composants ("chipset") au
            plus bas niveau afin d'obtenir des effets semblables.
          + Trop faible nombre de cycles d'attente
            Certains composants de la carte mre peuvent ne pas
            fonctionner toujours correctement si le nombre de cycles
            d'attente ("wait states") n'est pas appropri. L'augmenter
            grce au SETUP.
     * Dfaillance de la mmoire cache
       Le contenu de la mmoire cache n'est gnralement pas certifi par
       un test de parit et une dfaillance ne sera donc pas
       diagnostique par la carte mre. Test : utiliser le SETUP pour
       invalider le cache externe ("L2") puis faire fonctionner le
       systme. Si les problmes disparaissent le cache est dfectueux.
       Solutions :
          + Vitesse ou latence de la mmoire cache inadquate.
            Augmenter, grce au SETUP, le nombre de cycles d'attente.
          + Composant de mmoire dfecteux
            Il faut alors changer de composant cache. _ATTENTION_ : il
            s'agit trs souvent de mmoire statique, donc _trs_ fragile
            (Joseph Barone (barone@mntr02.psf.ge.com)).
          + Mode d'exploitation du cache inadquat
            Le mode "criture diffre" ("write back"), par exemple,
            cause parfois des problmes lorsque le jeu de composants de
            la carte mre n'est pas correctement conu (cas observ sur
            une carte "MV020 486VL3H" (20 Mo RAM) par Scott Brumbaugh).
     * Configuration incorrecte de la carte mre
       Un cavalier ("jumper") dtermine parfois le cache qui sera employ
       (le modle mont sur une micro carte d'extension ou bien les
       composants de mmoire classiques). Exemple : cavalier JP16 sur les
       ASUS P/I-P55TP4XE version 2.4.
     * Transferts de donnes entre disque et mmoire
       Un bloc de donnes lu sur le disque peut se trouver stock en
       mmoire avec un bit erron.
       Dterminer si c'est la cause du problme en recopiant des fichiers
       puis en comparant la copie  l'original. Rpter ce test : aprs
       un dd (consulter  ce propos la section consacre  l' expiration
       du buffer cache) la compilation avortera trs vraisemblablement 
       un autre stade.
          + Interruptions masques durant des transferts IDE
            Certains disques IDE ne tolrent pas le dmasquage des
            interruptions lors des transferts, en particulier en priode
            de forte charge systme ("hdparm -u0").
          + Disque de marque Kalok
            La qualit des disques Kalok de la srie 31xx laisse beaucoup
             dsirer, mieux vaut viter de les employer. Ils ne sont de
            toutes faons pas compatibles avec Linux. Les rformer ou
            laisser aux utilisateurs de systmes d'exploitation sans
            cache disque.
          + Disques SCSI
            Vrifier terminateurs et cbles. Un cble court peut sembler
            fonctionner avec une terminaison inadquate mais les donnes
            transfres peuvent en ptir. Essayer de valider les options
            de test de parit.
     * Augmentation abusive de la cadence d'horloge ("overclocking")
       Le rsultat est le plus souvent alatoire. Essayer d'exploiter la
       machine  la cadence d'horloge normale.
       Dans un cas au moins (Samuel Ramac (sramac@vnet.ibm.com)) un
       processeur P120 ne tolrait pas 120 MHz mais fonctionnait  100
       MHz. La carte mre n'tait pas en cause car le bus est en fait
       plus rapide lorsque l'horloge bat  100 MHz

     CPU  120 : bus  60 (x 2), CPU  100 : bus  66 (x 1,33)
       . Un autre processeur P120, mont en lieu et place, fonctionne
       d'ailleurs normalement.
       Tous les "fondeurs" (constructeurs de processeurs) produisent
       ainsi de rares "rats", ce n'est en rien spcifique  Intel.
     * Refroidissement du processeur
       L'levation de la temprature du processeur provoque par une
       augmentation de la cadence d'horloge ou par une panne du
       dispositif de refroidissement peut gnrer des dysfonctionnements.
       Bon rvlateur : interdire au noyau d'utiliser l'instruction HALT
       grce au paramtre LILO adquat (lire le "BootPrompt HOWTO"). La
       temprature du circuit augmentera alors beaucoup plus vite, mme
       sous faible charge systme, et la frquence d'apparition des
       problmes augmentera. Le Pentium  l'instruction "FDIV" bogue est
       particulirement concern car son ventilateur n'tait pas conu au
       mieux. Notons aussi que la colle employe pour assujetir le
       radiateur au processeur doit prsenter des caractristiques de
       conduction thermique correcte (Arno Griffioen (arno@ixe.net), W.
       Paul Mills (wpmills@midusa.net), Alan Wind (wind@imada.ou.dk))
       Intel indique que la temprature de la surface du processeur doit
       tre comprise entre :
          + 0 et +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4
          + 0 et +95 C: IntelDX2, IntelDX4 OverDrive
          + 0 et +80 C: 60 MHz Pentium
          + 0 et +70 C: 66 to 166 MHz Pentium
       Consulter  ce propos les sections Q6, Q7 et Q13 de ce document
       Intel
     * Voltage de l'alimentation du processeur
       Certains processeurs 5 Volts fonctionnent sous 3,3 Volts, mais pas
       toujours de faon parfaite. Pis : les documentations de certains
       systmes sont incorrectes et recommandent une configuration
       inadquate (Karl Heyes (krheyes@comp.brad.ac.uk))
     * Voltage de l'alimentation de la mmoire
       Les plus rcentes cartes ne tolrent que la mmoire 3,3 Volts. Ne
       jamais utiliser les composants sous un voltage inadquat (risque
       de destruction).
     * Surexploitation du bus local
       Le nombre de cartes connectables  un bus local dcrot avec sa
       frquence d'exploitation : 3 cartes  25 MHz, 2  33 MHz, une
       seule  40 MHz et aucune  50 MHz (frquence maximale). Certains
       systmes tolrent mal la surcharge et les donnes changes
       peuvent alors en ptir. Essayer d'augmenter les tats d'attente
       insrs entre les cycles du bus local (Richard Postgate
       (postgate@cafe.net)).
     * Fonctions d'conomie d'nergie ("power management", "APM")
       Certains portables, en particulier, offrent une fonction de
       reprise immdiate (mode "resume") et des programmes pilotes ne
       tolrent pas toujours cela. Dbrayer ces fonctions ou bien
       compiler l'"APM support" dans le noyau (Elizabeth Ayer
       (eca23@cam.ac.uk)).
     * Processeur dfectueux
       Certains exemplaires des processeurs courants reclent des bogues
       aux effets pervers. Aucune solution n'existe, il faut remplacer le
       composant. Des cas d'incompatibilit entre processeur et carte
       mre auraient t observs. Depuis fvrier 1997 la premire vague
       de problmes, qui concernait les processeurs Intel, dcrot
       nettement tandis que l'exploitation de processeurs Cyrix/IBM 6x86
       sur certaines cartes mre s'avre difficile. Le manuel d'une carte
       mre prcise qu'elle est incompatible avec les premires versions
       du 6x86. C'est regrettable car les performances de ces processeurs
       sont fort bonnes.

6. Mais tout fonctionnait correctement depuis longtemps !

   Le fait que la configuration dficiente fonctionnait sans problme
   depuis un moment n'implique malheureusement pas que le matriel est
   hors de cause.

   L'exemple classique concerne les composants de mmoire. Leurs
   fabricants ne disposent pas d'une ligne de production distincte pour
   chaque type de mmoire. Les circuits proviennent tous des mmes
   machines et matires premires, seul le test final dtermine si un
   composant donn sera par exemple vendu en tant que 60 ns ou bien 70
   ns. Vos composants fonctionnaient peut-tre  merveille depuis
   longtemps  la limite de leurs capacits mais un facteur quelconque
   (la temprature, par exemple, ralentit les mmoires) peut les rendre
   assez vite inadquats.

   Un climat estival ou bien une lourde charge de travail processeur
   place donc parfois le systme dans des conditions o son
   fonctionnement correct n'est plus certain, voire plus possible
   (Philippe Troin (ptroin@compass-da.com)).

7. Mon programme de test mmoire ne rvle aucun problme

   Le test mmoire effectu par le BIOS lors du dmarrage de la machine
   n'en est le plus souvent pas un. Des conditions d'exploitation
   extrmes peuvent seules permettre de lever le doute. Tester grce 
   memtest86.

8. Le problme est-il limit  la compilation du noyau ?

   Non, mais la compilation du noyau exige beaucoup de ressources et
   constitue donc un excellent test ou rvlateur.

   Autres cas observs :
     * Certaines machines se bloquent parfois lorsqu'elles excutent le
       script d'installation de la distribution Slackware
       (dhn@pluto.njcc.com).
     * Le noyau stoppe parfois une tche  cause d'une "general
       protection error" (message confi  syslog)
       (fox@graphics.cs.nyu.edu).

9. D'autres systmes d'exploitation fonctionnent pourtant bien sur cette
machine !

   Linux exploite mieux le matriel que la plupart des autres systmes,
   comme ses performances le laissent imaginer.

   Certains autres systmes, par exemple dits par Microsoft, se
   "plantent parfois" de faon incomprhensible. Peu d'utilisateurs s'en
   plaignent, semble-t-il, et cette socit leur rpond en ce cas d'une
   manire quelque peu trange.

   Le mode de conception et d'utilisation de ces systmes d'exploitation
   produit un ensemble le plus souvent plus "prdictible" que Linux dans
   la mesure ou une application donne sera le plus souvent charge dans
   la mme section de la mmoire vive. Les alas ds  un composant
   dfectueux sont donc parfois ports au compte d'un programme donn et
   non du matriel.

   Une chose demeure cependant certaine : un systme Linux bien install
   sur une machine saine doit pouvoir compiler cent fois de suite un
   noyau sans aucun problme.

   Tmoignage : Linux et gcc testent  merveille la machine. Hors de
   Linux le test "Winstone" produit le mme genre d'effets (Jonathan
   Bright (bright@informix.com))

10. "signal 11" est-il le seul effet ?

   Ce n'est malheureusement pas le cas. Les signaux 6 et 4 peuvent aussi
   relever de ce genre de problme (lorsque la mmoire n'accomplit pas
   correctement son office n'importe quel type d'erreur peut survenir)
   mais le 11 est le plus commun.

   Autres problmes constats :
     * free_one_pmd: bad directory entry 00000008
     * EXT2-fs warning (device X:Y): ext_2_free_blocks bit already
       cleared for block Z
     * Internal error: bad swap device
     * Trying to free nonexistent swap-page
     * kfree of non-kmalloced memory ...
     * scsi0: REQ before WAIT DISCONNECT IID
     * Unable to handle kernel NULL pointer dereference at virtual
       address c0000004
     * put_page: page already exists 00000046 invalid operand: 0000
     * Whee.. inode changed from under us. Tell Linus
     * crc error System halted (lors du dmarrage)
     * Segmentation fault
     * "unable to resolve symbol"
     * make 1]: *** ... Error 139 make: *** ... Error 1
     * X Window avorte brusquement avec un mesage 'can terminate with a
       "caught signal xx"'

   Les premiers exemples relvent d'arrts provoqus par le noyau qui
   "suspecte" une erreur de programmation l'affectant. Les autres
   concernent les applications.

   (S.G.de Marinis (trance@interseg.it), Dirk Nachtmann
   (nachtman@kogs.informatik.uni-hamburg.de))

11. Que faire ?

     * Dmonter des barrettes, les remplacer
     * Dbrayer (SETUP) le cache de second niveau du processeur
     * Diminuer la cadence du processeur et du bus
     * Restaurer la cadence de rafrachissement de la mmoire prconise
     * Dmarrer avec un noyau sous option "mem=4M" pour lui interdire
       d'exploiter la mmoire au-dessus des 4 premiers Mo
     * Tester :

    tcsh
    cd /usr/src/linux
    make zImage
    foreach i (0 1 2 3 4 5 6 7 8 9)
      foreach j (0 1 2 3 4 5 6 7 8 9)
        make clean;make zImage > log."$i"$j
      end
    end

       Tous les contenus des fichiers de trace rsultants doivent tre
       identiques. Cela exige environ 24 heures sur un P100 / 16 Mo RAM
       et environ 3 mois sur un 386 / 4 Mo :-)

   Le moyen le plus efficace reste de remplacer tous les composants de
   mmoire. Ce n'est cependant pas toujours facile.

12. Et le test physique ?

   Mme certains quipements lectroniques de test des mmoires ne
   mettent pas toujours en vidence les problmes dont nous traitons ici
   car ils peuvent par exemple dpendre du mode d'exploitation des
   composants par la carte mre.

13. Quelles sont les autres causes possibles ?

     * pgcc
       Utilisation de la version de gcc "pgcc", dont le gnrateur de
       code est optimis pour le Pentium. La compilation, avec ses
       options par dfaut, de certains modules du noyau (par exemple
       floppy.c) produit un signal 11. Les causes se trouvent  la fois
       dans le noyau, la libc et pgcc. On constate vite qu'il ne s'agit
       pas d'un problme matriel car il se produit toujours au mme
       stade de la compilation.
       Solution : utiliser un gcc standard ou bien des options
       interdisant certaines optimisations (par exemple
       "-fno-unroll-loops") (Evan Cheng (evan@top.cis.syr.edu)).
     * Composants de gcc htroclites
       Lorsque les fichiers appartenant  gcc proviennent de sources
       diffrentes des problmes peuvent appratre. Il faut alors tout
       remplacer par une version complte et correcte (Richard H. Derr
       III (rhd@Mars.mcs.com)).
     * dition de liens avec bibliothque pour SCO
       Sous iBCS  les applications dont le LDFLAGS contient -Llib/ sont
       exposes.
     * a.out et ELF
       Compilation d'un noyau a.out au sein d'un environnement ELF (ou le
       contraire).. Le premier appel  "ld" causera toujours un "signal
       11"(REW).
     * Carte Ethernet ISA sur bus PCI mal configur
       Cela peut causer de graves problmes logiciels (sigsegv, arrt du
       noyau...). Il faut alors utiliser le SETUP pour configurer
       l'"aperture" (zone de mmoire commune  la carte et  l'espace
       d'adressage du systme).
     * Contenu de la partition de mmoire virtuelle ("swap") endommag
       Tony Nugent (T.Nugent@sct.gu.edu.au) prcise qu'il a pu rsoudre
       le problme en re-prparant la partition grce  "mkswap".
       Louis J. LaBash Jr. (lou@minuet.siue.edu) nous rappelle qu'il faut
       invoquer "sync" aprs un "mkswap".
     * Cartes Ethernet bas de gamme de type NE2000
       La qualit de certaines cartes est si mdiocre qu'elles mettent en
       pril la stabilit du systme. Les noyaux Linux postrieurs 
       1.3.48 les tolrent semble-t-il mieux (REW).
     * Alimentation lectrique
       Cas peu probable, mme une machine trs bien quipe n'approche
       gure les limites des alimentations 200 W. Seul un systme
       utilisant de nombreux anciens disques (gros consommateurs de
       courant) peut poser un problme (Greg Nicholson
       (greg@job.cba.ua.edu)).
       Thorsten Kuehnemann (thorsten@actis.de) indique qu'une
       alimentation dfectueuse peut provoquer des signaux 11.
     * Compilation du code ext2
       Dans certains cas la compilation du code de gestion du systme de
       fichiers ext2 provoque un signal 11 (Morten Welinder
       (terra@diku.dk)).
     * Mmoire disponible insuffisante
       gcc produit alors d'tranges erreurs (Paul Brannan
       (brannanp@musc.edu)).

14. Cette liste me laisse sceptique !

   Nous ne traitons ici que de cas _rels !_
   (N.d.T : la version originale de ce document propose une liste des
   auteurs de tmoignages).
