Fejezet 5. Hibaelhárítás

A válasz nagy valószínűséggel a fizikai és virtuális memóriacímek közti különbségben rejlik.

A legtöbb PC-s hardvereszköz megegyezés szerint a 3,5 GB és 4 GB közti memóriaterületet speciális célokra tartja fenn (általában a PCI számára). Ezen a címterületen keresztül éri a PCI eszközöket. Ennek egyik következménye, hogy a fizikai memória ezen a részen nem érhető el.

Hogy pontosan mi történik az itt elhelyezkedő memóriával, teljesen a hardvertől függ. Sajnálatos módon bizonyos eszközök semmilyen megoldást nem nyújtanak a problémára, és így lényegében az utolsó 500 MB-nyi memória elveszik.

Szerencsére a legtöbb eszköz azonban képes ezt a területet egy felsőbb címre leképezni, így ki tudjuk használni. Ilyenkor azonban tapasztalhatunk némi félreértést, amikor megnézzük a rendszerindítás közben megjelenő üzeneteket.

A FreeBSD 32 bites változata esetén ez a memóriaterület elveszik, mivel a címe a 4 GB-os határ felé kerül, amelyet a 32 bites módban futó rendszermag már nem képes elérni. Ezen egy PAE támogatással rendelkező rendszermag használatával segíthetünk. A GYIK-on belül ebben a bejegyzésben olvashatunk bővebben a memóriakorlátokról, valamint ebben a részben láthatjuk a különböző platformokra vonatkozó memóriakorlátozásokat.

A FreeBSD 64 bites változata vagy a PAE használata esetén azonban a FreeBSD rendesen felismeri és leképezi a fennmaradó memóriaterületeket, így azok használhatóvá válnak. A rendszerindítás során azonban az előbb említett leképezés miatt látszólag úgy fog tűnni, mintha a FreeBSD több memóriát észlelne, mint amennyivel valójában rendelkezünk. Ez teljesen normálisnak tekinthető és a ténylegesen elérhető memória mennyisége a folyamat végén be fog állítódni.

A SCSI-meghajtók esetében a meghajtó általában képes önmagától átképezni az ilyen szektorokat. A legtöbb meghajtóban ez a lehetőség viszont alapból nem engedélyezett.

A hibás szektorok átképezéséhez az eszköz első lapmódját kell átírnunk, amelyet (root felhasználóként) így tehetünk meg:

# camcontrol modepage sd0 -m 1 -e -P 3

Változtassuk meg az AWRE (az írás automatikus átképzése) és ARRE (az olvasás automatikus átképzése) beállítások értékeit 0-ról 1-re:

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

A modernebb IDE-meghajtók is képesek a vezérlőjükkel nyilvántartani az időközben meghibásodott szektorokat, és ezt általában alapból engdélyezik.

Ha rossz szektorokra figyelmeztető hibaüzeneteket látunk (akármilyen típusú meghajtónk is legyen), az kétségtelenül arra utal, hogy ideje lecserélnünk a hardvert. A hibás szektorok használatát esetleg a gyártó saját diagnosztikai programjával le tudjuk tiltani, de hosszabb távon mindenképpen az lesz a legjobb, ha veszünk egy újat.

Ez tulajdonképpen egy ismert probléma. A HP Netserver gépekben egy integrált EISA buszos SCSI-vezérlő található, amely a 11-es EISA bővítőhelyen található, ezért az összes “valódi” EISA bővítőhely ez előtt helyezkedik el. Sajnos a 10 feletti EISA bővítőhelyek címei ütköznek a PCI eszközök számára kiosztott címekkel, ezért a FreeBSD önmagától nem tudja valami jól kezelni az ilyen helyzeteket.

Ezért a legjobban akkor járunk, ha egyszerűen letagadjuk a címterek ütközését :) Ezt úgy tudjuk megtenni, ha a rendszermag EISA_SLOTS nevű beállítását a 12 értékre állítjuk. Ezután már csak be kell konfigurálunk és újra kell fordítanunk a rendszermagot, ahogy azt a kézikönyv megfelelő része is tárgyalja.

Természetesen, amikor egy ilyen gépre akarunk telepíteni, a helyzet tovább bonyolódik. A telepítést úgy tudjuk megoldani, ha a UserConfig programon belül alkalmazunk egy apró trükköt. Most ne a “vizuális” felületét használjuk, hanem a parancssoros részt. Gépeljük be, majd a megszokottak szerint telepítsük a rendszert:

eisa 12
quit

Ettől függetlenül természetesen továbbra is javasolt egy, az előbbiek szerint módosított rendszermagot fordítanunk és telepítenünk.

A következő verziókban remélhetőleg már lesz valamilyen megoldás erre a problémára.

Ezt a hibát általában a megszakítások ütközése okozza (például két kártya ugyanazt a megszakítást akarja használni). Indítsuk a rendszerünket a -c beállítás használatával és az ed0/de0/... bejegyzéseket változtassuk meg a kártyáknak megfelelően.

