Következő: 13.4.4.0.10 Kérdés Fel: 13.4.4 Sig11 FAQ Előző: 13.4.4.0.8 Kérdés   Index

13.4.4.0.9 Válasz

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

Memória

A memóriában véletlenszerűen elromolhat egy bit. Ha ez a memória írásakor történik, nem lehet semmi paritáshibát látni. Többféleképp lehet a javítással próbálkozni:

• A memória sebessége túl alacsony. Növelni kell a ,,wait states'' számát a BIOS-ban. Ez lehet az AMIBIOS automatikus konfigurálásának hibája, esetleg azt hiszi, hogy a 486-os gépek mindössze 80 MHz-vel mehetnek, miközben vannak ennél gyorsabb CPU-k is. (Pat V.)
• A memória sebessége túl alacsony. Gyorsabb DRAM SIMM modulokat kell vásárolni. Pl. egyes ASUS alaplapok 60 ns-os DRAM-ot kívánnak amennyiben 100 vagy 133 MHz-es processzorod van (az alaplap leírásában benne kell lennie). Hallottam, hogy esetleg a 70 ns-os is működik, de nem teljesen megbízhatóan (véletlen sig11-ek feltűnnek, én nem vállalnám a kockázatot) (Andrew Eskilsson mpt95aes@pt.hk-r.se)
• Az egyik memóriachip hibás. Ha több ,,bank''-ban vannak a memóriamodulok, akkor némelyiket ki lehet venni ideiglenesen, és megnézni, a hiba megszűnik-e. Vigyázz, hogy statikus elektromossággal ne legyél feltöltődve!
• egy igen nehéz eset például: sikerült kideríteni, hogy mind a négy 16MB SIMM rossz volt, egy bitet veszítettek majdnem minden órában. Ez elég volt, hogy naponta egyszer lefagyasszák a számítógépet, vagy félbeszakítsák a kernel fordítást egy órán belül. Az új SIMM készlet kitűnően működik. Igen sok időbe került kideríteni a hibát, mivel mind a négy SIMM modul egyformán hibás volt, így a memória felének kihagyása nem jelentett megoldást. Mark Kettner (kettner@cat.et.tudelft.nl) írta, hogy a számítógépe képes volt 2300-szor lefuttatni a memóriatesztem hiba nélkül, ezek után viszont kb. tíz hibát kapott. Aztán újból hiba nélkül ment a memóriateszt néhányezerszer. Ilyen esetekben a kernelfordítás sokkal hatékonyabb útja a számítógép ellenőrzésének. A megoldás az volt, hogy ,,becserélte'' a memóriákat a boltban ,,upgrade'' keretében. A boltos ezek után maga ellenőrizte a memóriát, hibátlannak találta, és beszámította az árukat az újonnan vásároltak árába.
• Úgy néz ki, néhány 30 -> 72 pin konvertáló tok is okozhat hibát (nem sikerült teljesen bebizonyítani, hogy a tok volt a hibás, de néhány olyan memória, mely előtte évekig hibátlanul működött, az új tokban hibázott - Naresh Sharma n.sharma@is.twi.tudelft.nl). Paul Gormaker (paul.gortmaker@anu.edu.au) még megírta, hogy ezeknek a tokoknak legalább 4 mellék-kondenzátorának (bypass capacitor) kell lenniük, hogy tartani tudják a feszültséget a SIMM-ek számára.
• Ha a DRAM frissítése nem jó, akkor lassan elveszítik a tartalmukat. Némely (486) alaplap nem frissít helyesen, ha a ,,hidden refresh'' módban üzemeltetjük. Létezik egy ,,dram'' nevű program, mely összezavarja a frissítést, és sig11-et tud okozni (Hank Barta hank@pswin.chi.il.us és Ron Tapia tapia@nmia.com).
• A ,,waitstate'' száma alacsony lehet. Növelni kell a BIOS-ban a számukat. Az Intel Endeavour lap nem engedi, hogy ezt növeljük. Ez feltehetően megoldható MR BIOS bemásolásával (David Halls).

Cache memória

