  Le probleme du signal 11
  Rogier             Wolff             (R.E.Wolff@BitWizard.nl
  <mailto:R.E.Wolff@BitWizard.nl>)
  (traduit   par    Nat    Makarevitch    nat@linux-france.com
  <mailto:nat@linux-france.com>)
  Version 19970716fr

  Cette FAQ dresse liste des causes possibles d'un probleme que connais-
  sent ces derniers temps certains utilisateurs de Linux :  la  compila-
  tion d'un important ensemble logiciel (-- (par exemple le noyau)--)

  echoue  a  cause  d'un  _s_i_g_n_a_l _1_1.  Ce probleme peut etre cause par un
  dysfonctionnement d'ordre materiel (cas le plus  frequemment  observe)
  ou logiciel.

  11..  AA pprrooppooss ddee ccee ddooccuummeenntt

  La  version  originale <http://www.bitwizard.nl/sig11/> de ce document
  est a present integree a la collection des "Mini-Howto" de Linux.
  La version publiee sur le Web etait consultee 300 fois par semaine  en
  juin 1996 (augmentation : facteur 3 en 3 mois).

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

  Tout  commentaire  et  compte-rendu  d'experience  interesse  l'auteur
  (Rogier                 Wolff                 <R.E.Wolff@BitWizard.nl>
  <mailto:R.E.Wolff@BitWizard.nl>)   mais   les   suggestions   d'ajouts
  techniquement sans valeur seront rejetees.
  Expedier  a  nat@linux-france.com  <mailto:nat@linux-france.com>   les
  commentaires concernant cette adaptation francaise.

  Note  : le probleme detaille ici concerne aussi les autres systemes un
  tant  soit  peu  exigeants  :  Windows  3.1,  FreeBSD,   Windows   NT,
  NextStep...

  Cette adaptation francaise doit beaucoup a J. Chion.

  22..  QQuueessttiioonn ccllee

  Voici la question-cle traitee par ce document :

  Lorsque je compile un noyau Linux la procedure avorte avec un message:
        gcc: Internal compiler error: program cc1 got fatal signal 11
  Que se passe-t-il ?

  22..11..  RReeppoonnssee ssuucccciinnccttee

  Le  probleme  est  vraisemblablement cause par un dysfonctionnement du
  materiel.  De  nombreux  composants  de  l'ordinateur   peuvent   etre
  impliques et diverses manieres de resoudre le probleme existent.

  33..  CCoommmmeenntt ss''aassssuurreerr qquuee llee mmaatteerriieell eesstt eenn ccaauussee ??

  Sitot apres l'echec du make, invoquez-le a nouveau.

  Si  la  machine  parvient  a  compiler  quelques autres fichiers, nous
  pouvons penser que le materiel est defaillant.

  Si, par contre, la compilation cesse tout de suite  (message  "nothing
  to  be  done  for xxxx" avant nouvel echec au meme endroit), il faudra
  determiner si  le  contenu  de  la  memoire  vive  est  toujours  bien
  preserve. Pour cela :

          dd if=/dev/DISQUE_DUR of=/dev/null bs=1024k count=MEGAS

  _D_I_S_Q_U_E___D_U_R  remplace  ici  le nom du fichier special associe au disque
  dur stockant les sources. Pour  connaitre  son  nom,  rester  dans  le
  repertoire  abritant  les sources et introduire df  . ("df" suivi d'un
  espace puis un point).
  _M_E_G_A_S remplace ici le nombre de Mo de memoire  vive  dont  la  machine
  dispose (indique par free).

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

  Invoquer make.

  Si la compilation echoue toujours au meme "endroit", le  probleme  est
  probablement  d'ordre logiciel. Etudier en ce cas la section consacree
  aux ``autres causes possibles''.

  Si la compilation echoue a un autre stade, nous pouvons  conclure  que
  les  transferts  de donnees entre le disque et la memoire vive ne sont
  pas assures correctement.

  44..  QQuuee ssiiggnniiffiiee ccee ""ssiiggnnaall 1111"" ??

  Linux avorte grace au "signal 11" tout programme tentant  d'acceder  a
  une  adresse  memoire  ne  lui  appartenant  pas. Parmi les nombreuses
  causes possibles, nous ne  pouvons  retenir  dans  l'absolu  que  deux
  possibilites,  dans  le cas ou cela concerne une version stable de gcc
  utilisee sur une machine tres commune  :  probleme  materiel  ou  bien
  inadequation  de  certaines  composantes  des utilitaires logiciels du
  systeme.

  Lorsque ce probleme survient sur une machine sans defaut materiel,  il
  ne  peut  etre  cause  que  par  une  erreur  de  programmation  ou de
  compilation (en l'occurrence du  binaire  de  gcc).  Mais  lorsque  le
  materiel  est  defaillant, et que des valeurs stockees en memoire vive
  changent plus ou moins aleatoirement, un programme  exigeant  tel  que
  gcc  ne parviendra pas a mener a bien sa mission car il tentera tot ou
  tard de dereferencer un pointeur au contenu ainsi modifie.

  Un pointeur, sur une machine a processeur Intel, s'etend sur  32  bits
  et  permet  donc  d'acceder  a  4  Go. Peu de machines Intel disposent
  d'autant de memoire vive dont la majeure partie serait allouee a gcc !
  Une  adresse  de 32 bits aleatoire est donc tres probablement illegale
  et Linux tuera le  programme  qui  tente  avec  elle,  selon  lui,  de
  manipuler des donnees ne lui appartenant pas.

  55..  QQuueell ccoommppoossaanntt iinnccrriimmiinneerr ??

  Voici une liste des diverses causes de dysfonctionnement du materiel :

  +o  Composants trop lents.  De mauvaises surprises sont a  craindre  si
     l'une   des   "barrettes"   de   memoire  vive  ne  fonctionne  pas
     convenablement.  Meme une carte mere capable de controler par  test
     de  parite  ne  detectera pas les erreurs survenant lors des cycles
     d'ecriture.

     Inventaire des causes et solutions :

  +o  Latence des composants trop importante ("memoire trop lente")
     Le controleur de bus ne parvient pas toujours en ce cas a obtenir a
     temps  la  donnee requise par le processeur car la memoire "reagit"
     trop lentement. Solution :augmenter le nombre de  cycles  d'attente
     ("wait states") grace au SETUP de la machine. Probleme frequent sur
     les machines 486 cadence a plus de 80 MHz  equipees  d'un  BIOS  de
     marque AMI. (Pat V.)
     Il est parfois necessaire de remplacer les composants pour diminuer
     la latence. Les systemes ayant un  bus  cadence  a  33  MHz  (P100,
     P133...)  ne  doivent  pas  employer  de  RAM  avec plus de 60ns de
     latence, surtout si la carte mere est de  marque  ASUS.  L'ensemble
     peut sembler fonctionner avec des composants a 70ns mais une petite
     erreur est alors toujours possible (Andrew Eskilsson).

  +o  Composant defecteux
     Demonter une barrette (ou changer temporairement la seule  barrette
     employee) puis relancer le systeme et tester. Recommencer autant de
     fois  que  necessaire  afin  d'isoler  le  (ou  les  !)  composants
     defectueux.  Prendre garde, le cas echeant, lors de la manipulation
     des memoires statiques, car  une  decharge  _d_'_e_l_e_c_t_r_i_c_i_t_e  _s_t_a_t_i_q_u_e
     peut les _c_o_n_d_a_m_n_e_r.

     Temoignage  (kettner@cat.et.tudelft.nl)  :  nous  avons  eprouve de
     grandes difficultes avec une machine dont il s'avera que les quatre
     barrettes etaient defectueuses et modifiaient a peu pres un bit par
     heure de fonctionnement. La machine "plantait" environ une fois par
     jour  et  les compilations de noyau echouaient environ une fois par
     heure. Cette machine a pu executer  le  test  memoire  durant  2300
     cycles  complets  sans  erreur,  puis detecta environ 10 erreurs et
     continua  ensuite  sans  probleme  durant  plusieurs  centaines  de
     cycles.  La  compilation  de noyau s'avera le test le plus efficace
     car meme le cas le plus favorable ne  permettait  pas  de  compiler
     plus  de  14  noyaux  a  la  suite.  Nous  avons  donc  echange ces
     barrettes.

  +o  Convertisseurs defectueux
     De  nombreux  supports  de  memoire,  permettant  de   monter   des
     composants  32  bits sur des supports 72 points, ne sont pas concus
     de facon correcte, en particulier les plus anciens.

     Temoignages : nous avons tres longtemps utilise  sans  probleme  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 regulation du courant.

  +o  Mode de rafraichissement de la memoire vive inadequat
     Les  composants  "perdent"  alors  peu  a peu les donnees stockees.
     Causes    (Hank    Barta    (hank@pswin.chi.il.us),    Ron    Tapia
     (tapia@nmia.com))  : certaines cartes mere donnent la possiblite de
     rarefier les cycles de rafraichissement en vue d'augmenter la bande
     passante  utile  du  bus  (option  "hidden  refresh"  du SETUP). Un
     programme, souvent appele dram, offre le moyen de configurer le jeu
     de  composants  ("chipset")  au  plus bas niveau afin d'obtenir des
     effets semblables.

  +o  Trop faible nombre de cycles d'attente
     Certains composants de la carte mere  peuvent  ne  pas  fonctionner
     toujours  correctement  si  le  nombre  de  cycles d'attente ("wait
     states") n'est pas approprie. L'augmenter grace au SETUP.

  +o  Defaillance de la memoire cache
     Le contenu de la memoire cache n'est generalement pas certifie  par
     un test de parite et une defaillance ne sera donc pas diagnostiquee
     par la carte mere. Test : utiliser le SETUP pour invalider le cache
     externe  ("L2") puis faire fonctionner le systeme. Si les problemes
     disparaissent le cache est defectueux. Solutions :

  +o  Vitesse ou latence de la memoire cache inadequate.
     Augmenter, grace au SETUP, le nombre de cycles d'attente.

  +o  Composant de memoire defecteux
     Il faut alors changer de composant cache.  _A_T_T_E_N_T_I_O_N  :  il  s'agit
     tres  souvent de memoire statique, donc _t_r_e_s fragile (Joseph Barone
     (barone@mntr02.psf.ge.com)).

  +o  Mode d'exploitation du cache inadequat
     Le mode "ecriture differee"  ("write  back"),  par  exemple,  cause
     parfois des problemes lorsque le jeu de composants de la carte mere
     n'est pas correctement concu (cas  observe  sur  une  carte  "MV020
     486VL3H" (20 Mo RAM) par Scott Brumbaugh).

  +o  Configuration incorrecte de la carte mere
     Un  cavalier ("jumper") determine parfois le cache qui sera employe
     (le modele monte sur  une  micro  carte  d'extension  ou  bien  les
     composants  de memoire classiques). Exemple : cavalier JP16 sur les
     ASUS P/I-P55TP4XE version 2.4.

  +o  Transferts de donnees entre disque et memoire
     Un bloc de donnees lu sur le  disque  peut  se  trouver  stocke  en
     memoire avec un bit errone.
     Determiner  si c'est la cause du probleme en recopiant des fichiers
     puis en comparant la copie a l'original. Repeter ce test : apres un
     dd  (consulter a ce propos la section consacree a l'``expiration du
     buffer cache'') la compilation avortera tres vraisemblablement a un
     autre stade.

  +o  Interruptions masquees durant des transferts IDE
     Certains   disques   IDE   ne   tolerent   pas  le  demasquage  des
     interruptions lors des transferts, en  particulier  en  periode  de
     forte charge systeme ("hdparm -u0").

  +o  Disque de marque Kalok
     La  qualite  des  disques  Kalok de la serie 31xx laisse beaucoup a
     desirer, mieux vaut eviter de les employer. Ils ne sont  de  toutes
     facons  pas  compatibles  avec  Linux.  Les reformer ou laisser aux
     utilisateurs de systemes d'exploitation sans cache disque.

  +o  Disques SCSI
     Verifier terminateurs et  cables.   Un  cable  court  peut  sembler
     fonctionner  avec  une  terminaison  inadequate  mais  les  donnees
     transferees peuvent en patir. Essayer de  valider  les  options  de
     test de parite.

  +o  Augmentation abusive de la cadence d'horloge ("overclocking")
     Le  resultat  est le plus souvent aleatoire. Essayer d'exploiter la
     machine a la cadence d'horloge normale.

     Dans un  cas  au  moins  (Samuel  Ramac  (sramac@vnet.ibm.com))  un
     processeur  P120  ne  tolerait  pas 120 MHz mais fonctionnait a 100
     MHz. La carte mere n'etait pas en cause car le bus est en fait plus
     rapide  lorsque l'horloge bat a 100 MHz (-- CPU a 120 : bus a 60 (x
     2), CPU a 100 : bus a 66 (x 1,33)--) . Un  autre  processeur  P120,
     monte en lieu et place, fonctionne d'ailleurs normalement.
     Tous les "fondeurs" (constructeurs de processeurs) produisent ainsi
     de rares "rates", ce n'est en rien specifique a Intel.

  +o  Refroidissement du processeur
     L'elevation de la  temperature  du  processeur  provoquee  par  une
     augmentation de la cadence d'horloge ou par une panne du dispositif
     de  refroidissement  peut  generer  des   dysfonctionnements.   Bon
     revelateur : interdire au noyau d'utiliser l'instruction HALT grace
     au  parametre  LILO  adequat  (lire  le  "BootPrompt  HOWTO").   La
     temperature  du  circuit  augmentera alors beaucoup plus vite, meme
     sous faible  charge  systeme,  et  la  frequence  d'apparition  des
     problemes  augmentera. Le Pentium a l'instruction "FDIV" boguee est
     particulierement concerne car son ventilateur n'etait pas concu  au
     mieux.   Notons  aussi  que  la  colle  employee  pour assujetir le
     radiateur au processeur  doit  presenter  des  caracteristiques  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 temperature de la surface du  processeur  doit
     etre comprise entre :

  +o  0 et +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4

  +o  0 et +95 C: IntelDX2, IntelDX4 OverDrive

  +o  0 et +80 C: 60 MHz Pentium

  +o  0 et +70 C: 66 to 166 MHz Pentium

     Consulter  a  ce  propos  les sections Q6, Q7 et Q13 de ce document
     Intel <http://pentium.intel.com/procs/support/faqs/iarcfaq.htm>

  +o  Voltage de l'alimentation du processeur
     Certains processeurs 5 Volts fonctionnent sous 3,3 Volts, mais  pas
     toujours  de  facon  parfaite. Pis : les documentations de certains
     systemes  sont  incorrectes  et  recommandent   une   configuration
     inadequate (Karl Heyes (krheyes@comp.brad.ac.uk))

  +o  Voltage de l'alimentation de la memoire
     Les  plus  recentes cartes ne tolerent que la memoire 3,3 Volts. Ne
     jamais utiliser les composants sous un voltage inadequat (risque de
     destruction).

  +o  Surexploitation du bus local
     Le  nombre  de  cartes  connectables a un bus local decroit avec sa
     frequence d'exploitation : 3 cartes a 25 MHz, 2 a 33 MHz, une seule
     a 40 MHz et aucune a 50 MHz (frequence maximale). Certains systemes
     tolerent mal la surcharge et les donnees echangees peuvent alors en
     patir.  Essayer  d'augmenter  les etats d'attente inseres entre les
     cycles du bus local (Richard Postgate (postgate@cafe.net)).

  +o  Fonctions d'economie d'energie ("power management", "APM")
     Certains portables, en particulier, offrent une fonction de reprise
     immediate (mode "resume") et des programmes pilotes ne tolerent pas
     toujours cela. Debrayer  ces  fonctions  ou  bien  compiler  l'"APM
     support" dans le noyau (Elizabeth Ayer (eca23@cam.ac.uk)).

  +o  Processeur defectueux
     Certains  exemplaires  des processeurs courants recelent des bogues
     aux effets pervers. Aucune solution n'existe, il faut remplacer  le
     composant.   Des  cas  d'incompatibilite  entre processeur et carte
     mere auraient ete observes. Depuis fevrier 1997 la  premiere  vague
     de   problemes,  qui  concernait  les  processeurs  Intel,  decroit
     nettement tandis que l'exploitation de processeurs  Cyrix/IBM  6x86
     sur certaines cartes mere s'avere difficile.  Le manuel d'une carte
     mere precise qu'elle est incompatible avec les  premieres  versions
     du  6x86. C'est regrettable car les performances de ces processeurs
     sont fort bonnes.

  66..  MMaaiiss ttoouutt ffoonnccttiioonnnnaaiitt ccoorrrreecctteemmeenntt ddeeppuuiiss lloonnggtteemmppss !!

  Le fait que la configuration  deficiente  fonctionnait  sans  probleme
  depuis  un  moment  n'implique malheureusement pas que le materiel est
  hors de cause.

  L'exemple  classique  concerne  les  composants  de   memoire.   Leurs
  fabricants  ne  disposent pas d'une ligne de production distincte pour
  chaque type de  memoire.  Les  circuits  proviennent  tous  des  memes
  machines  et  matieres  premieres,  seul le test final determine si un
  composant donne sera par exemple vendu en tant que 60 ns  ou  bien  70
  ns.   Vos  composants  fonctionnaient  peut-etre  a  merveille  depuis
  longtemps a la limite de leurs capacites mais  un  facteur  quelconque
  (la  temperature,  par exemple, ralentit les memoires) peut les rendre
  assez vite inadequats.

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

  77..  MMoonn pprrooggrraammmmee ddee tteesstt mmeemmooiirree nnee rreevveellee aauuccuunn pprroobblleemmee

  Le  test  memoire effectue par le BIOS lors du demarrage de la machine
  n'en est  le  plus  souvent  pas  un.  Des  conditions  d'exploitation
  extremes  peuvent  seules  permettre de lever le doute. Tester grace a
  memtest86.

  88..  LLee pprroobblleemmee eesstt--iill lliimmiittee aa llaa ccoommppiillaattiioonn dduu nnooyyaauu ??

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

  Autres cas observes :

  +o  Certaines  machines  se  bloquent parfois lorsqu'elles executent le
     script    d'installation    de    la     distribution     Slackware
     (dhn@pluto.njcc.com).

  +o  Le noyau stoppe parfois une tache a cause d'une "general protection
     error" (message confie a syslog) (fox@graphics.cs.nyu.edu).

  99..  mmaacchhiinnee !!  DD''aauuttrreess ssyysstteemmeess dd''eexxppllooiittaattiioonn ffoonnccttiioonnnneenntt  ppoouurrttaanntt
  bbiieenn ssuurr cceettttee

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

  Certains  autres  systemes,  par  exemple  edites  par  Microsoft,  se
  "plantent parfois" de facon incomprehensible. Peu d'utilisateurs  s'en
  plaignent,    semble-t-il,    et    cette    societe    leur    repond
  <http://www.cantrip.org/nobugs.html> en ce cas d'une  maniere  quelque
  peu etrange.

  Le  mode de conception et d'utilisation de ces systemes d'exploitation
  produit un ensemble le plus souvent plus "predictible" que Linux  dans
  la  mesure ou une application donnee sera le plus souvent chargee dans
  la meme section de la memoire vive.  Les  aleas  dus  a  un  composant
  defectueux  sont donc parfois portes au compte d'un programme donne et
  non du materiel.

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

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

  1100..  ssiiggnnaall 1111"" eesstt--iill llee sseeuull eeffffeett ??

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

  Autres problemes constates :

  +o  free_one_pmd: bad directory entry 00000008

  +o  EXT2-fs warning (device X:Y): ext_2_free_blocks bit already cleared
     for block Z

  +o  Internal error: bad swap device

  +o  Trying to free nonexistent swap-page

  +o  kfree of non-kmalloced memory ...

  +o  scsi0: REQ before WAIT DISCONNECT IID

  +o  Unable to handle kernel NULL pointer dereference at virtual address
     c0000004

  +o  put_page: page already exists 00000046 invalid operand: 0000

  +o  Whee.. inode changed from under us. Tell Linus

  +o  crc error    System halted  (lors du demarrage)

  +o  Segmentation fault

  +o  "unable to resolve symbol"

  +o  make 1: *** ... Error 139 make: *** ... Error 1

  +o  X Window avorte brusquement avec un mesage

  Les  premiers  exemples  relevent  d'arrets provoques 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))

  1111..  QQuuee ffaaiirree ??

  +o  Demonter des barrettes, les remplacer

  +o  Debrayer (SETUP) le cache de second niveau du processeur

  +o  Diminuer la cadence du processeur et du bus

  +o  Restaurer la cadence de rafraichissement de la memoire preconisee

  +o  Demarrer avec un noyau sous  option  "mem=4M"  pour  lui  interdire
     d'exploiter la memoire au-dessus des 4 premiers Mo

  +o  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 resultants doivent etre iden-
  tiques.  Cela exige environ 24 heures sur un P100 / 16 Mo RAM et envi-
  ron 3 mois sur un 386 / 4 Mo :-)

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

  1122..  EEtt llee tteesstt pphhyyssiiqquuee ??

  Meme certains  equipements  electroniques  de  test  des  memoires  ne
  mettent  pas toujours en evidence les problemes dont nous traitons ici
  car ils peuvent  par  exemple  dependre  du  mode  d'exploitation  des
  composants par la carte mere.

  1133..  QQuueelllleess ssoonntt lleess aauuttrreess ccaauusseess ppoossssiibblleess ??

  +o  pgcc
     Utilisation de la version de gcc "pgcc", dont le generateur de code
     est optimise pour le Pentium. La compilation, avec ses options  par
     defaut, de certains modules du noyau (par exemple floppy.c) produit
     un signal 11. Les causes se trouvent a la fois dans  le  noyau,  la
     libc  et  pgcc.  On constate vite qu'il ne s'agit pas d'un probleme
     materiel  car  il  se  produit  toujours  au  meme  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)).

  +o  Composants de gcc heteroclites
     Lorsque  les  fichiers  appartenant  a  gcc  proviennent de sources
     differentes des problemes peuvent appraitre.  Il  faut  alors  tout
     remplacer par une version complete et correcte (Richard H. Derr III
     (rhd@Mars.mcs.com)).

  +o  Edition de liens avec bibliotheque pour SCO
     Sous iBCS  les applications dont le LDFLAGS  contient  -Llib/  sont
     exposees.

  +o  a.out et ELF
     Compilation  d'un noyau a.out au sein d'un environnement ELF (ou le
     contraire).. Le premier appel a "ld" causera  toujours  un  "signal
     11"(REW).

  +o  Carte Ethernet ISA sur bus PCI mal configure
     Cela  peut  causer de graves problemes logiciels (sigsegv, arret du
     noyau...).  Il  faut  alors  utiliser  le  SETUP  pour   configurer
     l'"aperture"  (zone  de  memoire  commune  a la carte et a l'espace
     d'adressage du systeme).

  +o  Contenu de la partition de memoire virtuelle ("swap") endommage
     Tony Nugent (T.Nugent@sct.gu.edu.au) precise qu'il a pu resoudre le
     probleme en re-preparant la partition grace a "mkswap".
     Louis  J. LaBash Jr. (lou@minuet.siue.edu) nous rappelle qu'il faut
     invoquer "sync" apres un "mkswap".
  +o  Cartes Ethernet bas de gamme de type NE2000
     La qualite de certaines cartes est si mediocre qu'elles mettent  en
     peril  la  stabilite  du  systeme.  Les  noyaux Linux posterieurs a
     1.3.48 les tolerent semble-t-il mieux (REW).

  +o  Alimentation electrique
     Cas peu probable, meme une machine  tres  bien  equipee  n'approche
     guere  les  limites  des  alimentations  200  W.  Seul  un  systeme
     utilisant  de  nombreux  anciens  disques  (gros  consommateurs  de
     courant)     peut     poser    un    probleme    (Greg    Nicholson
     (greg@job.cba.ua.edu)).
     Thorsten Kuehnemann (thorsten@actis.de) indique qu'une alimentation
     defectueuse peut provoquer des signaux 11.

  +o  Compilation du code ext2
     Dans  certains  cas la compilation du code de gestion du systeme de
     fichiers   ext2   provoque   un   signal   11   (Morten    Welinder
     (terra@diku.dk)).

  +o  Memoire disponible insuffisante
     gcc    produit    alors    d'etranges    erreurs    (Paul   Brannan
     (brannanp@musc.edu)).

  1144..  CCeettttee lliissttee mmee llaaiissssee sscceeppttiiqquuee !!

  Nous ne traitons ici que de cas rreeeellss !!
  (N.d.T : la version originale <http://www.bitwizard.nl/sig11/>  de  ce
  document propose une liste des auteurs de temoignages).

