Signal 11 při kompilaci jádra

Original page: https://bitwizard.nl/sig11/

Tento FAQ popisuje možné příčiny efektu, který v poslední době trápí spoustu lidí. Konkrétně to, že kompilace linux(*)-kernel (nebo jakýkoli jiný velký balík na to přijde) se zhroutí se “signálem 11”. Příčinou může být software nebo (s největší pravděpodobností) hardware. Čtěte dále a dozvíte se více.
(*) Samozřejmě nic není specifické pro Linux. Pokud je váš hardware nefunkční, Linux, Windows 3.1, FreeBSD, Windows NT a NextStep se zhroutí.


Sig11 FAQ

OTÁZKA

Signál 11, co to znamená?

ODPOVĚDĚT

Signál 11, nebo oficiálně známý jako „chyba segmentace“, znamená, že program přistoupil na místo v paměti, které nebylo přiřazeno. To je obvykle chyba v programu. Pokud tedy píšete svůj vlastní program, je to nejpravděpodobnější příčina. Tento FAQ se však zaměří na další možnosti.

OTÁZKA

Moje (kernel) kompilace se zhroutí s

   gcc: Interní chyba kompilátoru: program cc1 dostal fatální signál 11

Co je špatně s kompilátorem? Jakou verzi kompilátoru potřebuji? Je něco v nepořádku s jádrem?

ODPOVĚDĚT

S největší pravděpodobností není nic špatného s vaší instalací, vaším kompilátorem nebo jádrem. Velmi pravděpodobně to má něco společného s vaším hardwarem. Existuje celá řada podsystémů, které mohou být chybné, a existuje řada způsobů, jak to opravit. Čtěte dál a dozvíte se více. Z tohoto „pravidla“ existují dvě výjimky. Může vám docházet virtuální paměť nebo můžete instalovat Red Hat 5.x, 6.x nebo 7.x. Ke konci je o tom více.


OTÁZKA

Dobře, nemusí to být softwarem. Jak to mám vědět jistě?

ODPOVĚDĚT

Nejprve se ujistěte, že je to hardware, který způsobuje vaše potíže. Když se „make“ zastaví, jednoduše zadejte „make“ znovu. Pokud před zastavením zkompiluje několik dalších souborů, musí to být hardware, který vám způsobuje potíže. Pokud se okamžitě znovu zastaví (tj. před bombardováním přesně na stejném místě prohledá několik adresářů s „nic nedělat pro xxxx“), zkuste

   dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS

Změňte HARD_DISK na „hda“ podle názvu vašeho pevného disku (např. hda nebo sda. Nebo použijte „df .“). Změňte MEGS na počet megabajtů hlavní paměti, kterou máte. To způsobí, že prvních několik megabajtů vašeho pevného disku bude načteno z disku, což vynutí opětovné načtení zdrojových souborů C a binárního souboru gcc z disku při příštím spuštění. Nyní zadejte znovu make. Pokud se stále zastaví na stejném místě, začínám se divit, zda čtete správné FAQ, protože to koneckonců začíná vypadat jako softwarový problém…. Podívejte se na otázku „jaké jsou další možnosti“…. Pokud se bez tohoto příkazu „dd“ kompilátor zastaví na stejném místě, ale po použití „dd“ se přesune na jiné místo, určitě máte disk -> problém s přenosem ram.

OTÁZKA

co to vlastně znamená? Jste si jistý, že jde o hardwarový problém?

ODPOVĚDĚT

Kompilátor přistupoval k paměti mimo její rozsah paměti. Pokud se to stane na funkčním hardwaru, je to chyba programování uvnitř kompilátoru. Proto to říká „interní chyba kompilátoru“. Když se však hardware občas trochu překlopí, gcc používá tolik ukazatelů, že pravděpodobně skončí přístupem k něčemu mimo jeho rozsah adres. (náhodné adresy jsou většinou mimo váš rozsah adresování, protože i když vaše hlavní paměť může být v dnešní době významnou částí 4G, obvykle jen malá část je mapována na jeden proces. 🙂 Zdá se, že v dnešní době má každý problémy se „signálem 11“ Pokud vyvíjíte svůj vlastní software nebo máte software, který nebyl dostatečně odladěn, „signál 11“ (nebo chyba segmentace) je stále velmi silným náznakem, že s programem není něco v pořádku. Pouze když program jako „gcc“, který funguje téměř pro všechny ostatní, spadne na datové sadě (např. linuxové jádro), která byla také dobře otestována, pak se stane náznakem, že s vaším hardwarem není něco v pořádku. Pokud je některá softwarová součást, jako je ovladač hardwaru, ve vašem systému poškozena, může to způsobit příznaky, které jsou VELMI blízké příznakům selhání hardwaru. Pokud je však ovladač vadný, je pravděpodobnější, že způsobí vážné problémy uvnitř jádra, než že způsobí jen pád kompilátoru. mohlo by to způsobit příznaky, které jsou VELMI blízké příznakům selhání hardwaru. Pokud je však ovladač vadný, je pravděpodobnější, že způsobí vážné problémy uvnitř jádra, než že způsobí jen pád kompilátoru. mohlo by to způsobit příznaky, které jsou VELMI blízké příznakům selhání hardwaru. Pokud je však ovladač vadný, je pravděpodobnější, že způsobí vážné problémy uvnitř jádra, než že způsobí jen pád kompilátoru.


OTÁZKA

OK. Mohu mít problém s hardwarem, co to je?

ODPOVĚDĚT

Pokud je to náhodou hardware, může to být:

  • Hlavní paměť. Vaše hlavní paměť se může občas trochu pokazit. Pokud k tomu dojde u „zápisů“, neuvidíte žádné chyby parity. Existuje několik způsobů, jak to opravit:
    • Rychlost paměti může být příliš nízká. Zvyšte počet stavů čekání v systému BIOS.
      To může být způsobeno možností autokonfigurace AMIBIOS: může vědět pouze o 486 běžících do 80 MHz, zatímco v současné době kupujete 100 MHz verze. — Pat V.
    • Rychlost paměti může být příliš nízká. Získejte rychlejší DRAM SIMM. Například současné základní desky ASUS vyžadují 60 ns DRAM, pokud máte 100 nebo 133 MHz procesor (Podívejte se do manuálu vaší základní desky). Slyšel jsem zprávy, že 70 ns také funguje, problémy se spolehlivostí jako náhodné sig11 patří k možnostem…. (Neriskoval bych) — Andrew Eskilsson (mpt95aes@pt.hk-r.se)
    • Možná si myslíte, že své 100MHz SDRAM můžete provozovat na 100MHz. Špatně! přečtěte si http://www.bitwizard.nl/sig11/sdram, proč si myslím, že tomu tak je. Potřebujete alespoň jeden rychlostní stupeň rychlejší, než je rychlost, pro kterou jsou určeny.
    • Na jedné z SIMM je špatný čip. Pokud vlastníte více než 1 paměťovou kartu, možná budete moci vytáhnout SIMM a zjistit, zda problém nezmizí. Pozor na STATIKA!!!
    • Minulý týden jsme tu řešili jeden těžký. Ukázalo se, že VŠECHNY 4 16Mb SIMM byly rozbité tak, že jednou za hodinu trochu klesly. To stačilo ke zhroucení počítače přibližně za den nebo ke zhroucení kompilace jádra přibližně za hodinu. Nová sada SIMM funguje perfektně. Diagnostikování tohoto trvalo dlouho, protože všechny 4 SIMM byly ovlivněny stejně, takže ponechání poloviny paměti na věci nic nezměnilo.
      Mark Kettner ( kettner@cat.et.tudelft.nl) hlásí, že jeho systém byl schopen provést můj test paměti 2300krát bezchybně, ale pak zjistil asi 10 chyb. Poté pokračovalo v detekci žádných chyb po několik stovek spuštění znovu…. V jeho případě bylo spuštění kompilace jádra mnohem účinnějším způsobem zjišťování stavu systému (v nejstabilnější konfiguraci mohl systém zkompilovat přibližně 14 jader, než se zbláznil ). Jeho řešením bylo „vyměnit“ starou paměť za takzvaný „upgrade paměti“. Obchodník pak „testuje“ ve svém testeru paměti, který paměť OK. Na novou paměť pak dostal pořádnou slevu :-).
    • Zdá se, že některé 30-72 pinové převodníky mohou způsobit chyby paměti. (Podívejte se, jak je tento záznam starý? Kdo si pamatuje 30pinové SIMM? Nicméně všechny tyto věci perfektně platí pro SIMM <-> DIMM převodníky, nebo socket370 <-> slot 1 převodníky) (Nebylo prokázáno, zda 4 SIMMS v převodníku se pokazil, nebo jestli byl na vině převodník SIMM. SIMMS fungovaly perfektně roky, než byly přesunuty do převodníku….) — Naresh Sharma (n.sharma@is.twi.tudelft.nl). Paul Gortmaker (paul.gortmaker@anu.edu.au) dodává, že převodníky SIMM by měly mít alespoň 4 bypass kondenzátory, aby bylo napájení SIMM čisté.
    • Pokud obnova DRAM nefunguje správně, DRAM pomalu ztrácejí své informace. Některé (486) základní desky se přestanou správně obnovovat, když zapnete „skryté obnovování“. Zdá se, že existuje program zvaný „dram“, který může také zkazit vaše obnovení a způsobit problémy se sig11. — Hank Barta (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
    • Počet stavů čekání může být příliš nízký. Zvyšte počet stavů čekání v systému BIOS na opravu. Deska Intel Endeavour neumožňuje zvýšit stavy čekání paměti. To lze údajně opravit flashováním MR BIOSu do základní desky. — David Halls (david.halls@cl.cam.ac.uk)
    • Některé paměťové moduly jednoduše nerady spolupracují s ostatními. Odděleně oba fungují, společně ne. Nejpravděpodobněji se to stane, když kombinujete různé značky a velikosti. Oficiálně, pokud se budete držet specifikací pro všechny moduly, vždy to funguje. Neoficiálně se občas dostanete do problémů.
  • Vyrovnávací paměť. Vaše mezipaměť se může občas trochu pokazit. Keše obvykle nejsou vybaveny paritou. Tento případ můžete diagnostikovat vypnutím mezipaměti v systému BIOS. Pokud problém zmizí, je to pravděpodobně mezipaměť. Existuje několik způsobů, jak to opravit:
    • Rychlost mezipaměti může být příliš nízká. Zvyšte počet stavů čekání v systému BIOS.
    • Rychlost mezipaměti může být příliš nízká. Získejte rychlejší čipy SRAM.
    • Ve vaší mezipaměti je špatný čip. Je nepravděpodobné, že byste mohli vyměnit čipy tak snadno jako u SIMM. Pozor na STATIKA!!! — Joseph Barone (barone@mntr02.psf.ge.com)
    • Mezipaměť může být nastavena na „zpětný zápis“, když je chyba v implementaci zpětného zápisu vaší čipové sady. Základní deska, kde se to stalo, byla „MV020 486VL3H“ (s 20M RAM) — Scott Brumbaugh (scottb@borris.beachnet.com) (e-mailová adresa nefunguje. Scott: Obraťte se na mě s platnou zpáteční adresou)
    • Základní deska může vyžadovat propojku pro přepínání mezi Cache On A Stick a staromódní dip chip cache. (JP16 na základních deskách ASUS P/I-P55TP4XE Rev 2.4)
  • Přenosy disků. Blok přicházející z disku může občas způsobit bitovou chybu.
    • Pokud máte tento problém, s největší pravděpodobností budete muset provést příkaz „dd“, abyste „přesunuli“ problém z jednoho místa na druhé….
    • Některé pevné disky IDE nezvládají volbu „irq_unmasking“. To se může zobrazit pouze při zatížení. A mohlo by se to ukázat jako sig11.
    • Některá nastavení nemohou v některých konfiguracích zpracovat DMA. Mario Moder hlásí, že jeho systém konečně začal fungovat správně poté, co povolil 32-bit-io pro jeho HD i CD mechaniku. — Mario Moder ( clay-man@freenet.de )
    • Máte kalok 31xx? Vyhoďte to do odpadu. (nebo ho prodejte uživateli DOSu. Aktualizace: O kaloku jsem léta neslyšela. Pravděpodobně jsou v háji. Disky mimochodem také nefungují s W95.)
    • SCSI? Ukončení? Krátká sběrnice může stále fungovat (to je nespolehlivé) se špatným zakončením. Dlouhý autobus může mít chyby tak jako tak. Můžete zapnout paritu na hostiteli a DISKU?
  • Samotný CPU. Některé šarže procesorů mají mnohem vyšší procento z nich, které jsou náhodou „špatné“. Před několika lety: původní Intel-Pentium-120. Před několika lety AMD K6/2-300 (1998, vyrobeno v týdnech 34 až 39!). A nedávno AMD K6/2-450. Někteří lidé se mohou rozhodnout, že řekněme, že 400 MHz je pro ně přijatelné, ale pokud se ukáže, že je to problém, máte nárok na nový procesor. Jdi a vyměň to tam, kde jsi to koupil. (Zapomeňte na ty P120, nestojí to za ty potíže… 😉 — Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr) & Mark Keegan (keegan@mx.qc.ca)
  • Samotný CPU. Některé šarže procesorů K6 mají prostě konstrukční chybu. Přečtěte si http://www.multimania.com/poulot/k6bug.html a poté se ujistěte, že vám K6 vymění. — Rongen (rongen@istar.ca).
  • Přetaktování. Procesory Cyrix P-166 běží na 133 MHz, ne na 166. To musí být logické pro chlapy z Cyrix, ale pro nikoho jiného. Přetaktujete je, pokud je spustíte na 166 MHz… (Poznámka: Některé z těchto často kladených otázek jsou dost staré. Nyní AMD začalo dělat to samé: XP1800 běží na 1533 MHz.)
  • Přetaktování. Někteří prodejci (nebo soukromé osoby) si myslí, že je možné přetaktovat některá CPU. Některé z nich mohou fungovat, jiné ne. Možná budete chtít zkusit vypnout turbo (všimněte si, že většina základních desek pentium již nepodporuje režim bez turbo) a uvidíte, zda problém nezmizí. Zkontrolujte rychlost svého procesoru v porovnání (vytištěno na něm, v případě potřeby opatrně vyjměte ventilátor) s tím, co říkají propojky základní desky nebo nastavení systému BIOS…. Zdá se, že i Intel může v této oblasti dělat chyby. Nyní mám několik spolehlivých zpráv, že oficiální pentium by sig11 při své jmenovité rychlosti, ale ne při nižší rychlosti. Pokud jde o některé rychlosti, základní deska je pouze VÍCE namáhána kvůli nižší rychlosti procesoru (120 MHz-> základní deska běží na 60MHz, 100MHz-> základní deska běží na 66MHz), myslím, že je nepravděpodobné, že by to mělo něco společného se základní deskou. Navíc nový 120MHz procesor nyní funguje správně. — Samuel Ramac (sramac@vnet.ibm.com). To není jedinečné pro Intel ani žádnou z jeho konkurentů.
  • Přetaktování. V současné době jsou rychlosti procesoru, ztrátový výkon atd. tak blízko „hrany“, že se spolehlivé korporace, jako je Intel, musí tu a tam uchýlit k trikům, které používají overclockeři ke zlepšení výkonu. Výsledky mohou být také srovnatelné: Náhodné zablokování, sig11 atd. atd.
  • teplota CPU. Bez správného chladiče se může vysokorychlostní procesor přehřát. To může být také způsobeno vadným ventilátorem. (Můj osobní ‘486 má ventilátor, kterému trvá pár minut, než se dostane do otáček. Pravděpodobně nikdy opravdu NEselže, protože je nyní vyřazen z provozu :-). CPU se může stát nevyzpytatelným, pokud je „tlačeno“ kompilací jádra. Tento problém se zhorší, pokud deaktivujete „HALT“ na příkazovém řádku LILO. Linux se pokouší vypnout CPU provedením instrukce „halt“, když je systém nečinný. To šetří energii, a proto teplota CPU klesá, když je systém nečinný. Při jednoduchých úpravách si proto tohoto problému nemusíte všimnout a může se objevit až po hodinách náročných úloh CPU, když je okolní teplota vysoká. Pokud máte Pentium s chybou Fdiv, je vhodné jej vyměnit u Intelu. Zašlou vám nový, který je předem nakonfigurovaný s oficiálním ventilátorem schváleným společností Intel. Všimněte si také, že většina běžných lepidel jsou velmi špatné tepelné vodiče. K dispozici je speciální tepelné lepidlo, které by se mělo použít, když je třeba přilepit ventilátor k CPU. — Arno Griffioen (arno@ixe.net), — W. Paul Mills (wpmills@midusa.net) — Alan Wind (wind@imada.ou.dk) Intel říká, že přípustné teplotní rozsahy pro vnější část vašeho CPU jsou:
    0 až +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 procesor
    0 až +95 C: IntelDX2, procesory IntelDX4 OverDrive®
    0 až +80 C: 60 MHz procesor Pentium®
    0 až +70 C: 66 až 166 MHz procesor Pentium
    Informace o jak to změřit a nějaké potvrzení toho, co zde říkám, viz: http://pentium.intel.com/procs/support/faqs/iarcfaq.htm (Zejména otázky Q5, Q6 a Q12. Dokument začíná být mírně zastaralý, ale stále je velmi přesný. Zdá se, že otázky se tu a tam také trochu pohybují.) (Intel nyní přesunul soubor. Nemohl jsem. nenajdu nové. Je tu někdo, kdo by mě mohl nasměrovat na nové umístění???)
  • napětí CPU. Některé základní desky umožňují zvolit napětí CPU. Některé základní desky špatně dokumentují nastavení jumperů, které to zvládají. Zdá se, že 5V procesor může stále pracovat většinu času při 3,3 voltu….. — Karl Heyes (krheyes@comp.brad.ac.uk)
  • napětí RAM. Zdá se, že prodejci se nyní připravují na 3,3V RAM. Většina paměti je nyní 3,3V. (ale buďte opatrní, pokud máte desku schopnou nastavit napětí RAM: 3,3 V RAM se zlomí při 5V…..) (Když jsem o tom málo slyšel, myslím, že přepínač musí být automatický.)
  • Přetížení místní sběrnice. Na 25 MHz můžete mít 3 karty VesaLocalBus (VLB), na 33MHz pouze dvě, na 40MHz pouze jednu a hádejte co na 50MHz ŽÁDNÁ! (tj. máte povoleno provozovat váš systém s 50MHz místní sběrnicí, ale pak nemůžete používat žádné VLB karty). Některé systémy se při přetížení VLB začnou chovat nepravidelně. I když vaše VLB není přetíženo (nad limity uvedené výše), může systém ztratit několik nanosekund rezervy přidáním další karty VLB, takže možná budete muset přidat stav čekání mezipaměti nebo něco jiného poté, co jste přidali nová VLB karta… — Richard Postgate (postgate@cafe.net)
  • Řízení spotřeby. Některé notebooky (a dnes i „zelené“ počítače) mají funkce správy napájení. Ty by mohly rušit Linux. Jedna funkce může uložit obraz paměti na HD a obnovit RAM, když stisknete klávesu. Zní to jako zábava, ale ovladače zařízení pro Linux neočekávají, že by byl hardware mezi dvěma přístupy vypnutý. Někteří se mohou uzdravit, ale jiní ne. Zkuste to vypnout nebo povolit „podporu APM“ v jádře. — Elizabeth Ayer (eca23@cam.ac.uk)
  • Hromadění prachu. Nějaký prach by mohl trochu vést a vytvořit slabý zkrat. Někde by to mohlo zvýšit kapacity a zhoršit charakteristiky časování. Mohlo by to bránit tepelnému toku a vést k přehřívání součástí. Mohlo by to dokonce zkratovat propojku! Doporučuji, že každý rok nebo tak nějak je dobré otevřít počítač a vysát vnitřek. Tip: Tyto věcičky navlečené na vatu pomáhají vyhnat prach z nepřístupných míst… — Craig Graham (c_graham@hinge.mistral.co.uk). Někdo jiný mi řekl: pokud můžete, použijte k vyfouknutí věcí místo vysavače stlačený vzduch. Udělejte to raději venku.
  • Samotný CPU. Několik lidí hlásí, že kromě CPU nenašli nic, co by mohli vytknout. Mohla to být také nekompatibilita mezi CPU a základní deskou. Prošla vlna zpráv týkajících se CPU Intel (únor ’97). Přichází nová vlna zpráv, které obviňují CPU Cyrix/IBM 6×86. Ačkoli to může být skutečně CPU, může to být také tím, že vaše základní deska není kompatibilní s vaším CPU. Alespoň jsem v manuálu k základní desce viděl zmínku, že není kompatibilní se staršími 6×86. Moje vlastní zkušenost je, že tato zařízení nejsou vůbec špatná a na kompilaci jádra jsem porovnal P166+ tak, aby byl ekvivalentní s P155 (1,3krát rychlejší než P120).
  • Paměťová díra. Mnoho moderních základních desek umožňuje používat staré grafické karty ISA s jedním nebo dvěma megabajty lineární vyrovnávací paměti snímků. Aby toho dosáhli, musí zmapovat paměť těsně pod 16 Mb. Nikdo ve skutečnosti tuto funkci nikdy nepoužil, ale pokud zapnete paměťovou díru (nebo podporu LFB v některých BIOSech), váš počítač bude jistě nefunkční … — Paul Connolly ( pconnolly@macdux.com.au )
  • X a AMD nekompatibilita. Existuje problém s řadou moderních čipů AMD, které nezvládají některé operace tak dobře, jak by měly. Pokud máte AMD a X11 často končí s „signálem 11 zachycen“, pak byste se mohli stát obětí tohoto problému. Zkuste zavést s „mem=nopentium“. — Matthew Beale ( mixonic@synitech.com ).
  • Mikrokód. Zejména na systémech SMP může CPU vyžadovat upgrade. Od katastrofy divize Pentium má Intel možnost upgradovat své CPU! CPU lze v několika verzích narazit speciální instrukcí z BIOSu. Tyto upgrady obvykle přicházejí s vaším BIOSem, takže se ujistěte, že používáte nejnovější BIOS, zvláště pokud máte systém SMP. — Jeffrey Friedl (e-mail zadržen).

    OTÁZKA

    Problémy s časováním RAM? S nastavením biosu jsem se pohrával před více než měsícem. Mezitím jsem zkompiloval mnoho jader a nic se nepokazilo. Nemůže to být časováním RAM. Že jo?

ODPOVĚDĚT

Špatně. Myslíte si, že výrobci RAM mají stroj, který dělá 60ns RAM a jiný, který dělá 70ns RAM? Samozřejmě že ne! Udělají spoustu a pak je testují. Některé splňují specifikace pro 60 ns, jiné ne. To by mohlo být 61 ns, pokud by to výrobce musel uvést číslo. V tom případě je dost pravděpodobné, že to ve vašem počítači funguje, když je například teplota pod 40 stupňů Celsia (čipy se zpomalují, když teplota stoupá. Proto některé superpočítače potřebují tolik chlazení).

Nicméně „příchod léta“ nebo dlouhá kompilační úloha mohou posunout teplotu uvnitř vašeho počítače nad „limit“. — Philippe Troin (ptroin@compass-da.com)


OTÁZKA

Nechal jsem se vtáhnout do kupy ECC paměti, protože byla o něco levnější. Cítím se jako blázen. Měl jsem si koupit dražší paměť ECC. Že jo?

ODPOVĚDĚT

Nákup dražší paměti ECC a základních desek vás chrání před určitým typem chyb: těmi, které se vyskytují náhodně průchodem alfa částic.

Protože většina lidí dokáže reprodukovat problémy se „signálem 11“ během půl hodiny pomocí „gcc“, ale nedokáže je reprodukovat testováním paměti několik hodin za sebou, dokazuje mi to, že nejde jen o náhodné překlopení částice alfa. To by si všiml i test paměti. To znamená, že se děje něco jiného.

Mám dojem, že většina problémů se sig11 je způsobena chybami časování na cestě paměti CPU <-> cache <->. ECC v hlavní paměti vám v takovém případě nepomůže.

Kdy byste si měli koupit ECC? a) Když cítíte, že to potřebujete. b) Když máte HODNĚ RAM. (Proč ne mezní číslo? Protože mezní hodnota se s časem mění, stejně jako „SPOUSTY“.) Někteří lidé mají pocit, že všichni používají ECC paměť. Odkazuji je na důvod „a)“.


OTÁZKA

Problémy s pamětí? BIOS testuje paměť a říká, že je v pořádku. Mám tento luxusní program pro DOS, který mi říká, že moje paměť je v pořádku. Nemůže to být paměť?

ODPOVĚDĚT

Špatně. Test paměti v BIOSu je naprosto k ničemu. Může dokonce občas OK více paměti, než je skutečně k dispozici, natož otestovat, zda je dobrá nebo ne.

Můj kamarád měl 640k PC (jo, to bylo dávno), který měl jeden 64kbit čip místo 256kbit čipu v druhé 256k bance. To znamená, že měl efektivně 320k pracovní paměti. Někdy BIOS testoval 384k jako „OK“. V každém případě by selhaly pouze některé aplikace. Bylo velmi těžké diagnostikovat skutečný problém…

K většině problémů s pamětí dochází pouze za zvláštních okolností. Tyto okolnosti jsou stěží známé. gcc Zdá se, že je uplatňuje. Některé testy paměti, zejména testy paměti BIOS, ne. Už nepracuji na vytvoření diskety s linuxovým jádrem a dobrým testerem paměti na něm. Zapomeň na to, že bys mě kvůli tomu otravoval…

Důvodem je to, že test paměti způsobí, že CPU provede jen několik instrukcí a vzorce přístupu do paměti bývají velmi pravidelné. Za těchto okolností se rozpadne jen velmi malá podmnožina vzpomínek. Pokud studujete elektrotechniku ​​a zajímáte se o testování paměti, diplomová práce by mohla být, abyste zjistili, co se děje. Jsou výrobci počítačů, kteří by chtěli sponzorovat takový projekt s nějakým hardwarem, o kterém klienti tvrdí, že je nespolehlivý, ale neprojde produkčními testy…


OTÁZKA

Stává se to pouze při kompilaci jádra?

ODPOVĚDĚT

Ani náhodou. Váš hardware nemůže nijak vědět, že kompilujete jádro. Náhodou se stává, že kompilace jádra je pro váš hardware velmi náročná, takže se to často stává, když kompilujete jádro. Kompilace dalších velkých balíků jako gcc nebo glibc také často spouští sig11.

  • Lidé viděli „náhodné“ pády například při instalaci pomocí instalačního skriptu slackware…. — dhn@pluto.njcc.com
  • Ostatní dostávají z jádra „chyby obecné ochrany“ (s výpisem z havárie). Ty jsou obvykle v /var/adm/messages. — fox@graphics.cs.nyu.edu
  • Někteří vidí  pád bzip2 se „signálem 11“ nebo s „selháním interního tvrzení (#1007). Bzip2 je docela dobře otestován, takže pokud se zhroutí, pravděpodobně to není chyba v bzip2. — Julian Seward (jseward@acm.org)

OTÁZKA

Na NT, Windows 95, 98, Milenium nebo XP nic nepadá. Musí to být něco specifického pro Linux.

ODPOVĚDĚT

Za prvé, Linux zatěžuje váš hardware více než vše výše uvedené. Některé operační systémy, jako jsou ty od Microsoftu uvedené výše, každopádně havarují nepředvídatelným způsobem. Nikdo nebude volat Microsoftu a říkat “hej, můj box se systémem Windows se dnes zhroutil”. Pokud to přesto uděláte, řeknou vám, že vy, uživatel, jste udělali chybu (viz rozhovor s Billem Gatesem v německém časopise….) a že když to teď funguje, měli byste držet hubu.
Tyto operační systémy jsou také poněkud „předvídatelnější“ než Linux. To znamená, že Excel může být vždy načten v přesně stejné oblasti paměti. Proto když dojde k bitové chybě, vždy ji dostane Excel. Excel se zhroutí. Nebo excel spadne jinou aplikaci. Každopádně se bude zdát, že jde o jedinou aplikaci, která selže a nesouvisí s pamětí.
Jsem si jistý, že čistě nainstalovaný systém Linux by měl být schopen zkompilovat jádro bez jakýchkoli chyb. Rozhodně žádné sig-11. (** Výjimka: Red Hat 5.0 s procesorem Cyrix. Viz jinde.**)
Opravdu Linux a gcc zatěžují váš hardware více než jiné OS. Pokud potřebujete jinou než linuxovou věc, která zatěžuje váš hardware až k pádu, můžete zkusit winstone. — Jonathan Bright (bright@informix.com)


OTÁZKA

Je to vždy signál 11?

ODPOVĚDĚT

Ani náhodou. Jiné signály jako čtyři, šest a sedm se také vyskytují příležitostně. Nejběžnější je však signál 11.

Dokud se paměť poškozuje, může se stát cokoli. Očekával bych, že se špatné binární soubory budou vyskytovat mnohem častěji, než ve skutečnosti. Každopádně se zdá, že šance jsou silně ovlivněny tím, že gcc dostane signál 11. Také vidět:

  • free_one_pmd: bad directory entry 00000008
  • EXT2-fs warning (device 08:14): ext_2_free_blocks bit already cleared for block 127916
  • Internal error: bad swap device
  • Trying to free nonexistent swap-page
  • kfree of non-kmalloced memory…
  • scsi0: REQ before WAIT DISCONNECT IID
  • Unable to handle kernel NULL pointer dereference at virtual address c0000004
  • put_page: page already exists 00000046
    invalid operand: 0000
  • Whee.. inode changed from under us. Tell Linus
  • crc error — System halted (During the uncompress of the Linux kernel)
  • Segmentation fault
  • “unable to resolve symbol”
  • make [1]: *** [sub_dirs] Error 139
    make: *** [linuxsubdirs] Error 1
  • The X Window system can terminate with a “caught signal xx”

Prvních několik jsou případy, kdy jádro „podezřívá“ chybu programování jádra, která je ve skutečnosti způsobena špatnou pamětí. Posledních pár bodů k aplikačním programům, které skončí s problémem.

— SGde Marinis (trance@interseg.it)
— Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)


OTÁZKA

Co mám dělat?

ODPOVĚDĚT

Zde je několik věcí, které můžete vyzkoušet, když chcete zjistit, co je špatně… poznámka: Některé z nich výrazně zpomalí váš počítač. Tyto věci jsou určeny k tomu, aby váš počítač fungoval správně a umožnil vám zúžit, co je na něm špatného. Pomocí těchto informací se můžete například pokusit o výměnu vadné součásti u vašeho dodavatele.

  • Propojte základní desku pro nižší rychlost CPU a sběrnice.
  • Přejděte do systému BIOS a řekněte „Načíst výchozí nastavení systému BIOS“. Ujistěte se, že jste si předem zapsali nastavení diskové jednotky.
  • Deaktivujte mezipaměť (BIOS) (nebo ji vytáhněte, pokud je na „sticku“).
  • boot kernel s “linux mem=4M” (zakáže paměť nad 4Mb).
  • Zkuste vyjmout polovinu paměti. Zkuste obě poloviny postupně.
  • Pohrát si s nastavením aktualizace (BIOS)
  • Zkuste si vypůjčit paměť od někoho jiného. Nejlépe by to měla být paměť, na které běží Linux bezchybně na druhém stroji… (Silicon Graphics Indy stroje jsou také pěkné cíle, ze kterých si lze vypůjčit paměť)
  • Pokud chcete ověřit, zda řešení skutečně funguje, vyzkoušejte následující skript:
       #!/bin/sh
       #set -x
       t = 1
       zatímco [ -f log.$t ] 
         dělat
         t=`výraz $t + 1`
       Hotovo
    
       zatímco pravdivé
         dělat
         vyčistit
         make -k bzImage > log.cur 2>&1
         mv log.cur log.$t
         t=`výraz $t + 1`
       Hotovo
    

    Všechny výsledné soubory protokolu by měly být stejné (tj. stejnou velikost a stejný obsah). Každé sestavení jádra trvá přibližně 4 minuty na 1GHz Athlonu s 512 Mb paměti. (a asi 3 měsíce na 386 se 4Mb :-).

  • Dalším způsobem, jak otestovat, zda je vaše aktuální nastavení stabilní, může být spuštění „md5sum“ na souborech různých velikostí (dd if=/dev/random of=testfile bs=1024k count=). Pokud použijete soubor dvakrát větší než vaše RAM, procvičíte si disk. Pokud použijete soubor o 4 až 10 Mb menší, než je vaše RAM, zatížíte RAM/CPU.
    Zda tato metoda zachytí všechny možné problémy, však není jisté. Gcc provádí spoustu různých instrukcí v různém pořadí a md5sum prostě nemusí trefit správnou sekvenci instrukcí, kterou dělá gcc. Ale pokud md5sum vede k chybám, může to udělat rychleji než kompilace jádra. — Rob Ludwick (rob@no-spam)