Ha a hálózati kártyánkon BNC típusú csatlakozó található, akkor még előfordulhat, hogy azért látunk ilyen hibaüzeneteket, mert nem jól zártuk le a csatlakozást. Ezt úgy tudjuk könnyen ellenőrizni, ha a lezárót közvetlenül a kártyára dugjuk rá (kábel nélkül) és figyeljük, hogy továbbra is jönnek-e a hibaüzenetek.

Egyes NE2000-kompatibilis kártyák akkor adják ezt a hibát, ha az UTP portjukon nincs aktív összeköttetés vagy nem dugtuk be a kábelt.

Az ilyen típusú kártyák néha hajlamosak elfelejteni a beállításaikat. Frissítsük a kártya beállításait a 3c5x9.exe program segítségével.

Ha csupán annyi a problémánk, hogy a nyomtató irdatlanul lassan működik, akkor próbáljuk meg a kézikönyv nyomtatásról szóló részében leírtakhoz hasonlóan átállítani a nyomtató portkezelését.

Ezek a hibák akkor keletkeznek, amikor a futó programok olyan memóriaterülethez próbálnak meg hozzáférni, amihez eredetileg nem lenne szabad. Ha valami ehhez hasonló történik a rendszerünkben látszólag teljesen véletlenszerűen, akkor nagyon óvatosan kezdjünk el vizsgálódni.

A lehetséges okok az alábbiak lehetnek:

1. Ha csak olyan alkalmazások esetében jelentkezik ez a hiba, amelyeket mi magunk fejlesztünk, akkor az valószínűleg arra utal, hogy valamelyik része hibásan működik.

2. Ha a FreeBSD alaprendszerének valamelyik részében tapasztalunk ilyen hibákat, akkor azt szintén okozhatja hibás kód, de az ilyen hibákat általában hamarabb meg szokták találni és ki szokták javítani, mint ahogy a GYIK-ot olvasók többsége találkozna velük (a -CURRENT ág pontosan ezt a célt szolgálja).

Előfordulhat, hogy ez egy olyan furcsaság eredménye, amely nem a FreeBSD hibája: például ugyanazon program fordításakor mindig mást csinál a fordítóprogram.

Például tegyük fel, hogy a make buildworld parancsot futtatjuk, és a fordítás félbeszakad, amikor az ls.c állományból el akarja készíteni az ls.o állományt. Ha ezután megint megpróbáljuk kiadni a make buildworld parancsot, akkor a fordítás ugyanazon a helyen újból meghiúsul — valószínűleg hibás a forráskód, frissítsük a forrásainkat és próbáljuk meg ismét. Ha viszont a fordítás ilyenkor már egy másik helyen akad el, akkor szinte biztos, hogy hardverhibával akadtunk össze.

Amit ilyenkor tenni tudunk:

Az első esetben egy nyomkövető, például a gdb(1) segítségével keressük meg a program azon pontját, ahol rossz memóriaterülethez próbál meg hozzáférni és javítsuk ki.

A második esetben ellenőrizzük, hogy nem a hardver a hibás.

Ennek okai többek közt a következők lehetnek:

1. Túlmelegednek a merevlemezeink: ellenőrizzük, hogy a gépben található ventillátorok rendesen működnek-e (persze előfordulhat, hogy más eszközök melegednek túl).

2. A processzor túlmelegedett: lehet, hogy mert túlságosan nagy órajelen járatjuk, vagy mert egyszerűen leállt a hűtése. Akármelyik eset is következett be, legalább a hiba felderítéséig állítsuk vissza a hivatalos sebességére.

   Ha feltétlenül ragaszkodunk a rendszerünk tuningolásához, akkor érdemes elgondolkoznunk azon, hogy egy lassabb rendszerrel jobban járunk, mint egy állandóan cserélendő, ropogósra sült rendszerrel. Az emberek általában nem is nagyon szeretik az ilyen rendszereket, független attól, hogy szerintünk érdemes-e ilyet csinálni vagy sem.

3. Hibás memóriamodulok: ha több SIMM és DIMM modul is található a gépünkben, akkor vegyük ki az összeset és próbáljuk ki mindegyiket egyesével, ezzel is leszűkíthetjük a probléma felderítését a hibás DIMM/SIMM modulokra vagy azok kombinációjára.

4. Az alaplap túlbecslő értékei: a BIOS beállításai között vagy az alaplapon található jumperekkel szabályozni tudjuk a különböző időzítéseket, ahol általában az alapértelmezett értékek megfelelnek, de néha előfordulhat, hogy a memóriamodulok késleltetését lassúra, vagy éppen turbó sebességre állítják (“RAM Speed: Turbo” vagy ehhez hasonló néven keressük a BIOS-ban), ami szintén okozhat furcsa viselkedést. Próbáljuk meg visszaállítani az BIOS alapértelmezett értékeit, de előtte érdemes lejegyezni az aktuális beállításainkat.

