5. fejezet - Hibaelhárítás

5.1. Miért állapítja meg rosszul a FreeBSD a memória mennyiségét i386™ hardveren?
5.2. Mit tegyünk, ha meghibásodott szektorokat találunk a merevlemezünkön?
5.3. A FreeBSD miért nem találja meg a HP Netserver SCSI-vezérlőjét?
5.4. Állandóan ed1: timeout és ahhoz hasonló üzenetek jelennek meg. Mi lehet velük kezdeni?
5.5. Miért állnak le a 3Com® 3C509 kártyák minden különösebb ok nélkül?
5.6. A párhuzamos nyomtató nevetségesen lassú. Mi lehet ezzel kezdeni?
5.7. A programok miért állnak le időnként Signal 11 hibákkal?
5.8. A rendszer összeomlik vagy egy Fatal trap 12: page fault in kernel mode vagy pedig valamilyen panic: hibaüzenettel és egy halom számot ír ki. Mit tegyünk?
5.9. A rendszer indulása közben miért sötétül a képernyő és megy el rajta a kép?
5.10. A FreeBSD miért csak 64 MB memóriát használ, amikor 128 MB van a gépben?
5.11. A számítógépben több mint 1 GB memória van, de mégis kmem_map too small üzenetek jelennek meg. Mi a gond?
5.12. A számítógépben nincs 1 GB memória, a FreeBSD mégis kmem_map too small hibával leáll!
5.13. Miért jelenik meg a kernel: proc: table is full hibaüzenet?
5.14. Az új rendszermag indításakor miért keletkezik CMAP busy hibaüzenet?
5.15. Mit jelent az ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 üzenet?
5.16. Amikor elindul a rendszer, egy ahc0: illegal cable configuration hibaüzenet jelenik meg. A kábelek bekötésével semmilyen gond nincs. Mégis akkor mi a baj?
5.17. Miért küld a sendmail mail loops back to myself hibaüzenetet?
5.18. A távoli gépeken miért viselkednek olyan furcsán a teljes képernyős alkalmazások?
5.19. A Plug and Play kártyákat miért nem találja meg (vagy unknown típusúként látja) a FreeBSD?
5.20. Miért keletkezik nlist failed hiba például a top vagy systat parancsok futtatásakor?
5.21. Miért tart olyan sokáig ssh vagy telnet használatával csatlakozni a számítógéphez?
5.22. Mire utal a stray IRQ (kóbor megszakítási kérés) üzenet?
5.23. Miért jelenik meg folyamatosan a file: table is full üzenet a rendszernaplóban?
5.24. Miért árasztják el calcru: negative runtime vagy calcru: runtime went backwards üzenetek a konzolt?
5.25. Miért jár rosszul az óra a számítógépen?
5.26. A rendszer laptopon miért nem tudja rendesen megtalálni a PC-kártyákat?
5.27. Miért ad a FreeBSD rendszertöltője Read error hibát és áll meg a BIOS képernyőn?
5.28. Egy másik operációs rendszer letörölte a boot managert. Hogyan lehet visszaállítani?
5.29. Mit jelent a swap_pager: indefinite wait buffer: hibaüzenet?
5.30. Mik azok a UDMA ICRC hibák és hogyan lehet ellenük tenni valamit?
5.31. Mi az a lock order reversal?
5.32. Mit jelent a Called ... with the following non-sleepable locks held üzenet?
5.33. A buildworld/installworld miért áll le touch: not found hibával?

5.1.

Miért állapítja meg rosszul a FreeBSD a memória mennyiségét i386™ hardveren?

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.

5.2.

Mit tegyünk, ha meghibásodott szektorokat találunk a merevlemezünkön?

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.

5.3.

A FreeBSD miért nem találja meg a HP Netserver SCSI-vezérlőjét?

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.

Megjegyzés:

A HP Netserver esetén nem tudunk a lemezeken Veszélyesen dedikált (Dangerously Dedicated) módot használni. Erről itt olvashatunk bővebben.

5.4.

Állandóan ed1: timeout és ahhoz hasonló üzenetek jelennek meg. Mi lehet velük kezdeni?

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.

5.5.

Miért állnak le a 3Com® 3C509 kártyák minden különösebb ok nélkül?

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.

5.6.

A párhuzamos nyomtató nevetségesen lassú. Mi lehet ezzel kezdeni?

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.

5.7.

A programok miért állnak le időnként Signal 11 hibákkal?

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

5.8.

A rendszer összeomlik vagy egy Fatal trap 12: page fault in kernel mode vagy pedig valamilyen panic: hibaüzenettel és egy halom számot ír ki. Mit tegyünk?

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.

5.9.

A rendszer indulása közben miért sötétül a képernyő és megy el rajta a kép?

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.

5.10.

A FreeBSD miért csak 64 MB memóriát használ, amikor 128 MB van a gépben?

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.

5.11.

A számítógépben több mint 1 GB memória van, de mégis kmem_map too small üzenetek jelennek meg. Mi a gond?

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.

5.12.

A számítógépben nincs 1 GB memória, a FreeBSD mégis kmem_map too small hibával leáll!

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.

5.13.

Miért jelenik meg a kernel: proc: table is full hibaüzenet?

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.

5.14.

Az új rendszermag indításakor miért keletkezik CMAP busy hibaüzenet?

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

5.15.

Mit jelent az ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 üzenet?

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.

5.16.

Amikor elindul a rendszer, egy ahc0: illegal cable configuration hibaüzenet jelenik meg. A kábelek bekötésével semmilyen gond nincs. Mégis akkor mi a baj?

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.

5.17.

Miért küld a sendmail mail loops back to myself hibaüzenetet?

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

5.18.

A távoli gépeken miért viselkednek olyan furcsán a teljes képernyős alkalmazások?

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.

5.19.

A Plug and Play kártyákat miért nem találja meg (vagy unknown típusúként látja) a FreeBSD?

Ennek az okait a következő levélben fejtette ki Peter Wemm 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).

Megjegyzés:

Az eredeti szövegből készült idézetet frissítettük.

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.

5.20.

Miért keletkezik nlist failed hiba például a top vagy systat parancsok futtatásakor?

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

5.21.

Miért tart olyan sokáig ssh vagy telnet használatával csatlakozni a számítógéphez?

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.

5.22.

Mire utal a stray IRQ (kóbor megszakítási kérés) üzenet?

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.

5.23.

Miért jelenik meg folyamatosan a file: table is full üzenet a rendszernaplóban?

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.

5.24.

Miért árasztják el calcru: negative runtime vagy calcru: runtime went backwards üzenetek a konzolt?

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.

5.25.

Miért jár rosszul az óra a számítógépen?

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

5.26.

A rendszer laptopon miért nem tudja rendesen megtalálni a PC-kártyákat?

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.

5.27.

Miért ad a FreeBSD rendszertöltője Read error hibát és áll meg a BIOS képernyőn?

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.

5.28.

Egy másik operációs rendszer letörölte a boot managert. Hogyan lehet visszaállítani?

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.

5.29.

Mit jelent a swap_pager: indefinite wait buffer: hibaüzenet?

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.

5.30.

Mik azok a UDMA ICRC hibák és hogyan lehet ellenük tenni valamit?

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.

5.31.

Mi az a lock order reversal?

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.

5.32.

Mit jelent a Called ... with the following non-sleepable locks held üzenet?

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.

5.33.

A buildworld/installworld miért áll le touch: not found hibával?

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.

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.

Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.