Le probleme du signal 11

Le probleme du signal 11
Rogier Wolff ([email protected]
<mailto:[email protected]>)
(traduit par Nat Makarevitch [email protected]
<mailto:[email protected]>)
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.

11.. AA pprrooppooss ddee ccee ddooccuummeenntt

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 <[email protected]>
<mailto:[email protected]>) mais les suggestions d'ajouts
techniquement sans valeur seront rejetees.
Expedier a [email protected] <mailto:[email protected]> 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.

22.. QQuueessttiioonn ccllee

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 ?

22..11.. RReeppoonnssee ssuucccciinnccttee

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.

33.. CCoommmmeenntt ss''aassssuurreerr qquuee llee mmaatteerriieell eesstt eenn ccaauussee ??

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.

44.. QQuuee ssiiggnniiffiiee ccee ""ssiiggnnaall 1111"" ??

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.

55.. QQuueell ccoommppoossaanntt iinnccrriimmiinneerr ??

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 ([email protected]) : 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
([email protected])).

Paul Gortmaker ([email protected]) 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 ([email protected]), Ron Tapia
([email protected])) : 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
([email protected])).

+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 ([email protected])) 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 ([email protected]), W.
Paul Mills ([email protected]), Alan Wind ([email protected]))

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 ([email protected]))

+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 ([email protected])).

+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 ([email protected])).

+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.

66.. MMaaiiss ttoouutt ffoonnccttiioonnnnaaiitt ccoorrrreecctteemmeenntt ddeeppuuiiss lloonnggtteemmppss !!

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 ([email protected])).

77.. MMoonn pprrooggrraammmmee ddee tteesstt mmeemmooiirree nnee rreevveellee aauuccuunn pprroobblleemmee

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.

88.. LLee pprroobblleemmee eesstt--iill lliimmiittee aa llaa ccoommppiillaattiioonn dduu nnooyyaauu ??

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
([email protected]).

+o Le noyau stoppe parfois une tache a cause d'une "general protection
error" (message confie a syslog) ([email protected]).

99.. mmaacchhiinnee !! DD''aauuttrreess ssyysstteemmeess dd''eexxppllooiittaattiioonn ffoonnccttiioonnnneenntt ppoouurrttaanntt
bbiieenn ssuurr cceettttee

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 ([email protected]))

1100.. ssiiggnnaall 1111"" eesstt--iill llee sseeuull eeffffeett ??

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 ([email protected]), Dirk Nachtmann
([email protected]))

1111.. QQuuee ffaaiirree ??

+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.

1122.. EEtt llee tteesstt pphhyyssiiqquuee ??

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.

1133.. QQuueelllleess ssoonntt lleess aauuttrreess ccaauusseess ppoossssiibblleess ??

+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 ([email protected])).

+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
([email protected])).

+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 ([email protected]) precise qu'il a pu resoudre le
probleme en re-preparant la partition grace a "mkswap".
Louis J. LaBash Jr. ([email protected]) 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
([email protected])).
Thorsten Kuehnemann ([email protected]) 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
([email protected])).

+o Memoire disponible insuffisante
gcc produit alors d'etranges erreurs (Paul Brannan
([email protected])).

1144.. CCeettttee lliissttee mmee llaaiissssee sscceeppttiiqquuee !!

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