5. Az alaplap zajos vagy kevés áramot kap: ha vannak használaton kívüli I/O kártyáink, merevlemezeink, CD-meghajtóink a rendszerünkben, akkor próbáljuk meg ideiglenesen eltávolítani ezeket vagy egyszerűen csak lehúzni róluk a tápkábelt. Ezzel tudjuk vizsgálni, hogy a számítógépünk tápegysége képes-e megbirkózni a kisebb terheléssel. Esetleg kipróbálhatunk egy másik tápegységet is, lehetőleg egy kicsivel erősebbet (például ha a jelenlegi tápegységünk teljesítménye 250 watt, akkor használjunk helyette egy 300 wattosat).

Továbbá érdemes lehet még elolvasnunk a SIG11 GYIK-ot (lásd lentebb), ahol mindezeket a problémákat részletesen kifejtik, noha a Linux® nézőpontjából. Arról is olvashatunk benne, hogy egy hibás memóriát miért nem képesek észlelni a szoftveres vagy hardveres tesztelőeszközök.

Végezetül, ha az egyik javaslat sem segített a probléma megoldásában, akkor valószínűleg sikerült hibát találnunk a FreeBSD kódjában, amiről nyugodtan írhatunk a fejlesztőknek egy hibajelentést.

A problémáról minden részletre kiterjedő módon A SIG11-es probléma GYIK-ja írásban olvashatunk (angolul).

A FreeBSD fejlesztői nagyon kíváncsiak az ilyen hibákra, de a felderítéséhez sajnos jóval több információra van szükségük, mint amennyit láthattunk. Másoljuk le az összeomláshoz tartozó teljes üzenetet. Ezután nézzük meg a GYIK-nak azt a részét, amely a rendszermag összeomlásáról szól, készítsünk egy nyomkövetési információkkal ellátott rendszermagot és kérjük le a hívási láncot. Ez elsőre talán bonyolultnak hangzik, de ehhez igazából nem igényel semmilyen programozási tudást, egyszerűen csak a megadott utasításokat kell követnünk.

Ez az ATI Mach 64 videokártyák esetében jelentkező probléma. Ilyenkor az a gond, hogy a kártya a 0x2e8 címet használja, akárcsak a negyedik soros port. A sio(4) meghajtóban levő hiba (vagy netalán beállítás?) miatt azonban a negyedik soros portot még akkor is használni fogja, ha kikapcsoljuk a sio3 (a negyedik soros port) eszközt.

A hibát kijavításáig így kerülhetjük meg:

1. A betöltő parancssorában adjuk meg a -c paramétert. (Így elő tudjuk hozni a rendszermag konfigurációs módját.)

2. Kapcsoljuk ki a sio0, sio1, sio2 és sio3 eszközöket (tehát mindegyiket). Emiatt a sio(4) meghajtó nem indul el, és így nem okoz problémát.

3. Lépjünk ki és folytassuk a rendszer indítását.

Ha a soros portokat is használni akarjuk, akkor következő módosításokkal készítsünk egy új rendszermagot: a /usr/src/sys/dev/sio/sio.c (vagy pc98 esetén a /usr/src/sys/pc98/cbus/sio.c) állományban keressük meg a 0x2e8 karakterláncot és az azt megelőző vesszőt távolítsuk el (de az utána következőt tartsuk meg). Miután végrehajtottuk ezt a módosítást, a megszokott módon fordítsuk újra a rendszermagot.

Mivel FreeBSD a BIOS-tól próbálja megtudni a rendelkezésre álló memória méretét, ezért csak 16 biten képes lekérdezni a KB-okban (vagyis 65 535 KByte = 64 MB, vagy még ennél is kevesebb, mivel egyes BIOS-ok legfeljebb 16 MB memóriát engednek látni). Tehát ha 64 MB-nál több memóriával rendelkezünk, akkor a FreeBSD ugyan megpróbálja azt felderíteni, de nem feltétlenül fog sikerülni.

Ezt úgy tudjuk megoldani, ha a rendszermag alábbi beállítását használjuk. Alapvetően ugyanis létezik egy módszer, amivel le lehet kérdezni a memória teljes méretét a BIOS-tól, de a hozzá tartozó rutin nem fért el a rendszerindító blokkban. Ha egyszer majd sikerül neki helyet csinálni, akkor a rendszer képes lesz kizárólag ezzel a módszerrel dolgozni. Amíg viszont ez nem így van, addig kénytelenek leszünk a most következő megoldást választani:

options MAXMEM=N

ahol N a memória Kilobyte-okban megadott mérete. Tehát egy 128 MB memóriával rendelkező számítógép esetén ez 131072.

A FreeBSD általában a rendszermag néhány fontos paraméterét, mint például az egyszerre megnyitható állományok maximális számát a számítógépben található memória méretéből származtatja. Az 1 GB memóriánál több esetén azonban elképzelhető, hogy ez az “automatikus méretezés” túlságosan is nagy értékeket választ. Így a rendszer indításakor a rendszermag olyan nagy méretű táblázatokat és egyéb struktúrákat foglal le, amelyek betöltik a rendelkezésére bocsátott terület nagy részét. Később, a rendszer futása közben pedig a rendszermag szépen lassan kifogy a dinamikus memóriaterületekből és összeomlik.

Készítsünk egy olyan saját rendszermagot, ahol a VM_KMEM_SIZE_MAX beállítást megnöveljük egészen a maximális 400 MB-os értékig (options VM_KMEM_SIZE_MAX=419430400). 400 MB használata valószínűleg elég lesz egészen 6 GB memóriáig.

Ez a hibaüzenet arra utal, hogy a rendszer kifogyott a hálózati pufferek (különösen az mbuf klaszterek) számára kiosztott virtuális memóriából. Az mbuf klaszterek részére fenntartott virtuális memória méretének beállításáról a kézikönyv Hálózati korlátozások című szakaszában olvashatunk.

A FreeBSD rendszermagja egyszerre csak bizonyos számú programot enged futni. Ezek konkrét száma a kern.maxusers sysctl(8)-változótól függ. A kern.maxusers ezenkívül még hatással van más belső korlátokra is, például a hálózati pufferekre (lásd ezt a korábbi kérdést). Ha a számítógépünk túlságosan leterhelt, akkor érdemes megpróbálkoznunk a kern.maxusers értékének növelésével. Ennek átállítása a rendszerben egyszerre futtatható maximális programok számával együtt sok más rendszerszintű korlátozást is finomít.

A kern.maxusers értékének beállításához nézzük meg a kézikönyv Az állományok és futó programok korlátozásairól szóló szakaszát. (Miközben ez a rész a megnyitható állományok maximális számáról szól, addig ugyanez érvényes a futó programokra is.)

Ha viszont a számítógépünk nem éri akkora terhelés, de mégis szeretnénk egyszerre nagyobb számú programot is futtatni rajta, akkor ehhez elegendő csak kern.maxproc változót átállítanunk. Ezt úgy tudjuk megtenni, ha felvesszük a /boot/loader.conf állományba. Ez az érték természetesen addig nem beállítódni, amíg a rendszerünket újra nem indítjuk. Ezekről a változókról a loader.conf(5) és sysctl.conf(5) man oldalakon tájékozódhatunk részletesebben. Ha az összes programot egyetlen felhasználóval akarjuk futtatni, akkor a kern.maxprocperuid változót értékét is át kell állítanunk, méghozzá a kern.maxproc új értékénél eggyel kisebbre. (Ezért kell így csinálni, mert egy rendszerprogram, az init(8) mindig fut.)

A sysctl változók beállításait úgy is tudjuk véglegesíteni, ha felvesszük ezeket az /etc/sysctl.conf állományba. A kézikönyv A rendszermag korlátainak finomhangolása című szakaszában részletesebb is olvashatunk róla, hogy miként állítsuk be a rendszerünket.

Az elavult /var/db/kvm_*.db állományokat összegyűjtő rutin időnként nem működik megfelelően, és a nem egyező állományok esetén össze is omolhat.

Amikor ilyen történik, indítsuk újra a rendszert egyfelhasználós módban és gépeljük be:

# rm /var/db/kvm_*.db

Ez az Ultrastor SCSI vezérlőkártya ütközésére utal.

A rendszerindítás közben lépjünk be a rendszermag konfigurációs menüjébe és tiltsuk le a gondot okozó uha0 eszközt.

Az alaplapon nem található olyan áramkör, amely támogatja az automatikus lezárást (“automatic termination”). A SCSI BIOS-ban az automatikus lezárás helyett adjuk meg a megfelelő lezárást. Az ahc(4) meghajtója nem képes rendesen érzékelni a kábeleket, ha az alaplapon van ilyen érzékelés (és így automatikus lezárás). A meghajtó egyszerűen annyit feltételez, hogy ennek támogatása csak akkor érhető el, ha az EEPROM-ban megadtuk az “automatic termination” beállítást. A megfelelő kábeldetektáló eszköz nélkül a meghajtó gyakran rosszul állapítja meg a lezárást, ami pedig így veszélyezteti a SCSI busz megbízhatóságát.

Erről részletesebben a kézikönyvben olvashatunk.

Előfordulhat, hogy az adott távoli gépen a terminál típusa nem cons25, amire viszont a FreeBSD konzolnak a megfelelő működéshez szüksége lenne.

Ezt a problémát többféle módon is meg tudjuk kerülni:

• Mikor bejelentkezünk a távoli gépre, állítsuk a TERM környezeti változót az ansi vagy sco értékre, amiből kiderül, hogy egyáltalán ismeri ezeket a termináltípusokat.

• A FreeBSD konzolban használjunk VT100 emulátort, például a screen alkalmazást. A screen segítségével egyetlen terminálról egyszerre több munkamenetet is tudunk indítani, de egyébként is egy nagyon jó program. Minden screen által létrehozott ablak VT100-as terminálként működik, ezért a távoli gépen a TERM környezeti változó nyugodtan beállítható a vt100 értékre.

• Tegyük hozzá a cons25 bejegyzést a távoli gép terminálokat tároló adatbázisához. Ez pontos módszere jelentős mértékben függ az adott gépen található operációs rendszertől. Ebben leginkább az adott gépen található man oldalak tudnak segíteni.

• Indítsunk el a FreeBSD rendszert futtató gépen egy X szervert és a távoli gépről egy X rendszerre íródott terminálemulátorral, például az xterm vagy az rxvt programmal jelentkezzük be. A távoli gépen ekkor a TERM változó értéke vagy xterm, vagy pedig vt100 lesz.

Ennek az okait a következő levélben fejtette ki Peter Wemm <peter@FreeBSD.org> a FreeBSD general questions levelezési lista tagjainak, amelyben arra válaszolt, hogy egy belső modemet miért nem észlel a rendszer miután frissítették FreeBSD 4.X-re (az érthetőség kedvéért szögletes zárójelek között hozzáadtunk néhány kiegészítést is).

A PNP BIOS beállította [a modemet] és magára hagyta valahol a portok számára fenntartott címtérben, így az ISA eszközök régi típusú [3.X-ben levő] eszközpróbálgatásai ott “találták” meg.

A 4.0 esetében azonban az ISA eszközöket kezelő kód már sokkal inkább a PnP támogatására koncentrál. Korábban [a 3.X verziókban] előfordulhatott az is, hogy az ISA eszközök keresése során a rendszer egy “kóbor” eszközt talált, majd ugyanazt megtalálta PnP eszközként és ütköztek az így duplán lefoglalni kívánt erőforrások. Ennek kivédésére először tehát letiltjuk a programozható kártyák felderítését, így ez a típusú kettős detektálás nem történhet meg. Ez továbbá azt is jelenti, hogy a támogatott PnP hardverek azonosítóit előre ismerni kell. Ennek hangolhatóságát már tervbevettük.

Tehát egy ilyen eszköz működtetéséhez szükségünk lesz a PnP azonosítójára, valamint arra, hogy felvegyük a felderítendő PnP eszközök ISA eszközök közé. Ezt a pnpinfo(8) segítségével kérhetjük le, amely például egy belső modem esetén a következő kimenetet fogja adni:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[a többi részt kihagytuk]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

Innen a Vendor ID kezdetű sorra lesz szükségünk. A zárójelek között szereplő hexadecimális szám (ami a példában a 0x3024a341) lesz az eszköz PnP azonosítója, valamint a közvetlenül ez előtt szereplő karakterlánc az egyedi ASCII azonosítója (PMC2430).

Ha a pnpinfo(8) lefuttatásának eredményeképpen megjelenő lista nem tartalmazza a kérdéses eszközt, akkor helyette a pciconf(8) használatával is próbálkozhatunk. Íme a pciconf -vl parancs kimenete egy integrált hangkártya esetében:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

Ebből a chip változót, vagyis a 0x24158086 értéket kell felhasználnunk.

Ezt az információt (a Vendor ID vagy a chip értékét) ezután a /usr/src/sys/dev/sio/sio_isa.c állományba kell felvennünk.

Ehhez először is készítsünk egy biztonsági másolatát a sio_isa.c állományról arra az esetre, ha véletlenül valami rossz történne. Ez azért is hasznunkra fog válni, mert így tudunk egy javítást mellékelni a hibajelentésünk mellé (mert ugye írni fogunk róla hibajelentést, ugye?). Szóval, keressük meg a sio_isa.c állományban a következő sort:

static struct isa_pnp_id sio_ids[] = {

Menjük lentebb egészen addig, amíg nem találunk egy helyet, ahova be tudunk szúrni egy bejegyzést az eszközünkhöz. A bejegyzések megadásának módja lentebb látható, és a jobb oldalt megjegyzésbe tett ASCII Vendor ID szerint rendezettek, amelyek mellett még megtalálható (amennyiben kifér) a pnpinfo(8) Device Description kimenetében kapott érték is:

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */

A megfelelő helyre ezután vegyük fel az eszközünkhöz tartozó hexadecimális Vendor ID értéket, mentsük el az állományt, fordítsuk újra a rendszermagot és indítsuk újra vele a rendszerünket. Ha mindent jól csináltunk, akkor az eszköz sio eszközként fog megjelenni.

A gondot alapvetően az okozza, hogy a kérdéses alkalmazás valamiért egy olyan rendszermagbeli szimbólumot keres, amit nem talál. Ez a típusú hiba a következőkből eredhet:

• A rendszermag és a hozzá tartozó programok nincsenek szinkronban (vagyis fordítottunk egy új rendszermagot, de nem volt installworld vagy fordítva) és emiatt a szimbólumokat tároló táblázat nem teljesen úgy épül fel, ahogy azt az alkalmazás gondolja. Ha erről lenne szó, akkor egyszerűen nincs más teendőnk, mint befejezni a frissítést (ennek pontos részleteit lásd a /usr/src/UPDATING állományban).

• Nem a /boot/loader, hanem közvetlenül a boot2 (lásd boot(8)) segítségével töltjük be a rendszermagot. Noha alapvetően semmilyen problémát nem nem okoz a /boot/loader kihagyása, általánosságban véve azért mégis jobban elérhetővé tudja tenni a rendszermagban található szimbólumokat a felhasználói programok felé.

A tünet: nagyon sok idő telik aközött, amíg a TCP kapcsolat felépül és a kliens bekéri a jelszót (vagy a telnet(1) esetében amíg a bejelentkező képernyő megjelenik).

A betegség: nagyon valószínű, hogy a késlekedést az okozza, amikor a szerver megpróbálja a kliens IP-címét feloldani hálózati névvé. Sok szerver, köztük a FreeBSD-ben is megtalálható Telnet és SSH szerver is ezt csinálja, többek közt azért, hogy a rendszergazda számára el tudja tárolni egy naplóban ezt a hálózati nevet.

Az orvosság: ha az említett jelenség minden olyan esetben jelentkezik, amikor a számítógépről (mint kliensről) valamilyen szerverhez csatlakozni akarunk, akkor a kliens oldalán lesz a gond. Ehhez hasonlóan, ha csak egy adott szervernél tapasztaljuk, akkor azzal a számítógéppel történhetett valami.

Amennyiben a problémákat a kliens okozza, nem tehetünk mást, a névoldáson kell úgy javítanunk, hogy a szerver normálisan fel tudja oldani. Ha helyi hálózaton tapasztaljuk mindezt, akkor ez már a szerver problémája és olvassunk tovább. Ellenkező esetben az internet a felelős, ezért nagyon valószínű, hogy fel kell vennünk a kapcsolatot az internet-szolgáltatónkkal és segítséget kérni tőlük a hiba elhárításában.

Ha a problémát viszont a helyi hálózaton található szerver okozza, akkor úgy kell azt beállítanunk, hogy a helyi neveket képes legyen rendesen feloldani. Ezzel kapcsolatban a hosts(5) és named(8) man oldalakat érdemes elolvasnunk. Ha a probléma viszont az interneten jelenik meg, akkor valószínű, hogy a szerver névfeloldása nem üzemel rendesen. Nézzünk meg egy másik gépet — például a www.yahoo.com címet. Ha ez sem működik, akkor nálunk van a gond.

A FreeBSD friss telepítését követően az is elképzelhető, hogy egyszerűen csak hiányoznak a tartományokkal és névszerverekkel kapcsolatos megfelelő adatok az /etc/resolv.conf állományból. Ez gyakran okoz késlekedést az SSH működésében, mivel az /etc/ssh könyvtárban található sshd_config állományban alapértelmezés szerint a UseDNS beállítás értéke yes (tehát a névfeloldás használata engedélyezett). Ha valóban ez okozza a problémát, akkor a pótoljuk az /etc/resolv.conf állományból hiányzó adatokat vagy az sshd_config állományban a UseDNS értéke ideiglenesen legyen no.

A kóbor megszakítási kéréseket jelző üzenetek általában a hardveres megszakítási kérések egyenletlenségeire utalnak, ezen belül is leginkább olyan esetekre, amikor az eszköz egy megszakítási kérés nyugtázása közepén eltávolítja az adott kérést.

Három dolgot tehetünk ezzel kapcsolatban:

• Elviseljük ezeket a figyelmeztetéseket. Megszakítási kérésenként az első öt üzenet után amúgy sem jelez többet a rendszer.

• Ha platformunkhoz (mint például i386) tartozó intr_machdep.c állományban található MAX_STRAY_LOG értékét átírjuk 5-ről 0-ra és így újrafordítjuk a rendszermagot, akkor ezzel teljesen letilthatjuk a figyelmeztetéseket.

• Megszüntetjük az üzeneteket úgy, hogy csatlakoztatunk a rendszerhez egy olyan párhuzamos vonali eszközt, amely a 7-es IRQ-t használja, és rakunk fel hozzá egy PPP meghajtót (a legtöbb helyen egyébként ezzel lesz a gond), valamint a 15-ös IRQ-ra pedig rakunk egy IDE-meghajtót vagy más hasonló eszközt és telepítjük hozzá a megfelelő meghajtót.

Ha ilyen hibaüzenetet látunk, akkor az arra utal, hogy kifogytunk a rendszerünkben egyszerre használható állományleírókból. A probléma leírásával és megoldásával kapcsolatban olvassuk el a kézikönyvben a kern.maxfiles változóról szóló részt A rendszermag korlátainak finomhangolása című szakaszban.

Ismert egy olyan probléma, hogy a BIOS-ban engedélyezzük az Intel® Enhanced SpeedStep technológiáját, akkor a rendszermag ehhez hasonló “calcru” üzeneteket kezd el küldözgetni:

calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue)
calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)

