5.1. | Miért állapítja meg rosszul a FreeBSD a memória mennyiségét i386TM 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 (
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 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 | |
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 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(R) 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
| |
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:
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
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:
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(R) 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 A hibát kijavításáig így kerülhetjük meg:
Ha a soros portokat is használni akarjuk, akkor
következő módosításokkal
készítsünk egy új rendszermagot: a
| |
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= ahol | |
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 | |
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
A 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
A sysctl változók
beállításait úgy is tudjuk
véglegesíteni, ha felvesszük ezeket az
| |
5.14. | Az új rendszermag indításakor miért keletkezik CMAP busy hibaüzenet? |
Az elavult Amikor ilyen történik, indítsuk újra a rendszert egyfelhasználós módban és gépeljük be:
| |
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ó
| |
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
Ezt a problémát többféle módon is meg tudjuk kerülni:
| |
5.19. | A Plug and Play kártyákat miért nem
találja meg (vagy |
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. Megjegyzés:Az eredeti szövegből készült idézetet frissítettü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:
[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 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
Ebből a Ezt az információt (a Ehhez először is készítsünk
egy biztonsági másolatát a
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
| |
5.20. | Miért keletkezik nlist
failed hiba például a
|
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:
| |
5.21. | Miért tart olyan sokáig
|
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
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
| |
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:
| |
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(R) 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(R) 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
Erről a
Előfordulhat, hogy az ACPI-időzítő
hibás. Ilyenkor az a legegyszerűbb, ha az
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
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
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 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 és 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
| |
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 | |
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
|
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
|
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>.