A cache memóriában szintén előfordulhat bitfordulás. Ezek az áramkörök legtöbbször nincsenek paritás-ellenőrzéssel ellátva. A BIOS-ban viszont ki lehet kapcsolni használatukat, és lehet ellenőrizni, hogy ha a probléma megszűnik, akkor a cache volt a hibás. A következőképp lehet javítani ezt:

• A cache sebessége túl alacsony. A ,,wait states'' számát kell növelni a BIOS-ban.
• Esetleg lehet gyorsabb SRAM chipeket vásárolni.
• Ha az egyik chip rossz, ki kell cserélni. Azonban ez valószínűleg sokkal bonyolultabb, mint a SIMM cseréje. Nagyon kell vigyázni az elektrosztatikusságra (Joseph Barone barone@mntr02.psf.ge.com)!
• A ,,write back''-re állított cache nem működik, ha a ,,write back'' kódolásában hiba van. Ez az MV020 486VL3H alaplapoknál történt (20MB RAM-mal, Scott Brumbaugh scottb@borris.beachnet.com)
• The motherboard may require a jumper to switch between Cache On A Stick and the old-fashioned dip chip cache. (JP16 on Rev 2.4 ASUS motherboards)
• Lemezátvitel. A lemezről jövő adat átvitele közben is előfordulhat bit error. Ha ez a problémád, akkor a dd parancsot kell használnod, hogy az egyik helyről a másikra ,,mozgasd'' a hibát.
• egyes IDE merevlemezek nem ismerik az ,,irq_unmasking'' módot. Ez azonban csak terheléskor jön elő. És bizony előjöhet sig11 képében.
• esetleg egy ,,kalok 31XX'' nevű jószágod van? Dobd ki a szemétbe (vagy add el egy DOS-szerelmesnek).
• SCSI? Véglezárása? Egy rövid busz még működhet - persze megbízhatatlanul - rossz lezáróval. Hosszabb busz mindenképp hibát jelez. Be tudod kapcsolni a paritás-ellenőrzést a gépen ÉS a lemezen?

Túlhajtás

Egyes cégek (és emberek) úgy gondolják, hogy a CPU-kat túl lehet hajtani (overlock). Ez egyszer igaz, máskor nem. Esetleg ki kell kapcsolni a ,,turbo'' állást (manapság legtöbb Pentiumban már nincs ,,nem-turbo'' lehetőség), ellenőrizni, hogy a hiba megszűnik-e. Ellenőrizd, hogy a CPU sebessége (rá van nyomtatva, esetleg óvatosan le kell a hűtőt venni) megegyezik-e az alaplapon ill. a BIOS-ban beállítottal. Még az Intel is csinál hibát ezen a téren. Van feljegyzés róla, hogy egy hivatalos 120MHz Pentium sig11-et ad 120MHz-en, de nem 100 MHz esetén. Mivelhogy az alaplap többet dolgozik 100 MHZ esetén, nem hinném, hogy ez alaplaphiba lenne. Továbbá egy újabb 120MHz CPU probléma nélkül fut (Samuel Ramac sramac@vnet.ibm.com)

CPU hőmérséklet

Egy gyors CPU túlmelegedhet megfelelő hűtés nélkül. Ez lehet egy rossz hűtő miatt is. A CPU ilyenkor megbolondulhat, ha a kernel-fordítás miatt nyúzás alá kerül. A helyzet még rosszabb, ha a LILO parancssorában a ,,HALT'' kapcsolót kikapcsolod. A Linux megpróbálja ezzel a paranccsal lekapcsolni a CPU-t, ha sokáig nem csinál semmit. Ez áramot takarít meg, és a CPU hőmérséklete leesik ekkor. Azaz nem találkozol a sig11 hibával, amikor pl. csak valamilyen dokumentumot javítasz, és csak akkor jön ki, amikor már hosszú ideje sok CPU-t igénylő programot futtatsz, és a processzor teljes környezete már átmelegedett. Ha egy Fdiv-hibás Pentiumod van, akkor ajánlatos az Intelnél becserélni. Egy vadiúj CPU-t küldenek egy felszerelt, az Intel által is elfogadott hűtőventillátorral együtt. Továbbá tudni kell, hogy a legtöbb szokásos ragasztó igen rossz hővezető. Van speciális hővezető ragasztó, amit lehetőleg használjunk a hűtőventillátorok feltételekor (Arno Griffioen arno@ixe.net, W. Paul Mills wpmills@midusa.net, Alan Wind wind@imada.ou.dk) A megengedhető külső CPU-hőmérsékletek az Intel szerint:

