Signal 11 kernel-fordítás közben

Ez a GYIK egy, - az utóbbi idõben egyre több embert foglalkoztató - jelenség lehetséges okait fogja taglalni. Nevezetesen, hogy a linux(*)-kernel (vagy bármelyik egyéb nagyobb csomag) fordítása ,,signal 11" üzenettel szakad meg. Az ok lehet programhiba, vagy - legvalószín\ûbben - a hardver hibája. Ezeket vesszük sorra a továbbiakban.

(*)Természetesen semmi sem Linux-függõ. Ha a számítógép elektronikája ócska, Linux, Windows, FreeBSD és NextStep esetén egyformán megszakad a fordítás.

Elvileg ez az írás a Linux Mini-Howto gyûjteményének a tagja. A http://www.bitwizard.nl/sig11/ helyen megtalálható ezen írás eredetije ill. legújabb verziója. Az eredeti szerzõ elérhet\õ az R.E.Wolff@BitWizard.nl email címen, szívesen fogadja az észrevételeket - természetesen angolul. A magyar verziót Juhos Szilveszter fordította (Szilveszter.Juhos@durham.ac.uk), elérhetõ lesz a remelem http://lma.rulez.org helyen.

A Sig11 GYIK

Kérdés:

Kernelfordítás közben a következõ üzenettel áll le a fordító:

gcc: Internal compiler error: program cc1 got fatal signal 11

Mi a baj a fordítóval? Melyik verzióját kell használnom a fordítónak? Vagy a kernellel van valami baj?

Válasz:

Feltehetõen nincs semmi baj a telepítéssel, a fordítóval, vagy a kernellel. Azonban nagyon valószín\û, hogy a hardverrel valamit tenni kell. Több dolog is hibás lehet, és többféleképp lehet helyrehozni. Pontosabb válaszokat lásd alább. Egy kivétel van: RedHat 5.0, a végefelé ezt is tárgyalom.

Kérdés:

Rendben, lehet, hogy nem a program, de hogy lehetek biztos benne?

Válasz:

Elõször is meg kell bizonyosodni róla, hogy a hardver okozza a hibát. Ha a ,,make" parancs futása megszakad, egyszer\ûen be kell gépelni újból azt, hogy ,,make". Ha a fordítás újból elindul, és nem ugyanannál az állománynál áll le, hanem még néhányat lefordít, akkor majdnem biztos lehetsz benne, hogy a hardver a hibás. Ha azonnal megáll, (persze elõtte végigfut a már lefordított részeken ,,nothing to be done for xxx"- ,,nincs mit csinálni az xxxx-en" üzenettel) mielõtt kiírja ugyanazt az üzenetet pontosan ugyanazon a helyen, próbáld a következõ parancsot lefuttatni:

dd if=/dev/hda of=/dev/null bs=1024k count=16

természetesen SCSI merevlemez esetén /dev/sda kell a /dev/hda helyett. A ,,count" értékét pedig a számítógép memóriájának (ez nem a merevlemez mérete) megabájtokban mért megfelelõ értékére állítsad be. A fenti parancs a merevlemez elsõ 16 megabájtját kiolvassa a merevlemezbõl, és biztosítja, hogy a forráskód és a gcc a következõ futáskor mindenképpen újra be lesznek olvasva a memóriába a következõ futáskor. Ha mégegyszer lefuttatva a fordítást újfent az elõzõ helyen áll meg hibával a fordító, akkor ez nem ennek a GYIK-nak a témája, mivel ez mindenképp programhibát jelent. Olvasd el a GYIK végén a ,,Mik az egyéb hibalehetõségek?" pontot.

Amennyiben a ,,dd" parancs lefuttatása nélkül a fordító ugyanazon a helyen áll le, de ez a hely megváltozik a futtatása után, akkor sajnos merevlemez->memória átviteli problémád van (szintén lásd alább).

Kérdés:

Jó, de ez az üzenet pontosan mit jelent?

Válasz:

A fordító egy olyan memóriaterülethez nyúlt hozzá, amely kívül van a fordító megengedett memória-területén. Ha ez egy jól mûködõ hardveren történik, akkor ez a fordító program hibája. Ezért kapjuk az ,,internal compiler error" - ,,fordítóprogram belsõ hiba" üzenetet. Azonban, ha egy hibás hardveren véletlenül egy bit megfordul, nagyon valószínû, hogy a gcc valamit a megengedett címzési tartományon kívülre címez, mivel rengeteg mutatót (pointert) használ (véletlen címek rendszerint a megengedett címzési tartományon kívül vannak, mivel igen kevés embernek van 4 gigabájtnyi memóriája a számítógépében).

Manapság mindenki, akinek a sig11 elõjött, ezeken az oldalakon próbál megoldást találni. Ha azonban saját szoftvert fejlesztesz, mely még nerm kész, lehetnek benne hibák, akkor a ,,sig 11'', vagy a ,,Segmentation fault'' egy erõs érv amellett, hogy valami rossz a programban. Ha azonban egy már ismerten jól mûködõ program hibázik egy jól tesztelt adathalmazon (mint pl. a gcc a Linux-kernel fordításkor), akkor rendszerint a hiba a hardverben van.

Kérdés:

Rendben. Hardver hibám van, de mi lehet az?

Válasz:

Ha ez a hardver hibája, akkor ez lehet a:

Memória. A memóriában véletlenszerûen elromolhat egy bit. Ha ez a memória írásakor történik, nem lehet semmi paritáshibát látni. Többféleképp lehet a javítással próbálkozni:
Cache memória. A cache memóriában szintén elõfordulhat bitfordulás. Ezek az áramkörök legtöbbször nincsenek paritás-ellenõrzéssel ellátva. A BIOS-ban viszont ki lehet kapcsolni használatukat, és lehet ellenõrizni, hogy ha a probléma megszûnik, akkor a cache volt a hibás. A következõképp lehet javítani ezt:
Túlhajtás. Egyes cégek (és emberek) úgy gondolják, hogy a CPU-kat túl lehet hajtani (overlock). Ez egyszer igaz, máskor nem. Esetleg ki kell kapcsolni a ,,turbo" állást (manapság legtöbb Pentiumban már nincs ,,nem-turbo" lehetõség), ellenõrizni, hogy a hiba megszûnik-e. Ellenõrizd, hogy a CPU sebessége (rá van nyomtatva, esetleg óvatosan le kell a hûtõt venni) megegyezik-e az alaplapon ill. a BIOS-ban beállítottal. Még az Intel is csinál hibát ezen a téren. Van feljegyzés róla, hogy egy hivatalos 120MHz Pentium sig11-et ad 120MHz-en, de nem 100 MHz esetén. Mivelhogy az alaplap többet dolgozik 100 MHZ esetén, nem hinném, hogy ez alaplaphiba lenne. Továbbá egy újabb 120MHz CPU probléma nélkül fut (Samuel Ramac sramac@vnet.ibm.com)
CPU hõmérséklet. Egy gyors CPU túlmelegedhet megfelelõ hûtés nélkül. Ez lehet egy rossz hûtõ miatt is. A CPU ilyenkor megbolondulhat, ha a a kernel-fordítás miatt nyúzás alá kerül. A helyzet még rosszabb, ha a LILO parancssorában a ,,HALT" kapcsolót kikapcsolod. Linux megpróbálja ezzel a paranccsal lekapcsolni a CPU-t, ha sokáig nem csinál semmit. Ez áramot takarít meg, és a CPU hõmérséklete leesik ekkor. Azaz nem találkozol a sig11 hibával, amikor pl. csak valamilyen dokumentumot javítasz, és csak akkor jön ki, amikor már hosszú ideje sok CPU-t igénylõ programot futtatsz, és a processzor teljes környezete már átmelegedett. Ha egy Fdiv-hibás Pentiumod van, akkor ajánlatos az Intelnél becserélni. Egy vadiúj CPU-t küldenek egy felszerelt, az Intel által is elfogadott hûtõventillátorral együtt. Továbbá tudni kell, hogy a legtöbb szokásos ragasztó igen rossz hõvezetõ. Van speciális hõvezetõ ragasztó, amit lehetõleg használjunk a hûtõventillátorok feltételekor (Arno Griffioen arno@ixe.net, W. Paul Mills wpmills@midusa.net, Alan Wind wind@imada.ou.dk) A megengedhetõ külsõ CPU-hõmérsékletek az Intel szerint:

A hõmérséklet mérésérõl és az itt leírtak bizonyításaképp angolul elérhetõ a következõ írás: http://pentium.intel.com/procs/support/faqs/iarcfaq.htm (különösen a következõ kérdések érdekesek: Q6, Q7 és Q13)

CPU feszültség. Némely alaplap megengedi, hogy a CPU feszültségét beállítsuk. És némely alaplapnak rossz a leírása, hogy hogyan állítsuk be a jumpereket ehhez. Egy 5V-os processzor jó ideig elmegy 3.3 V-on is (Karl Heyes krheyes@comp.brad.ac.uk).
RAM feszültség. A legtöbb memória még mindig 5V-on mûködik, de már elterjedtek a 3.3V-os memóriák is. Vigyázni kell, mert a 3.3V-os tönkre is megy 5V-on.
Local bus túlhajtás. 25MHz-en három Vesa local bus megy el, 33MHz-en csak kettõ, 40MHz-en mindössze egy, és találd ki, mennyi tud mûködni 50MHz-es frekvencián? Egy sem. Némely rendszer kiszámíthatatlan lesz, ha a VLB túl van hajtva. Még ha a VLB nincs is túlhajtva (a fenti mértékek szerint), néhány nanomásodperc elveszhet egy új VLB kártya hozzáadásakor. Azaz érdemes esetleg a ,,cache wait state" -et növelni ekkor (Richard Postgate postgate@cafe.net).
Power management (APM). Bizonyos laptopok (és ,,green" PC-k) rendelkeznek ezzel a lehetõséggel. Ez közbejátszhat a Linux mûködésében. Egyik eshetõség, hogyha sokáig nem nyúlunk a géphez, az APM a memória tartalmát kimenti a merevlemezre, és csak akkor tölti vissza a RAM-ba, amikor hozzáérünk a billentyûzethez. Ez jó ötletnek tûnik, csakhogy a Linux eszközmeghajtók nem szoktak hozzá, hogy két elérés közben kikapcsolódik az eszköz. Egyesek túlélik, mások nem. Érdemes kikapcsolni a BIOS-ban, vagy megengedni az ,,APM support" lehetõséget a kernelben (Elisabeth Ayer eca23@cam.ac.uk).
Maga a CPU. Néhanyan azt találták, hogy semmi mást nem lehet okolni a hibáért, csakis a CPU-t. Ez lehet pl. egy összeférhetetlenség a CPU és az alaplap között. Volt már egy ilyen hullám (1997 februárjában) és egy másik manapság, amely a Cyrix/IBM 6x86 CPU-kat okolta. Bár a hiba oka lehet valóban a CPU, lehet, hogy mindössze az alaplap összeférhetetlen a CPU-val. Már láttam olyan alaplapleírást, ami állította, hogy nem kompatibilis a 6x86 sorozat elsõ tagjaival. Saját tapasztalatom, hogy ezek az eszközök nem rosszak összességében, kernel fordítással ellen\õrizve a P166+ egyenl\õ a P155-el (1.3-szor gyorsabb, mint a P120).
Memory hole. Sok modern alaplap megengedi, hogy a régi ISA videokártyádat egy vagy két megabájt lineáris keret pufferrel (linear frame buffer) használd. Ehhez ezt a memóriát a 16MB alá kell helyezni. Szinte senki nem használja ezt a lehetõséget, de ha bekapcsolod a ,,memory hole'' (vagy más BIOS-okban ,,LFB support'') kapcsolót, akkor a harvered furcsán fog viselkedni (Paul Connolly pconnolly@macdux.com.au).

Kérdés:

RAM idõzítési hiba? Néhány hónapja valóban birizgáltam a BIOS beállítást, és több kernelt is lefordítottam azóta hiba nélkül. Azaz nem lehet RAM beállítás hiba, rendben?

Válasz:

Nincs rendben. Gondolod, a RAM gyártóknak van egy gyártósoruk, amely 60ns RAM-ot készít. és egy másik, ami 70ns-t? Nyilván nem. Csinálnak egy adag ugyanolyant, és ellenõrzik õket. Némelyik megfelel 60ns-nek, másik nem. Az utóbbiak lehetnének pl. a 61ns-osak, ha a gyártó rátenné a valós címkét. Ebben az esetben nagyon valószínû, hogy mûködik rendesen, amíg a hõmérséklet nem megy 40 C fölé (a chipek lassulhatnak magasabb hõmérsékleten, ezért kell a szuperszámítógépeket annyira hûteni). Azonban a nyár (vagy egy hosszú fordítási feladat) a bizonyos tûrési határ fölé emelheti a hõmérsékletet a számítógép belsejében (Philippe Troin ptroin@compass-da.com).

Kérdés:

Megjártam, hogy nem vettem drágább ECC memóriát. Kicsivel többet áldoztam volna a gépre, most nem lenne hibás a hardverem.

Válasz:

Ha ilyen drágább ECC memóriát vagy alaplapot veszel, akkor azokat a ritka hibákat szûröd ki, melyet a szóródó alfa-részecskék okoznak. Ezek rendszertelenül jönnek elõ. Mivel legtöbb ember fél órán belül képes a gcc-vel sig11-et elõhozni, de akár órákon át is hibátlanul teszteleheti ugyanazt a memóriát más programokkal, ez engem arról gyõz meg, hogy nem egy alfa-részecske fordított meg egy bitet. Ezt a memória-teszt is kihozta volna. Azaz valami más történt. Az a benyomásom, hogy a legtöbb sig11 a CPU <-> cache <-> memória úton történõ idõzítési hiba eredménye. Ebben az esetben ECC nem segít rajtad. Mikor vegyél esetleg mégis ECC memóriát? a) Ha úgy érzed szükséged van rá. b) Ha NAGYON sok RAM-ra van szükséged (nem tudom megmondani, mennyi is az a NAGYON sok, ez idõvel változik). Néhányan mindenkinek azt tanácsolják, hogy ECC RAM-ot vegyen. Én csak az a) pontot állítom.