Ennek oka, hogy az Intel SpeedStep (EIST) egyes alaplapokkal nem kompatibilis.

Megoldás: Tiltsuk le a BIOS-ban az EIST használatát. Ekkor még az ACPI-alapú processzorfrekvencia-szabályozás továbbra is elérhető a powerd(8) használatán keresztül.

A számítógépnek kettő vagy több időmérő eszköze van, és a FreeBSD pont a rosszabbikat választotta.

Adjuk ki a dmesg(8) parancsot és vizsgáljuk meg a Timecounter kezdetű sorokat. Ezek közül a FreeBSD a legnagyobb “quality” értékkel rendelkezőt választotta.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Erről a kern.timecounter.hardware sysctl(3) változó lekérdezésével tudunk ténylegesen megbizonyosodni:

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Előfordulhat, hogy az ACPI-időzítő hibás. Ilyenkor az a legegyszerűbb, ha az /etc/loader.conf állományban letiltjuk az ACPI-időzítő használatát:

debug.acpi.disabled="timer"

Vagy a BIOS is tudja módosítani a TSC időzítőt — például azért, hogy csökkentse a processzor sebességét, amikor merül az akkumulátor vagy energiatakarékos módra vált. A FreeBSD sajnos nem figyel ezekre a változtatásokra és elcsúszik az időméréssel.

Ahogy viszont az iménti példában is látható, itt még az i8254 időzítő is használható, méghozzá úgy, hogy a kern.timecounter.hardware sysctl(8) változó értékét átállítjuk erre az értékre:

# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Innentől kezdve a számítógépünk már sokkal pontosabban mutatja az időt.

Ezt a változtatást úgy tudjuk minden rendszerindítás során automatikusan megtenni, ha felvesszük a következő sort az /etc/sysctl.conf állományba:

kern.timecounter.hardware=i8254

Ez a probléma gyakran megjelenik olyan laptopokon, amelyek egynél több operációs rendszert is futtatnak, egyes nem-BSD típusú rendszerek ugyanis hajlamosak a hardvert inkonzisztens állapotban hagyni. Emiatt a pccardd(8) parancs az adott kártyát “"(null)""(null)"” néven észleli a valós típusa helyett.

A hardvert innen teljesen csak úgy tudjuk alapállapotába hozni, ha a PC-kártya foglalatát áramtalanítjuk. Ehhez ki kell kapcsolnunk a laptopot. (Tehát ne tegyük se készenléti, se pedig hibernált állapotba — teljesen ki kell kapcsolni.) A PC-kártya ezután várhatóan már működni fog.

Némely laptopok hazudnak arról, hogy rendesen ki vannak-e kapcsolva. Amennyiben az előbbi módszer nem válna be, próbáljuk meg úgy, hogy kikapcsoljuk a gépet, kivesszük az akkumulátort, várunk egy keveset, visszarakjuk és újra bekapcsoljuk.

A FreeBSD rendszertöltője rosszul ismerte fel a merevlemez geometriáját. Ezt a FreeBSD slice-ok létrehozásakor és módosításakor külön meg kell adni az fdisk(8) használatakor.

A meghajtóhoz tartozó megfelelő geometriai beállítások a számítógép BIOS-ában találhatóak. Keressük meg az adott meghajtó cilinder-fej-szektor (Cylinder/Head/Sector) értékét.

A sysinstall(8) partíciószerkesztőjében a G billentyű lenyomásával tudjuk beállítani ezt.

Ekkor egy párbeszédablak jelenik meg, ahol meg tudjuk adni a cilinderek, fejek és a sávonkénti szektorok számát. Ide perjelekkel elválasztva gépeljük e a BIOS-ban talált értékeket. Például ha a merevlemez geometriája 5000 cilinder, 250 fej és sávonként 60 szektor, akkor a 5000/250/60 értéket kell megadnunk.

Az Enter billentyű lenyomására ezek az értékek beállítódnak, és a W lenyomására pedig az új partíciós tábla kiíródik a lemezre.

Indítsuk el a sysinstall(8) programot, majd válasszuk a Configure és Fdisk menüpontokat. A partíciószerkesztőben a Space billentyűvel tudjuk kiválasztani azt a partíciót, amelyen korábban a boot manager volt. Ezután az W billentyű lenyomásával tudjuk a változtatásainkat lemezre menteni. Ekkor egy menü jelenik meg, ahol a telepíteni kívánt rendszertöltőt választhatjuk ki. Adjuk meg és ekkor visszakerül a helyére.

Ez arra utal, hogy egy futó program megpróbált kiírni egy lapot a memóriából a lemezre, azonban 20 másodperce már nem tudott hozzáférni a lemezhez. Ezt okozhatják hibás szektorok a lemezen, a lemez hibás kábelezése vagy esetleg valamilyen lemezműveletekkel kapcsolatos hardver meghibásodása. Amennyiben maga a meghajtó a rossz, akkor az ilyen hibaüzenetek mellett még más, a lemez hibás működésére utaló üzenetet is látnunk kell a /var/log/messages állományban vagy a dmesg kimenetében. Minden más esetben érdemes a meghajtó csatlakozásait és kábelezését ellenőrizni.

A ata(4) meghajtó jelenti ezeket a “UDMA ICRC” hibákat olyan esetekben, amikor a merevlemezre vagy a merevlemezről érkező DMA átvitel hibás. A meghajtó ilyenkor még párszor megpróbálja megismételni a műveletet. Amennyiben ezek a műveletek is meghiúsulnak, a DMA átvitel helyett a lassabb PIO átviteli módra állítja át a merevlemez felé irányuló kommunikációt.

Ezt a problémát több tényező is okozhatja, habár ennek a leggyakoribb oka a hibás vagy rossz kábelezés. Ilyenkor mindig ellenőrizzük, hogy a merevlemezhez csatlakozó ATA-kábelek sértetlenek és a használni kívánt Ultra DMA átviteli módra alkalmasak. Ha cserélhető lemezes meghajtót használunk, akkor kompatibilisnek is kell lenniük. Ez a gond akkor jelentkezhet, amikor ugyanarra az ATA-csatornára egy Ultra DMA 66-os (vagy annál is gyorsabb) és egy régebbi meghajtót csatlakoztatunk. Végezetül ezek a hibaüzenetek arra is utalhatnak, hogy a meghajtó meghibásodott. A legtöbb gyártó külön szoftver ajánl fel ennek vizsgálatára, ezért ilyenkor érdemes letesztelnünk az érintett meghajtót, illetve amennyiben szükséges, biztonsági másolatot készíteni az adatainkról és kicserélni az eszközt.

Az atacontrol(8) segédprogram használatával ellenőrizni tudjuk, hogy jelenleg az egyes ATA-eszközök milyen DMA vagy PIO módban működnek. Erre a célra különösen az atacontrol mode csatorna parancsot javasoljuk, amivel képesek vagyünk megnézni az adott ATA-csatornára csatlakozó eszközök átviteli módjait. Itt a csatorna értéke nullától indul.

Erre a kérdésre a választ a FreeBSD-s szakkifejezések gyűjteményében találjuk meg a LOR címszó alatt.

Ez az üzenet arra utalhat, hogy egy függvény lepihent miközben nála volt egy mutex (vagy más, nem pihentethető) típusú zárolás.

Azért keletkezik ilyen hiba, mert a mutexeket nem úgy tervezték, hogy hosszabb ideig is meg lehessen tartani, kizárólag csak rövid időtartamra vonatkozó szinkronizációt lehet velük végezni. Ez a programozói megegyezés lehetővé teszi az eszközmeghajtók számára, hogy a megszakítások közben mutexek segítségével képesek legyenek szinkronizálni a rendszermag többi részével. A megszakítások (FreeBSD alatt) pedig nem pihenhetnek. Ezért a rendszermagon belül semmilyen olyan alrendszer nem blokkolódhat huzamosabb ideig, amelyik mutexet tart magánál.

Ezeket a hibákat úgy tudjuk elcsípni, ha olyan ellenőrzéseket teszünk a rendszermagba, amelyek jeleznek a witness(4) alrendszernek, hogy küldjön figyelmeztetést vagy akár végzetes hibát (a rendszer konfigurációjától függően) azokban a helyzetekben, amikor egy sejthetően hosszabb ideig blokkolt hívás tart magánál egy mutexet.

Röviden úgy foglalhatnánk össze, hogy ezek a hibák alapvetően nem végzetesek, de egy kis balszerencsével az egyszerű kis megakadásoktól kezdve a teljes lefagyásig szinte bármilyen hibáért felelősek lehetnek.

Ez a hibaüzenet nem azt jelenti, hogy a touch(1) segédprogram nem található, hanem inkább azt, hogy az érintett állományok dátuma a jövőre állítódott be. Ha a CMOS óránkat a helyi idő szerint állítottuk be, akkor egyfelhasználós módban indítsuk újra a rendszert és a adjkerntz -i parancs kiadásával állítsuk be a rendszermag óráját.