Fejezet 8. A rendszermag beállítása

Egyáltalán nem! Ezzel kapcsolatban olvassuk el a FreeBSD kézikönyv rendszermag beállításairól szóló részét.

Ez valószínűleg azért következett be, mert eltávolítottuk az npx0 (lásd npx(4)) támogatást a rendszermag beállításai közül, mert a rendszerünkben nincs matematikai társprocesszor. Az npx0 eszköz jelenléte azonban kötelező. Valahol a gépünkben lennie kell olyan eszköznek, amely a lebegőpontos számok hardveres kezelését végzi, annak ellenére, hogy nem egy különálló eszköz, ahogy régen a 386-osoknál volt. A rendszermagban szerepelnie kell az npx0 eszköznek. Ha netalán még sikerülne is npx0 támogatás nélkül fordítanunk egy rendszermagot, akkor sem tud elindulni.

Nagyon valószínű, hogy a rendszermagunk debug módban készült el. A debug módú rendszermagokban rengeteg olyan szimbólum található, amely hasznos lehet a hibák keresése és a rendszer vizsgálata során, ezért emiatt jelentős mértékben növekszik a mérete. Emiatt nem kell aggódnunk, mert egy hibakeresésre felkészített rendszermag egyáltalán nem vagy csak egy kicsivel lassabb, mint a hagyományos változat, illetve a rendszer összeomlásakor mindig mindig szükségünk lehet ezekre a debug információkra.

Ha viszont kevés a lemezterület vagy egyszerűen csak nem akarunk debug módú rendszermagot akarunk futtatni, akkor a következőkre kell figyelnünk:

• Vegyük ki a rendszermag konfigurációs állományából a következő sort:

  makeoptions DEBUG=-g

• A config(8) használata során ne használjuk a -g beállítást.

A fentiek közül akármelyiket is választjuk, a rendszermagunk debug módban jön létre. Ha azonban sikerült betartani a fentebb javasolt lépéseket, akkor egy normál rendszermagot kapunk, amely mérete ilyenkor jelentős mértékben visszaesik: a legtöbbjük olyan 1,5 és 2 MB körül van.

Ha a rendszermagot a többportos soros vonali kártyák támogatásával fordítjuk le, akkor a rendszertől azt az üzenetet kapjuk, hogy csak az első megszakítást fogja használni, a többit pedig ütközés miatt (interrupt conflict) kihagyja. Hogyan lehet ezen javítani?

A gondot alapvetően az okozza, hogy a FreeBSD a rendszermagban fixen letárolja ezeket, nehogy valamilyen hardveres vagy szoftveres ütközés miatt elkallódjanak. Ezen úgy tudunk segíteni, ha egyetlen IRQ vonal kivételével az összes többi beállítását szabadon hagyjuk. Íme erre egy példa:

#
# Többportos nagysebességű soros vonali eszközök - 16550 UART
#
device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr

Ennek több oka is lehet. Ezek közül néhány, de nem feltétlenül ebben a sorrendben:

• Nem a make buildkernel és make installkernel parancsokat használtuk és valószínűleg a forrásaink sem egyeznek meg a jelenleg futó rendszerével (például egy 8.0-RELEASE rendszert akarunk fordítani egy 7.2-RELEASE rendszeren). Ha frissíteni akarunk, akkor olvassuk el a /usr/src/UPDATING állományt, különös tekintettel a végén található “COMMON ITEMS” című szakaszra.

• A make buildkernel és make installkernel parancsokat használtuk, de előtte nem futott le rendesen a make buildworld parancs. A make buildkernel parancs ugyanis erősen támaszkodik a make buildworld által végzett munkára.

• Gyakran a FreeBSD-STABLE változat használata esetén is előfordulhat, hogy olyan pillanatban töltöttük le a forrásokat, amikor módosítás alatt voltak vagy valamiért nem működtek rendesen. Kizárólag a kiadások esetén tudjuk szavatolni a hibátlan fordítást, noha a FreeBSD-STABLE verzióból készült változatok is többnyire megfelelőek. Próbáljuk meg újra letölteni a forrásokat, ha eddig még nem próbálkoztunk volna vele, és nézzük meg, hogy ez segít-e megoldani a problémát. Keressük másik szervert, ha gondjaink vannak a frissítéssel.

Nézzük meg, hogy a rendszerünkben elérhető-e a kern.sched.quantum változó. Ha van ilyenünk, akkor valami ilyesmit kell tapasztalnunk:

% sysctl kern.sched.quantum
kern.sched.quantum: 99960

Ha létezik a kern.sched.quantum nevű sysctl változó, akkor a 4BSD ütemező fut (lásd sched_4bsd(4)). Ha nem, akkor egy ilyen hibát kapunk a sysctl(8) parancstól (ezt nyugodtan figyelmen kívül hagyhatjuk):

% sysctl kern.sched.quantum
sysctl: unknown oid 'kern.sched.quantum'

Az aktuálisan használt ütemező neve közvetlenül elérhető a kern.sched.name sysctl változó lekérdezésén keresztül:

% sysctl kern.sched.name
kern.sched.name: 4BSD

A kern.sched.quantum értéke határozza meg, hogy egy futó program legfeljebb mennyi órajelet futhat egyszerre, megszakítás nélkül. Ezt az értéket a 4BSD ütemező használja, ezért a jelenlétéből vagy hiányából következtetni tudunk a pillanatnyilag használatban levő ütemezőre.