Kérdés:

Memóriaprobléma? A BIOS mindig ellenõrzi a memóriát, és rendben találja. Van egy spéci DOS programom is, ami ellenõrzi, és az sem jelzett hibát, tehát nem lehet az.

Válasz:

Ez így nem teljes. A BIOS memória-ellenõrzése teljesen használhatatlan. Néha még a valóban elérhetõnél többet is gond nélkül leellenõriz, és kiírja, hogy ,,OK". Egy barátomnak Van egy 640k PC-je és egy 64k-s modullal a második bankban a 256k helyett. Ez azt jelenti, hogy 320k memóriája van, a BIOS azonban néha azt jelzi, hogy 384k memóriát leelenõrzött, és rendben talált. Persze a több memóriát kívánó alkalmazások nem mûködnek, de elég nehéz volt megtalálni a probléma forrását.

A legtöbb memóriahiba csak bizonyos körülmények között jön elõ. Sajnos nem is biztos, hogy megtudjuk, mik is ezek a körülmények, de a gcc úgy tûnik a legjobb próba. Memóriatesztek, - a BIOS teszt különösen- nem megbízhatóak. Szeretnék készíteni egy bootolható floppy-t, amelyen egy kernel és egy jó memória-ellenõrzõ program van. Még nincs kész floppy, de a ha van egy már mûködõ Linux géped, akkor az ellenõrzõ programot kipróbálhatod. Elérhetõ a http://www.bitwizard.nl/sig11/memtest.tar.gz (bináris) és a http://www.bitwizard.nl/sig11/memtest.tgz.uue (uuencode-olt) helyeken. Próbálok valami még jobbat csinálni, de arra még várni kell.

Szokásosan a memória-tesztelõ programok kevés CPU parancsot használnak, és a memória-elérési minták is meglehetõsen rendezettek bennük. Ilyen körülmények között kevés memóriachip fog hibásan mûködni. Ha villamosmérnöknek tanulsz, és érdekel a memória-tesztelés, egy doktori disszertáció biztos kijönne belõle. Vannak olyan cégek, melyek minden bizonnyal szponzorálnának is egy ilyen témát, mely megnézné azokat a hardver elemeket, melyek átmennek a gyári ellenõrzésen, a vásárlóknál meg mégis hibásan mûködnek.

Kérdés:

Csak kernel-fordításkor jön elõ ez a hiba?

Válasz:

