(par exemple le noyau)�choue � cause d'un signal 11. Ce probl�me peut �tre caus� par un dysfonctionnement d'ordre mat�riel (cas le plus fr�quemment observ�) ou logiciel.
La
version originale de ce document est � pr�sent int�gr�e � la collection des
"Mini-Howto" de Linux.
La version publi�e sur le Web �tait consult�e 300 fois par semaine en juin
1996 (augmentation : facteur 3 en 3 mois).
La plus r�cente version de ce texte, librement utilisable s'il n'est pas modifi�, sur trouve sur son site de r�f�rence <URL:http://www.linux-france.com/>
Tout commentaire et compte-rendu d'exp�rience int�resse l'auteur (
Rogier Wolff <R.E.Wolff@BitWizard.nl>) mais les suggestions d'ajouts techniquement
sans valeur seront rejet�es.
Exp�dier �
nat@linux-france.com les commentaires concernant cette adaptation
fran�aise.
Note : le probl�me d�taill� ici concerne aussi les autres syst�mes un tant soit peu exigeants : Windows 3.1, FreeBSD, Windows NT, NextStep...
Cette adaptation fran�aise doit beaucoup � J. Chion.
Voici la question-cl� trait�e par ce document :
Lorsque je compile un noyau Linux la proc�dure avorte avec un message:
gcc: Internal compiler error: program cc1 got fatal signal 11
Que se passe-t-il ?
Le probl�me est vraisemblablement caus� par un dysfonctionnement du mat�riel. De nombreux composants de l'ordinateur peuvent �tre impliqu�s et diverses mani�res de r�soudre le probl�me existent.
Sit�t apr�s l'�chec du make, invoquez-le � nouveau.
Si la machine parvient � compiler quelques autres fichiers, nous pouvons penser que le mat�riel est d�faillant.
Si, par contre, la compilation cesse tout de suite (message "nothing to be done for xxxx" avant nouvel �chec au m�me endroit), il faudra d�terminer si le contenu de la m�moire vive est toujours bien pr�serv�. Pour cela :
dd if=/dev/DISQUE_DUR of=/dev/null bs=1024k count=MEGASDISQUE_DUR remplace ici le nom du fichier sp�cial associ� au disque dur stockant les sources. Pour conna�tre son nom, rester dans le r�pertoire abritant les sources et introduire
df . ("df" suivi
d'un espace puis un point).free).
Cette commande va obliger Linux � lire les informations plac�es au d�but du disque de fa�on � "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 m�me "endroit", le probl�me est probablement d'ordre logiciel. �tudier en ce cas la section consacr�e aux autres causes possibles.
Si la compilation �choue � un autre stade, nous pouvons conclure que les transferts de donn�es entre le disque et la m�moire vive ne sont pas assur�s correctement.
Linux avorte gr�ce au "signal 11" tout programme tentant d'acc�der � une adresse m�moire ne lui appartenant pas. Parmi les nombreuses causes possibles, nous ne pouvons retenir dans l'absolu que deux possibilit�s, dans le cas o� cela concerne une version stable de gcc utilis�e sur une machine tr�s commune : probl�me mat�riel ou bien inad�quation de certaines composantes des utilitaires logiciels du syst�me.
Lorsque ce probl�me survient sur une machine sans d�faut mat�riel, il ne peut �tre caus� que par une erreur de programmation ou de compilation (en l'occurrence du binaire de gcc). Mais lorsque le mat�riel est d�faillant, et que des valeurs stock�es en m�moire vive changent plus ou moins al�atoirement, un programme exigeant tel que gcc ne parviendra pas � mener � bien sa mission car il tentera t�t ou tard de d�r�f�rencer un pointeur au contenu ainsi modifi�.
Un pointeur, sur une machine � processeur Intel, s'�tend sur 32 bits et
permet donc d'acc�der � 4 Go. Peu de machines Intel disposent d'autant de
m�moire vive dont la majeure partie serait allou�e � gcc !
Une adresse de 32 bits al�atoire est donc tr�s probablement ill�gale et
Linux tuera le programme qui tente avec elle, selon lui, de manipuler des
donn�es ne lui appartenant pas.
Voici une liste des diverses causes de dysfonctionnement du mat�riel :
Inventaire des causes et solutions :
T�moignage (kettner@cat.et.tudelft.nl) : nous avons �prouv� de grandes difficult�s avec une machine dont il s'av�ra que les quatre barrettes �taient d�fectueuses et modifiaient � peu pr�s 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 ex�cuter le test m�moire durant 2300 cycles complets sans erreur, puis d�tecta environ 10 erreurs et continua ensuite sans probl�me durant plusieurs centaines de cycles. La compilation de noyau s'av�ra le test le plus efficace car m�me le cas le plus favorable ne permettait pas de compiler plus de 14 noyaux � la suite. Nous avons donc �chang� ces barrettes.
T�moignages : nous avons tr�s longtemps utilis� sans probl�me 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 r�gulation du courant.
dram,
offre le moyen de configurer le jeu de composants ("chipset") au plus bas
niveau afin d'obtenir des effets semblables.
dd
(consulter � ce propos la section consacr�e � l'
expiration du buffer cache) la compilation avortera
tr�s vraisemblablement � un autre stade.
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.
Intel indique que la temp�rature de la surface du processeur doit �tre
comprise entre :
Le fait que la configuration d�ficiente fonctionnait sans probl�me depuis un moment n'implique malheureusement pas que le mat�riel est hors de cause.
L'exemple classique concerne les composants de m�moire. Leurs fabricants ne disposent pas d'une ligne de production distincte pour chaque type de m�moire. Les circuits proviennent tous des m�mes machines et mati�res premi�res, seul le test final d�termine 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 capacit�s mais un facteur quelconque (la temp�rature, par exemple, ralentit les m�moires) peut les rendre assez vite inad�quats.
Un climat estival ou bien une lourde charge de travail processeur place donc parfois le syst�me dans des conditions o� son fonctionnement correct n'est plus certain, voire plus possible (Philippe Troin (ptroin@compass-da.com)).
Le test m�moire effectu� par le BIOS lors du d�marrage de la machine n'en
est le plus souvent pas un. Des conditions d'exploitation extr�mes peuvent
seules permettre de lever le doute. Tester gr�ce � memtest86.
Non, mais la compilation du noyau exige beaucoup de ressources et constitue donc un excellent test ou r�v�lateur.
Autres cas observ�s :
Linux exploite mieux le mat�riel que la plupart des autres syst�mes, comme ses performances le laissent imaginer.
Certains autres syst�mes, par exemple �dit�s par Microsoft, se "plantent parfois" de fa�on incompr�hensible. Peu d'utilisateurs s'en plaignent, semble-t-il, et cette soci�t� leur r�pond en ce cas d'une mani�re quelque peu �trange.
Le mode de conception et d'utilisation de ces syst�mes d'exploitation produit un ensemble le plus souvent plus "pr�dictible" que Linux dans la mesure ou une application donn�e sera le plus souvent charg�e dans la m�me section de la m�moire vive. Les al�as d�s � un composant d�fectueux sont donc parfois port�s au compte d'un programme donn� et non du mat�riel.
Une chose demeure cependant certaine : un syst�me Linux bien install� sur une machine saine doit pouvoir compiler cent fois de suite un noyau sans aucun probl�me.
T�moignage : Linux et gcc testent � merveille la machine. Hors de Linux le test "Winstone" produit le m�me genre d'effets (Jonathan Bright (bright@informix.com))
Ce n'est malheureusement pas le cas. Les signaux 6 et 4 peuvent aussi relever de ce genre de probl�me (lorsque la m�moire n'accomplit pas correctement son office n'importe quel type d'erreur peut survenir) mais le 11 est le plus commun.
Autres probl�mes constat�s :
Les premiers exemples rel�vent d'arr�ts provoqu�s 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))
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
Le moyen le plus efficace reste de remplacer tous les composants de m�moire. Ce n'est cependant pas toujours facile.
M�me certains �quipements �lectroniques de test des m�moires ne mettent pas toujours en �vidence les probl�mes dont nous traitons ici car ils peuvent par exemple d�pendre du mode d'exploitation des composants par la carte m�re.
SCO-Llib/ sont
expos�es.
Nous ne traitons ici que de cas r�els !
(N.d.T : la version
originale de ce document propose une liste des auteurs de
t�moignages).