Nejtěžší na tom je, že většina lidí bude umět všechno výše uvedené kromě toho, že si vypůjčí paměť od někoho jiného, ​​a na tom nezáleží. Díky tomu je pravděpodobné, že se skutečně jedná o RAM. RAM bývala jednou z nejdražších součástí PC, takže byste k tomuto závěru raději nedospěli, ale, je mi líto, dostávám spoustu reakcí, které se nakonec ukáží jako RAM. Zatím však nezoufejte: vaše RAM nemusí být úplně promarněná: vždy ji můžete zkusit vyměnit za jinou nebo více RAM.


OTÁZKA

Nechal jsem své RAM otestovat v zařízení RAM-tester a jsou v pořádku. Nemůže to být RAM ne?

ODPOVĚDĚT

Špatně. Zdá se, že chyby, které se aktuálně vyskytují v RAMS, nejsou zjistitelné testery RAM. Je možné, že vaše základní deska přistupuje k RAM pochybným způsobem nebo jinak kazí RAM, když je ve VAŠEM počítači. Výhodou je, že svou RAM můžete prodat někomu, kdo má stále důvěru v jeho RAM-tester…


OTÁZKA

Jaký další hardware by mohl být problém?

ODPOVĚDĚT

No, nějaký hardwarový problém uvnitř vašeho počítače. Ale věci, které lze snadno zkontrolovat, by se měly nejprve zkontrolovat. Takže například všechny vaše karty by měly být správně vloženy do základní desky.


OTÁZKA

Proč na mě instalace Red Hatu útočí?

ODPOVĚDĚT

Instalace Red Hat 5.x, 6.xa 7.x má na některých počítačích problémy. Zkuste spustit instalaci pouze s 32M. To lze obvykle provést s mem=32m jako spouštěcím parametrem.

Je možné, že na CD došlo k chybě čtení. Instalační program to zvládá méně než dokonale…. Ujistěte se, že vaše CD je bezchybné! Zdá se, že instalátor bude bombardovat okrajová CD!

Lidé hlásí, a já jsem to viděl na vlastní oči, že instalace Red Hatu se mohou pokazit (selhání se signálem 7 nebo signálem 11) na strojích, které jsou naprosto v pořádku. Můj stroj byl a stále je 100% spolehlivý (vlastně stroj, na kterém jsem to testoval, je nyní spolehlivě mrtvý). Lidé se dostávají do problémů tím, že smažou starou distribuci „fungující v pořádku“ a poté chtějí nainstalovat novější distribuci Red Hat. Návrat zpět již není možný, protože návrat k verzi 5.x má také za následek stejné „chyby při instalaci“.

Patrick Haley (haleyp@austin.rr.com) uvádí, že vyzkoušel všechny konfigurace paměti až do 96 Mb (32 & 64) a zjistil, že instalace bude fungovat pouze tehdy, když bude mít nainstalovaných 96 Mb. To je také v souladu s mou vlastní zkušeností (se selháním instalací Red Hat): Zkoušel jsem instalaci na 32M počítači.

NOVINKA: Zdá se, že to může být způsobeno problémem v jádře. Jádru může (dočasně) docházet paměť a zabíjet aktuální proces. Oprava od Huberta Mantela (mantel@suse.de) je na: http://juanjox.linuxhq.com/patch/20-p0459.html.

Pokud tomu tak skutečně je, zkuste se přepnout na druhou virtuální konzoli (ctrl-alt-F2) a každých pár sekund tam napište „sync“. To snižuje množství paměti zabrané vyrovnávací paměti na pevném disku… Opravdu bych ocenil, kdyby jste mi řekli, kdybyste viděli, jak se instalace Red Hatu zhroutila dvakrát nebo vícekrát za sebou, a pak jste byli schopni instalaci dokončit pomocí tohoto triku!!!

Co děláte, abyste tento problém vyřešili?…

  • Použijte SuSE. Je to lepší: Během instalace nepadá. (Kromě toho, že ve skutečnosti  je  lepší. 😉
  • Možná narážíte na špatný blok na vašem CD. To může být závislé na pohonu. Pokud je to váš případ, zkuste vytvořit kopii CD v jiné mechanice. Zkuste si půjčit kopii Red Hatu od někoho jiného.
  • Zkuste nakonfigurovat GIGABYTE swapu. Mám dvě nezávislé zprávy, které hlásí, že to zvládli výměnou. Prosím, nahlaste mi, jestli to pomůže!
  • Upravte „nastavení“ pevného disku. Změna nastavení z „LBA“ na „NORMAL“ v biosu pomohla alespoň jedné osobě. Pokud to zkusíte, opravdu bych ocenil, kdybyste mi poslali e-mail: Rád bych od vás slyšel, zda to pomůže nebo ne. (a co jste přesně změnili, aby to fungovalo)
  • Dostal  jsem svůj  počítač k instalaci instalací minimálního základního systému a poté přidáním balíčků do nainstalovaného systému.
  • Někdo navrhl, že když se to stane, stroj může mít nedostatek paměti. Zkuste mít připravený odkládací oddíl. Instalace může být také „připravena“ na to, aby zvládla situace s nízkou pamětí, ale špatně odhadla situaci. Může například načíst RAMDISK, ponechat pouze 1M volné paměti RAM a poté se pokusit načíst 2M aplikaci. Takže pokud máte 16M RAM, bootování s mem=14M může ve skutečnosti pomoci, protože fáze „načtení RAMDISKu“ by pak selhala a instalace by pak věděla, že se má spustit z CD místo z RAMDISku. (instalace dříve fungovaly pro více než 8 milionů strojů. Je to stále pravda?)
  • Zkuste v jedné relaci vyčistit disk od všech oddílů, které bude Linux používat. Restartujte. Pak zkuste instalaci. Buď ručním rozdělením na oddíly, nebo tím, že necháte instalační program, aby na to přišel. (Beru to tak, že Red Hat má také tuto možnost, SuSE ji má…) Pokud vám to funguje, ocenil bych, kdybyste mi to řekli.
  • Může to způsobit i poškozené stahování. Duh.
  • Někdo hlásí, že instalace na 8Mb strojích již nefungují a že instalace bez chybičky skončí se sig7. — Chris Rocco (crocco@earthlink.net)
  • Jeden člověk uvádí, že mu pomohlo vypnutí funkce „BIOS shadow“ (systém & VIDEO). Protože Linux nepoužívá BIOS, stínování nepomáhá. Některé počítače vám mohou dokonce poskytnout 384 kB paměti RAM navíc, pokud vypnete stínování. Prostě to deaktivujte a uvidíte, co se stane. — Philippe d’Offay (pdoffay@pmdsoft.com).

OTÁZKA

Jaké jsou další možnosti?

ODPOVĚDĚT

Jiní zaznamenali následující možnosti:

  • Kompilátor a knihovna libc obsažené v Red Hat 5.0 mají zvláštní interakci s procesorem Cyrix. Zhroutí kompilátor, to je VELMI zvláštní. Domnívám se, že jediný způsob, jak to může být, je, když má Cyrix chybu, která byla celou tu dobu neodhalena a spolehlivě se spustí, když TENTO gcc zkompiluje jádro Linuxu. Každopádně, pokud chcete pouze zkompilovat jádro, měli byste získat nový kompilátor a/nebo knihovnu libc z webu Red Hat. (začněte na domovské stránce a klikněte na errata).
  • Kompilace jádra 2.0.x s 2.8.x gcc nebo jakýmkoli egcs nefunguje. V jádře je několik chyb, které se nezobrazují, protože gcc 2.7.x odvádí mizernou práci při jeho optimalizaci. gcc 2.8.xa egcs prostě vysypou část kódu, protože jsme mu neřekli, aby to nedělal. Každopádně obvykle dostanete jádro, které vypadá, že funguje, ale má zábavné chyby. Například X může havarovat se signálem 11. A než se zeptáte, ne, nebude to opraveno. Neobtěžuj s tím Alana nebo Linuse, OK? — Hans Peter Verne (hpverne@kjemi.uio.no)
  • Pentium-optimizing-gcc (ten s číslem verze končícím na „p“) selhává s výchozími možnostmi u určitých zdrojových souborů, jako je floppy.c v jádře. „Spouštěče“ jsou v jádře, knihovně libc a v samotném gcc. To lze snadno diagnostikovat jako „nejedná se o hardwarový problém“, protože se vždy vyskytuje na stejném místě. Můžete buď zakázat některé optimalizace (nejprve zkuste -fno-unroll-loops) nebo použít jiný gcc. — Evan Cheng (evan@top.cis.syr.edu ) (Jinými slovy: gcc 2.7.2p havaruje se sig11 na floppy.c . Řešení-1: Použijte prostý gcc. Řešení-2: Ručně zkompilujte disketu.c pomocí „-O” místo “-O2”.)
  • Špatné spojení mezi diskem a systémem. Například kabely IDE mohou mít délku pouze 40 cm (16″). Mnoho systémů se dodává s delšími kabely. Také odnímatelný IDE rack může způsobit problémy se zhroucením systému.
  • Špatně nakonfigurovaný gcc — některé části z jedné verze, některé z jiné. Po několika týdnech jsem skončil s reinstalací od nuly, aby bylo vše v pořádku. — Richard H. Derr III (rhd@Mars.mcs.com).
  • Gcc nebo výsledná aplikace může skončit s sig11, když je program propojen s knihovnami SCO (které přicházejí s iBCS). K tomu dochází u některých aplikací, které mají ve svých LDFLAGS -L/lib….
  • Při kompilaci jádra pomocí kompilátoru ELF, ale nakonfigurovaného pro a.out (nebo naopak, zapomněl jsem), dostanete signál 11 při prvním volání „ld“. To lze snadno identifikovat jako softwarový problém, protože se vždy vyskytuje při PRVNÍM volání „ld“ během sestavování. — REW
  • Ethernetová karta spolu se špatně nastaveným PCI BIOSem. Pokud má vaše (ISA) karta Ethernet otvor na sběrnici ISA, možná ji budete muset nakonfigurovat někde na obrazovkách nastavení systému BIOS. Jinak by hardware hledal na sběrnici PCI oblast sdílené paměti. Protože ISA karta nemůže reagovat na požadavky na PCI sběrnici, čtete prázdný „vzduch“. To může mít za následek chyby segmentace a pády jádra. — REW
  • Poškozený odkládací oddíl. Tony Nugent (T.Nugent@sct.gu.edu.au) hlásí, že míval tento problém a vyřešil ho mkswapem na svém odkládacím oddílu. (Nezapomeňte napsat „sync“, než po mkswapu uděláte cokoliv jiného. — Louis J. LaBash Jr. (lou@minuet.siue.edu)
  • karta NE2000. Některé levné karty Ne2000 by mohly zkazit systém. — Danny ter Haar ( dth@ci stron.nl) Osobně jsem mohl mít podobné problémy, protože můj poštovní server každou chvíli (jednou denně) silně havaroval. Nyní se zdá, že 1.2.13 a mnoho jader 1.3.x má tuto chybu. V 1.3.48 jsem to neviděl. Asi se to mezitím někde opravilo… — REW
  • Zdroj napájení? Ne, nemyslím si to. Moderní těžký systém se dvěma nebo třemi pevnými disky, SCSI i IDE nepřekročí 120 wattů nebo tak. Pokud máte spoustu starých pevných disků a starých rozšiřujících karet, požadavky na napájení budou vyšší, ale přesto je velmi těžké dosáhnout limitů napájecího zdroje. Některým lidem se samozřejmě podaří najít spoustu starých pevných disků plné velikosti a nainstalovat je do své velké věže. Tímto způsobem můžete skutečně přetížit napájecí zdroj. — Greg Nicholson ( greg@job.cba.ua.edu ) Vadný napájecí zdroj MŮŽE samozřejmě dodávat mezní výkon, což způsobuje všechny poruchy, o kterých čtete v tomto souboru…. — Thorsten Kuehnemann (thorsten@actis.de)
  • Nekonzistentní ext2fs. Některé okolnosti mohou způsobit, že kód jádra souborového systému ext2 bude mít za následek signál 11 pro Gcc. — Morten Welinder (terra@diku.dk)
  • CMOS baterie. I když nastavíte BIOS tak, jak chcete, může se vám pod nosem měnit zpět na „špatné“ nastavení, pokud je baterie CMOS špatná. — Heonmin Lim (coco@me.umn.edu)
  • Žádný nebo příliš málo odkládacího prostoru. Gcc nezvládá elegantně stav „nedostatek paměti“. — Paul Brannan (brannanp@musc.edu)
  • Nekompatibilní knihovny. Když máte symbolický odkaz z „libc.so.5“ ukazující na „libc.so.6“, některé aplikace budou bombardovat sig11. — Piete Brooks (piete.brooks@cl.cam.ac.uk).
  • Zlomená myš. Nějak se zdá, že myš se dokáže rozbít takovým způsobem, že způsobí pád některých programů (souvisejících s myší) se Sig11. Viděl jsem, že se to stalo na X serveru, který by spadl, pokud byste rychle pohnuli myší. Matthew možná ani nepohnul myší. — REW & Matthew Duggan (stauff@guarana.org).
  • Špatně usazená RAM. Ujistěte se, že je vaše RAM správně usazena v patici…. — Carroll Kong (me@carrollkong.com).

OTÁZKA

Zjistil jsem, že běh… detekuje chyby mnohem rychleji než jen kompilace jader. Uveďte to prosím na svých stránkách.

ODPOVĚDĚT

Mnoho lidí mi e-mailem s poznámkami, jako je tato. Mnozí si však neuvědomují, že narazili na JEDEN případ problematického hardwaru. Osoba doporučující „unzip -t“ měla náhodou rozbitou DRAM paměť. A stalo se, že unzip to „našel“ mnohem rychleji než kompilace jádra.

Jsem si však jistý, že u mnoha dalších problémů by to kompilace jádra nalezla, zatímco jiné testy ne. Myslím, že kompilace jádra je dobrá, protože zatěžuje spoustu různých částí počítače. Mnoho dalších testů procvičuje pouze jednu oblast. Pokud je tato oblast ve vašem případě poškozená, objeví se problém mnohem rychleji než „kompilace jádra“. Ale pokud je váš počítač v této oblasti v pořádku a v jiné porouchaný, „rychlejší“ test vám může říct, že je váš počítač v pořádku, zatímco test kompilace jádra by vám řekl, že je něco špatně.

V každém případě bych mohl stejně dobře uvést, co si lidé myslí, že jsou dobré testy, což jsou, ale ne tak obecné jako test „zkuste a zkompilujte jádro“…

  • Spusťte unzip při kompilaci jader. Použijte zip soubor velký přibližně jako RAM.
  • použijte „memtest86“ na adrese:  http://www.memtest86.com/.
  • proveďte dd if=/dev/hda of=/dev/null při kompilaci jader.
  • spusťte md5sum na velkých stromech.

Všimněte si, že ať už najdete jakoukoli rychlou metodu, jak vám sdělit, že je váš počítač rozbitý, nezaručí to, že váš počítač bude v pořádku, pokud takový test náhle již selže. Vždy doporučuji, abyste poté, co se pohráváte s věcmi, aby to fungovalo, spustili 24hodinový test kompilace jádra.


OTÁZKA

Proč není „memtest86“ první, kdo to vyzkouší, když mám podezření na problémy s pamětí?

ODPOVĚDĚT

Klidně to udělejte. Něco z toho je černá magie. Když vám však „memtest86“ řekne, že vaše RAM je v pořádku, můžete být v pokušení tomu věřit. Říká vám,  že  nenašel žádné problémy. Neříká vám to, že vaše RAM je bezchybná.

Podle mých zkušeností se problémy související s RAM někdy nenajdou pomocí testeru paměti. Vzory jsou všechny pěkné a pravidelné. Některá problematická RAM jednoduše funguje dobře pod tímto druhem stresu, ale selhává při více nevyzpytatelných stresových vzorcích způsobených „gcc“ nebo „zip“.

Takže stále doporučuji, abyste zkusili ověřit váš systém pomocí kompilací jádra a nedůvěřovali testeru paměti….


OTÁZKA

Tomu nevěřím. Komu se to stalo?

ODPOVĚDĚT

No, mně osobně se to stalo. Ale nemusíš mi věřit. Stalo se také:

  • Johnny Stephens (icjps@asuvm.inre.asu.edu)
  • Dejan Ilic (d92dejil@und.ida.liu.se)
  • Rick Tessner (rick@myra.com)
  • David Fox (fox@graphics.cs.nyu.edu)
  • Darren White (dwhite@baker.cnw.com) (L2 cache)
  • Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu)
  • Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Temp problems)
  • Michael Blandford (mikey@azalea.lanl.gov) (Temp problems: CPU fan failed)
  • Alex Butcher (Alex.Butcher@bristol.ac.uk) (Memory waitstates)
  • Richard Postgate (postgate@cafe.net) (VLB loading)
  • Bert Meijs (L.Meijs@et.tudelft.nl) (bad SIMMs)
  • J. Van Stonecypher (scypher@cs.fsu.edu)
  • Mark Kettner (kettner@cat.et.tudelft.nl) (bad SIMMs)
  • Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 converter)
  • Rick Lim (ricklim@freenet.vancouver.bc.ca) (Bad cache)
  • Scott Brumbaugh (scottb@borris.beachnet.com)
  • Paul Gortmaker (paul.gortmaker@anu.edu.au)
  • Mike Tayter (tayter@ncats.newaygo.mi.us) (Something with the cache)
  • Benni ??? (benni@informatik.uni-frankfurt.de) (VLB Overloading)
  • Oliver Schoett (os@sdm.de) (Cache jumper)
  • Morten Welinder (terra@diku.dk)
  • Warwick Harvey (warwick@cs.mu.oz.au) (bit error in cache)
  • Hank Barta (hank@pswin.chi.il.us)
  • Jeffrey J. Radice (jjr@zilker.net) (Ram voltage)
  • Samuel Ramac (sramac@vnet.ibm.com) (CPU tops out)
  • Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM speed)
  • W. Paul Mills (wpmills@midusa.net) (CPU fan disconnected from CPU)
  • Joseph Barone (barone@mntr02.psf.ge.com) (Bad cache)
  • Philippe Troin (ptroin@compass-da.com) (delayed RAM timing trouble)
  • Koen D’Hondt (koen@dutlhs1.lr.tudelft.nl) (more kernel error messages)
  • Bill Faust (faust@pobox.com) (cache problem)
  • Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: fan installed)
  • Andrew R. Cook (andy@anchtk.chm.anl.gov) (bad cache)
  • Allan Wind (wind@imada.ou.dk) (P66 overheating)
  • Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p victim)
  • R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok for months…)
  • Florin (florin@monet.telebyte.nl) (Overclocked CPU by vendor)
  • Dale J March (dmarch@pcocd2.intel.com) (CPU overheating on laptop)
  • Markus Schulte (markus@dom.de) (Bad RAM)
  • Mark Davis (mark_d_davis@usa.pipeline.com) (Bad P120?)
  • Josep Lladonosa i Capell (jllado@arrakis.es) (PCI options overoptimization)
  • Emilio Federici (mc9995@mclink.it) (P120 overheating)
  • Conor McCarthy (conormc@cclana.ucd.ie) (Bad SIMM)
  • Matthias Petofalvi (mpetofal@ulb.ac.be) (“Simmverter” problem)
  • Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p victim)
  • Greg Nicholson (greg@job.cba.ua.edu) (many old disks)
  • Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking)
  • Daniel Pancamo (pancamo@infocom.net) (70ns instead of 60 ns RAM)
  • David Halls (david.halls@cl.cam.ac.uk)
  • Mark Zusman (marklz@pointer.israel.net) (Bad motherboard)
  • Elizabeth Ayer (eca23@cam.ac.uk) (Power management features)
  • Thorsten Kuehnemann (thorsten@actis.de)

© 1996-2022 – BitWizard B.V. is a registered trademark

Leave a Reply

Your email address will not be published. Required fields are marked *