• 0 - 85 C : 486SX, 486DX, IntelDX2, DX4
• 0 - 95 C: IntelDX2, IntelDX4, Overdrive
• 0 - 80 C: 60MHz Pentium
• 0 - 70 C: 66 -tól 166 Pentium

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

CPU feszültség

Némely alaplap megengedi, hogy a CPU feszültségét beállítsuk. És némely alaplapnak rossz a leírása, hogy hogyan állítsuk be a jumpereket ehhez. Egy 5V-os processzor jó ideig elmegy 3.3 V-on is (Karl Heyes krheyes@comp.brad.ac.uk).

RAM feszültség

A legtöbb memória még mindig 5V-on működik, de már elterjedtek a 3.3V-os memóriák is. Vigyázni kell, mert a 3.3V-os tönkre is megy 5V-on.

Local bus túlhajtás

25MHz-en három Vesa local bus megy el, 33MHz-en csak kettő, 40MHz-en mindössze egy, és találd ki, mennyi tud működni 50MHz-es frekvencián? Egy sem. Némely rendszer kiszámíthatatlan lesz, ha a VLB túl van hajtva. Még ha a VLB nincs is túlhajtva (a fenti mértékek szerint), néhány nanomásodperc elveszhet egy új VLB kártya hozzáadásakor. Azaz érdemes esetleg a ,,cache wait state'' -et növelni ekkor (Richard Postgate postgate@cafe.net).

Power management (APM)

Bizonyos laptopok (és ,,green'' PC-k) rendelkeznek ezzel a lehetőséggel. Ez közbejátszhat a Linux működésében. Egyik eshetőség, hogyha sokáig nem nyúlunk a géphez, az APM a memória tartalmát kimenti a merevlemezre, és csak akkor tölti vissza a RAM-ba, amikor hozzáérünk a billentyűzethez. Ez jó ötletnek tűnik, csakhogy a Linux eszközmeghajtók nem szoktak hozzá, hogy két elérés közben kikapcsolódik az eszköz. Egyesek túlélik, mások nem. Érdemes kikapcsolni a BIOS-ban, vagy megengedni az ,,APM support'' lehetőséget a kernelben (Elisabeth Ayer eca23@cam.ac.uk).

Maga a CPU

Néhanyan azt találták, hogy semmi mást nem lehet okolni a hibáért, csakis a CPU-t. Ez lehet pl. egy összeférhetetlenség a CPU és az alaplap között. Volt már egy ilyen hullám (1997. februárjában) és egy másik manapság, amely a Cyrix/IBM 6x86 CPU-kat okolta. Bár a hiba oka lehet valóban a CPU, lehet, hogy mindössze az alaplap összeférhetetlen a CPU-val. Már láttam olyan alaplapleírást, ami állította, hogy nem kompatibilis a 6x86 sorozat első tagjaival. Saját tapasztalatom, hogy ezek az eszközök nem rosszak összességében, kernel fordítással ellenőrizve a P166+ egyenlő a P155-el (1.3-szor gyorsabb, mint a P120).

Memory hole

Sok modern alaplap megengedi, hogy a régi ISA videokártyádat egy vagy két megabájt lineáris keret pufferrel (linear frame buffer) használd. Ehhez ezt a memóriát a 16MB alá kell helyezni. Szinte senki nem használja ezt a lehetőséget, de ha bekapcsolod a ,,memory hole'' (vagy más BIOS-okban ,,LFB support'') kapcsolót, akkor a harvered furcsán fog viselkedni (Paul Connolly pconnolly@macdux.com.au).

Következő: 13.4.4.0.10 Kérdés Fel: 13.4.4 Sig11 FAQ Előző: 13.4.4.0.8 Kérdés   Index