Dehogy. A harvered soha nem ,,tudja" hogy éppen kernelt fordítasz. Egyszerûen a kernelfordítás igénybe veszi a hardvert, ezért leginkább ekkor történik. De:

Kérdés:

Semmi nem omlik össze NT, Win95, OS/2 vagy DOS alatt. Ennek Linux-függõnek kell lennie.

Válasz:

Elõször is, Linux sokkal jobban kihasználja a hardvered, mint az fentiek. Némely operációs rendszerek, mint pl. a Microsoft által gyártottak megjósolhatatlanul omlanak össze. Senki nem hívja fel a Microsoftot, hogy: ,,Hé, ma összeomlott a Windows-om!". Ha mégis megteszed, akkor elmondják Neked, hogy Te, a felhasználó hibáztál (lásd az interjút egy német magazinban Bill Gates-el), és mivel újraindítás után mûködik, fogd be a szád. Ezek a rendszerek mégis valahogy megjósolhatóbbak, mint a Linux. Ez többek között azt jelenti, hogy pl. az Excel mindig ugyanarra a memória-területre kerül. Így a bit-fordulás után az Excel összeomlik. Vagy valamelyik másik program dõl össze az Excel miatt. Akárhogyis, az fog látszódni, hogy egy program hibázik, de ennek semmi köze a memóriához. Amiben biztos vagyok, hogy egy hibátlanul telepített 1.2.13-as Linux rendszeren gond nélkül le kell hogy forduljon a kernel. Semmikép nem sig11-el (kivétel: RedHat 5.0, lásd alább).

Valójában a Linux és a gcc sokkal jobban megnyúzza a hardvered, mint bármely más operációs rendszer. Ha valami nem-linuxos programra vágysz, ami keményen átgyúrja a hardvered, egészen a végletekig, a Winstone-t tudom ajánlani (Jonathan Bright bright@informix.com).

Kérdés:

Csak signal 11 lehet kernel-fordításkor?

Válasz:

Persze nem, más hibák mint sig 6, és sig 4 is elõfordulhatnak. Azonban a sig 11 a leggyakoribb. Mikor a memória megsérül, bármilyen hiba elõjöhet. Hibás programok mág a vártnál is több hibát eredményezhetnek. Azonban az esetek túlnyomó többségében sig 11-el áll le a gcc. Ennek ellenére még a következõ üzeneteket kaphatjuk:

Az elsõ néhány üzenet olyan, ahol a kernel azt tételezi fel, hogy kernel-programozási hiba van, pedig esetleg hibás memória okozta. Az utóbbiak olyan alkalmazásokat mutatnak, melyek hibásan álltak le. S. G. de Marinis (trance@interseg.it) Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)

Kérdés:

Mit lehet tenni?

Válasz:

Az összes generált logfájlnak egyeznie kell (diff) - az elsõ ,,make zImage" azért van külön, hogy a függõségek (dependencies) is generálódjanak. Ez kb 24 órába kerül egy 100 MHz Pentiumon 16MB memóriával (és három hónapba 386/4MB esetén :-)

A fentieket mindenki meg szokta csinálni, egyedül a memória kölcsönzést hagyják ki, márpedig enélkül a lépés nélkül nehéz különbséget tenni a lehetséges hibák között. Mivel a memória pénzbe kerül, jobb lenne nem erre az eredményre jutni, de ez van. Rengeteg visszajelzést kaptam, melybõl kiderült, hogy a memória volt a ludas. De a chipek nem vesznek teljesen el: legtöbbször be lehet cserélni egy másik, vagy több RAM-ra.

Kérdés:

A RAM-omat nem holmi programmal, hanem egy ellenõrzõ mûszerrel ellenõriztem, és rendben találta. Tehát a RAM nem lehet hibás.

Válasz:

Nem igaz. A mai chipekben olyan hibák is elõfordulhatnak, melyeket nem találnak meg a RAM-ellenõrzõ mûszerek. Vagy, az alaplapod olyan módon éri el a memóriát, hogy az megzavarodik, de csak a Te alaplapodban. De szerencsére eladhatod a RAM-ot másnak, aki bízik a RAM-tesztelõ áramkörében.

Kérdés:

Mik az egyéb hibalehetõségek?

Válasz:

A következõ lehet még: