Signál 11 Při Kompilaci Jádra

Jedná se o překlad z http://www.bitwizard.nl/sig11/ stránky za Ivana Horak. Zdrojová stránka je autorem BitWizard B.V.

Toto FAQ popisuje jaké jsou možné příčiny jsou pro efekt, který trápí mnoho lidí v poslední době. A sice, že linux (*) – jádro (nebo jakýkoli jiný velký balík na to přijde), kompilace zhroutí se „signálem 11“. Příčinou může být software nebo (s největší pravděpodobností) hardware. Číst dál a dozvíte se více.
(*) Samozřejmě nic není Linux specifické. Pokud váš hardware je šupinatá, Linux, Windows 3.1, FreeBSD, Windows NT a NextStep budou všechny havárie.

Často kladené otázky Sig11 

OTÁZKA

Signál 11, co to znamená?

ODPOVĚDĚT

Signál 11, nebo oficiálně známý jako „chyba segmentace“, znamená to, že tento program přístupný umístění v paměti, která nebyla přiřazena. To je obvykle chyba v programu. Takže pokud píšete svůj vlastní program, to je nejpravděpodobnější příčinou. Nicméně, tento FAQ bude soustředit na možnosti kromě toho.

OTÁZKA

My (kernel) kompilace zhroutí se

   gcc: Internal compiler error: program cc1 got fatal signal 11

Co je špatného na kompilátor? Kterou verzi kompilátoru potřebuji? Je tu něco s jádrem děje?

ODPOVĚDĚT
S největší pravděpodobností není nic s instalací, váš kompilátor nebo jádra špatně. Má velmi pravděpodobné, že co do činění s hardwarem. Existuje celá řada subsystémů, které mohou být v pořádku, a existuje celá řada způsobů, jak to opravit. Čtěte dál a dozvíte se více. Existují dvě výjimky z tohoto „pravidla“. Ty by mohly být nedostatek virtuální paměti, nebo byste mohli být instalace Red Hat 5.x, 6.x nebo 7.x K dispozici je více informací o tomto blíží ke konci.

OTÁZKA
Ok to nemusí být software, Jak mám vědět jistě?

ODPOVĚDĚT
První umožňuje ujistěte se, že je hardware, který způsobuje vaše potíže. Když se „make“ zastaví, jednoduše napište „make“ znovu. Pokud se sestavuje několik dalších souborů před zastavením, musí se jednat o hardware, který je příčinou vám problémy. Je-li okamžitě opět zastaví (tj. Prověřuje několik adresářů s „tím nedá nic dělat pro xxxx“ před bombardováním přesně na stejném místě), zkuste

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

Změnit HARD_DISK na „hda“ na název vašeho disku (např. hda nebo sda. Nebo použijte „df“.). Změna mega počtu megabajtů operační paměti, které máte. To způsobí, že prvních několik megabajtů pevném disku ke čtení z disku, nutit zdrojové soubory C a GCC binární být znovu načíst z disku při příštím spuštění jej. Nyní zadejte provést znovu. Pokud to stále zastaví na stejném místě Začínám uvažovat, jestli čtete správné dotazy, jak to začíná vypadat jako problém softwaru po celý…. Nahlédněte na „Jaké jsou další možnosti “otázkou….. Pokud aniž by to „dd“ příkaz kompilátor udržuje při zastavení na stejném místě, ale přesune na jiné místo po použití „dd“, který určitě->problém přenosu ram pomocí disků.

OTÁZKA
Co to vlastně znamená? Jsi si jistý, že je to hardwarový problém?

ODPOVĚDĚT
No, kompilátor přístupná paměť mimo jeho rozsah paměti. Pokud se tak stane v pracovní hardwaru, že je to chyba programování uvnitř kompilátor. To je důvod, proč se říká, že „vnitřní chyba kompilátoru“. Nicméně, když je hardware občas vyletí trochu, gcc používá tolik ukazatelů, že je pravděpodobné, že skončí přístupu něco mimo jeho adresování rozsahu. (Náhodné adresy jsou většinou mimo adresování rozsah, protože i když vaše hlavní paměť může být podstatná část 4G v dnešní době, obvykle jen malá část je mapována na jednom procesu. 🙂 Zdá se, že v dnešní době, každý s „signál 11 “problémy dostane směrován na této stránce. Pokud jste rozvíjet své vlastní software, nebo mají software, který nebyl ladit dost, „signál 11“ (nebo segmentace porucha) je stále velmi silný náznak, že je něco s programem špatného. Pouze tehdy, když program jako „gcc“, která pracuje pro téměř všechny ostatní narazit na datovém souboru (např. Linux-kernel), který byl také osvědčeného, ​​pak je náznak, že je něco v nepořádku s hardwarem v pořádku. Je-li zlomené některé softwarová komponenta, jako hardwarové ovladače ve vašem systému, mohlo by to způsobit symptomy, které jsou velmi blízké těm, selhání hardwaru. Nicméně, když řidič je vadná to je více pravděpodobné, že způsobí vážné problémy uvnitř jádra, než jen způsobí kompilátor k havárii.

OTÁZKA
OK. I mohou mít problém s hardwarem, co je to?

ODPOVĚDĚT
Pokud se stane, že hardware může být:

• Hlavní paměť. Váš hlavní paměť může být také stále příležitostně trochu špatně. Pokud se tak stane na „píše“, nebudete vidět žádné chyby parity. Existuje několik způsobů, jak to opravit:

· Rychlost paměti může být příliš pomalý. Zvýšení počtu čekacích stavů v systému BIOS.
To by mohlo být způsobeno možností AMIBIOSs autokonfiguracního: to může vědět jen asi 486s systémem aľ 80 MHz, zatímco v současné době koupit 100 MHz verzí. – Pat V.
· Rychlost paměti může být příliš pomalý. Rychlejší DRAM Simms. Například aktuální desky ASUS vyžadovat 60 ns DRAM, pokud máte 100 nebo procesor 133 MHz (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 jsou náhodné sig11 to patří k možnostem …. (nebudu riskovat) – Andrew Eskilsson (mpt95aes@pt.hk-r.se)
· Možná si myslíte, že můžete spustit vaše 100MHz SDRAM 100MHz. Špatně! číst http://www.bitwizard.nl/sig11/sdram, proč myslím, že to je případ. Budete potřebovat alespoň jeden rychlostní stupeň rychleji, než je rychlost, které jsou dimenzované pro.
· Tam je špatný čip na jednom z SIMMy. Pokud vlastníte více než 1 břeh paměti byste měli být schopni vytáhnout moduly SIMM a zjistit, zda problém zmizí. Dávejte pozor, pro STATICKE!!!
· Zvládli jsme těžký tady poslední týden. Ukázalo se, že ALL 4 16MB SIMM byly rozděleny v tom, že se trochu poklesla přibližně jednou za hodinu. To stačilo k havárii stroje v asi jeden den, nebo nouzově jádro kompilovat asi za hodinu. Nová sada SIMMy funguje perfektně. Trvalo dlouhou dobu diagnostikovat tento jeden, protože všechny čtyři z SIMMy byly ovlivněny stejně, takže odcházející polovina paměti se nezměnil věci.
Mark Kettner (kettner@cat.et.tudelft.nl) uvádí, že jeho systém byl schopen běžet na můj test paměti na 2300 krát bezchybně, ale pak detekována kolem 10 chyb. To pak opět pokračoval detekci žádné závady na několik set běhů ….. V jeho případě se systémem jádra kompiluje byla mnohem účinnější způsob zjišťování zdravotního systému (nejstabilnější uspořádání by systém mohl sestavit okolo 14 jader před se berserk). Jeho řešení bylo „obchodovat“ staré paměti pro takzvaného „rozšíření paměti“. Obchodník pak „zkoušky“ v jejich paměti testeru, který OKS paměti. On pak dostal dobrou slevu na novou paměťovou :-).
· Zdá se, že někteří 30-72 pin měniče může způsobit chyby paměti. (Podívejte se, jak starý je tato položka Kdo pamatuje 30pin moduly SIMM Nicméně všechny tyto věci držet perfektně SIMM? <-> převodníky DIMM nebo Socket370 <-> slotu 1 měniče) (To, že nebylo prokázáno, zda 4 Simms v konvertoru odešla špatné, nebo je-li převodník SIMM byl na poruchu, SIMMS byl fungující perfektně po celá léta předtím, než byly přesunuty do konvertoru ….). – Naresh Sharma (n.sharma@is.twi.tudelft.nl) , Paul Gortmaker (paul.gortmaker@anu.edu.au) dodává, že převodníky SIMM by měl mít alespoň 4 bypass kondenzátory pro udržení napájení z SIMMy čistotě.
· Je-li obnovovací DRAM nepracuje správně, budou DRAM pomalu ztrácejí svou informaci. Někteří (486) desky přestane osvěžující správně při zapnutí „skryté obnovování“. Zdá se, že program s názvem „dram“ kolem, které mohou také zkazit obnovování způsobit problémy sig11. – Hank Barta (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
· Počet čekacích stavů může být příliš nízká. Zvýšení počtu čekacích stavů v systému BIOS pro opravu. Snaha deska Intel neumožňuje zvýšit paměti čekání stavy. To lze pravděpodobně stanovena blikající MR BIOS na základní desce. – David haly (david.halls@cl.cam.ac.uk)
· Některé paměťové moduly prostě nemají rádi spolupracovat s ostatními. Odděleně oba pracují společně nemají. To je nejvíce pravděpodobné, že se stane, když smícháte různých značek a velikostí. Oficiálně pokud se budete držet na specifikace pro všechny moduly, vždy to funguje. Neoficiálně jste někdy narazit na problémy.

• Vyrovnávací paměť. Váš vyrovnávací paměti by mohly být stále příležitostně trochu špatně. Cache jsou obvykle není vybaven parity. Můžete diagnostikovat, že se jedná o případ vypnutím cache v systému BIOS. V případě, že problém zmizí, je pravděpodobně mezipaměti. Existuje několik způsobů, jak to opravit:

· Rychlost vyrovnávací paměť může být příliš pomalý. Zvýšení počtu čekacích stavů v systému BIOS.
· Rychlost vyrovnávací paměť může být příliš pomalý. Získat rychlejší SRAM čipy.
· K dispozici je špatný čip v mezipaměti. Je nepravděpodobné, že můžete vyměnit žetony stejně snadno jako s SIMMy. Dávejte pozor, pro STATICKE!!! – Joseph Barone (barone@mntr02.psf.ge.com)
· Vyrovnávací paměť by mohla být nastavena na „odepsat“, zatímco tam je chyba v psát zpět realizaci vašeho chipsetu. Základní deska, kde se to stalo, byl „MV020 486VL3H“ (s 20M RAM) – Scott Brumbaugh (scottb@borris.beachnet.com) (Poštovní adresa nefunguje Scott: Vrať se ke mně s platnou zpáteční adresou.)
· Základní deska může vyžadovat jumper přepínat mezi Cache na tyči a staromódní dip chip cache. (JP16 na rev 2.4 ASUS P/I-P55TP4XE desky)

• Převody disků. Blok přicházející z disku by mohla vzniknout občas bitové chyby.

· Pokud máte tento problém, jste s největší pravděpodobností muset provést příkaz „dd“ na „tah“ Problém z jednoho místa na druhé….
· Některé pevné disky IDE nemůže zpracovat volbu „irq_unmasking“. To může zobrazit pouze při zatížení. A to by mohlo ukázat jako sig11.
· Některé konfigurace nelze zpracovat DMA v některých konfiguracích. Mario Moder hlásí, že jeho systém konečně začala pracovat správně po zapnutí 32-bit IO pro jeho HD a jeho CD-ROM. – Mario Moder (clay-man@freenet.de)
· Máte Kalok 31xx? Hodit ho do popelnice. (Nebo prodat uživateli DOS Aktualizace: Neslyšeli o Kalok po celá léta Nejspíš poprsí Jednotky také nepracují s W95 mimochodem…)
· SCSI? Ukončení? Krátká autobus mohl ještě pracovat (nespolehlivě to je) se špatným ukončením. Dlouhý autobus mohl stejně dostat chyby. Můžete zapnout parity na počítači a DISK?

• CPU sám o sobě. Některé šarže procesory mají mnohem vyšší procento těch, kteří se stalo, že „špatné“. Před několika lety: originální Intel-Pentium-120 je. Před několika lety AMD K6/2-300 to (1998, produkoval v týdnech 34 až 39 let!). A v poslední době AMD K6/2-450 je. Někteří lidé se mohou rozhodnout, že říkají, 400 MHz je pro ně přijatelné, takže pokud to dopadá být problém, máte nárok na nový procesor. Jít a vyměnit ho tam, kde jste ho koupili. (Zapomeňte na ty P120 let, to nestojí za námahu…;-) – Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr) a Mark Keegan (keegan@mx.qc.ca)
• CPU sám o sobě. Některé šarže procesory K6 prostě mají konstrukční chybu. Číst http://www.multimania.com/poulot/k6bug.html a pak se ujistil, dostanete svůj K6 vyměnit. – Rongen (rongen@istar.ca).

• Přetaktování. Cyrix P-166 procesory běží na 133MHz, ne na 166. To musí být logické, aby kluci na Cyrix, ale nikdo jiný. Dáváte jim přetaktování, pokud je běžet na 166MHz….. (Poznámka:. Některé z těchto častých dotazů je dost stará Nyní AMD začalo dělat stejnou věc:. XP1800 je běh na 1533MHz)
• Přetaktování. Někteří výrobci (či soukromé osoby), myslím, že je možné přetaktovat některé procesory. Některé z nich mohou pracovat jiní ne. Možná budete chtít zkusit vypnout turbo (Všimněte si, že většina Pentium desky již nepodporují režim non-turbo) a zjistit, zda problém zmizí. Zkontrolovat rychlost vašeho CPU v porovnání (vytištěné na něj opatrně vyjměte ventilátor, pokud je to nutné) s tím, co základní desce propojky nebo nastavení BIOS říci…. Zdá se, že dokonce i Intel mohou dělat chyby v této oblasti. Nyní mám několik spolehlivé zprávy, že úředník pentium by sig11 při jejich jmenovitých otáčkách, ale ne při nižší rychlosti. Co se týče některých rychlosti základní desky je třeba zdůraznit, jen těžší pro pomalejší rychlost procesoru (120 MHz-> deska běží na 60MHz, 100MHz-> deska běží na 66MHz), myslím, že je nepravděpodobné, že to má co do činění se základní deskou. Navíc nová 120MHz procesor je nyní funguje správně. – Samuel Ramac (sramac@vnet.ibm.com). To není specifická pro Intel nebo některý z jeho konkurentů.
• Přetaktování. V současné době, rychlost procesoru, ztrátový výkon atd atd. Jsou tak blízko „hrana“, které tu a tam spolehlivé společnosti jako Intel muset uchýlit k triky, které Overclockers používají ke zlepšení výkonnosti. Výsledky mohou být také srovnatelné: Náhodné Zablokování, sig11 je atd. Atd.

• Teplota CPU. Vysoká rychlost procesoru by mohlo dojít k přehřátí bez správného chladiče. To může být také způsobena tím, selhávající ventilátorem. (Můj osobní ‚486 má ventilátor, který trvá několik minut se dostat až na rychlost. Pravděpodobně to bude ve skutečnosti nikdy nezdaří, protože je to nyní vyřazeno z provozu :-). Procesor může být nevyzpytatelné, pokud „tlačil“ kompilací jádra. Tento problém se zhoršuje, pokud zakážete „HALT“ na příkazovém řádku LILO. Linux se snaží k moci-down CPU vykonáním „halt“ instrukce, když je systém nečinný. To zachovává sílu, a proto je teplota procesoru klesne, když je systém nečinný. Můžete se tedy nemusí tento problém, když prostě editaci všimnout, a to by mohlo povrch teprve po několika hodinách CPU náročných úloh, když je okolní teplota je vysoká. Pokud máte Pentium s Fdiv chyby, je vhodné obchodovat ji společnosti Intel. Oni vám zašleme novou že prednastavenou oficiální Intel schváleného FAN. Také si všimněte, že většina normálních lepidla jsou velmi špatné tepelné vodiče. K dispozici je speciální tepelné lepidlo k dispozici, které by měly být použity, když potřebuje ventilátor, které mají být nalepeny na CPU. – Arno Griffioen (arno@ixe.net), – W. Paul Mills (wpmills@midusa.net) – Alan Wind (wind@imada.ou.dk)
Intel uvádí, že pracovní teplota se pohybuje po vnější části vašeho procesoru je:
0-85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 procesor
0-95 C: IntelDX2, procesory IntelDX4 OverDrive®
0-80 C: 60 MHz Pentium®
0-70 C: 66 až 166 MHz procesor Pentium

Informace o tom, jak změřit to i 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 Tento dokument je stále. mírně zastaralé, ale stále je velmi přesné. zdá se, že otázky pohybovat trochu tu a tam stejně.) (Intel se nyní přesunul do souboru. nemohl jsem najít novou. je někdo, kdo mi může poukázat do nového umístění???)

• CPU napětí. Některé základní desky umožňují vybrat napětí procesoru. Některé základní desky špatně dokumentovat nastavení můstků, které spravují tato. Zdá se, že 5V procesor mohl ještě pracovat většinu času na 3,3 voltů….. – Karl Heyes (krheyes@comp.brad.ac.uk)
• RAM napětí. Zdá se, že výrobci se připravují na 3,3 RAM teď. Most paměť je nyní 3,3. (Ale pozor, pokud máte desku schopnou stanovení RAM napětí: 3,3 RAM zlomí při 5V…..) (Po vyslechnutí málo o tom, myslím, že spínač musí být automatické.)
• Místní autobus přetížení. Při 25 MHz máte povoleno mít 3 VesaLocalBus karty (VLB), na 33MHz jen dva, na 40MHz jediná a hádejte co na 50MHz NONE! (Tj. Máte možnost spustit systém s 50MHz místním autobusem, ale pak vám není dovoleno používat jakékoliv karty VLB). Některé systémy začít jednat šupinatá při přetížení VLB. Dokonce i když váš VLB není přetížen (přes výše uvedených mezních hodnotách), systém může přijít o několik nanosekund marže tím, že přidá další VLB karty, takže možná budete muset přidat cache stavu čekání, nebo tak něco poté, co jste přidal nová VLB karty…. – Richard Postgate (postgate@cafe.net)

• Řízení spotřeby. Některé notebooky (a dnes i „zelené“ PC) mají funkce pro správu napájení. To by mohlo narušit s Linuxem. Jeden rys by mohl ušetřit paměťový obraz do HD a obnovení paměti RAM při stisknutí tlačítka. Zní to jako legrace, ale ovladače zařízení Linux nečekejte, že hardware byl vypnut mezi dvěma přístupy. Někteří se mohou zotavit, ale jiní ne. Zkuste jeho vypnutí nebo zapnutí „podporu APM“ ve svém jádře. – Elizabeth Ayer (eca23@cam.ac.uk)
• Prach nahromadění. Některé prach by mohl vést trochu a vytváří slabý krátký. To by mohlo zvýšit kondenzátory někde, a degradovat časové charakteristiky. To by mohlo narušit tepelný tok, a vést k přehřátí komponent. Mohlo by to krátká spojení jumper! Doporučuji, aby každý rok nebo tak, je to dobrý nápad otevřít počítač a vysát vnitřek. Tip: Ti, bavlna-on-a-stick věciček pomáhají popichování prachu z nedostupných míst… – Craig Graham (c_graham@hinge.mistral.co.uk). Někdo jiný mi řekl: pokud je to možné, použít stlačeným vzduchem věci namísto vysavače. S výhodou to udělat venku.
• CPU sám o sobě. Několik lidí se hlásí, že se jim podařilo nalézt nic vinit kromě CPU. To by mohlo také byli nekompatibility mezi CPU a základní desky. Vlna zpráv týkajících Intel procesory prošlo (únor ’97). Nová vlna zpráv přichází v tom, že jsou viní Cyrix/IBM 6×86 procesory. I když by to mohlo být skutečně CPU, mohlo by to také být, že vaše základní deska je neslučitelné s CPU. Aspoň jsem viděl manuál k základní desce zmínku, že není kompatibilní se staršími 6×86 let. Moje vlastní zkušenost je, že tato zařízení nejsou vůbec špatné, a na kompilaci jádra I porovnány s P166+ za rovnocenné s P155 (1,3 krát rychlejší než P120).

• Díra paměti. Mnoho moderních základních desek umožňují používat staré grafické karty ISA s jedním nebo dvěma megabyty lineární framebufferu. K dosažení tohoto cíle, musí zmapovat paměť těsně pod 16Mb. Nikdo vlastně nikdy používal tuto funkci, ale pokud se dáte díru paměti (nebo podporu LFB v některých BIOSech) na, bude váš počítač jistě potrhlý ​​….. – Paul Connolly (pconnolly@macdux.com.au)
• X a AMD nekompatibilita. To je problém s partou moderních AMD čipy, které nejsou zvládnout některé operace zdaleka tak dobré, jak by měly. Pokud máte AMD a X11 často skončí s „signálu 11 ulovených“, pak byste měli být obětí tohoto problému. Zkuste bootování s “mem = nopentium”. – Matthew Beale (mixonic@synitech.com).
• Mikrokódu. Zejména na SMP systémech CPU může potřebovat upgrade. Vzhledem k tomu, divize katastrofy Pentium, Intel mají své procesory pole rozšiřitelná! CPU může být naražený několik verzí pomocí speciálního pokynu BIOS. Tyto aktualizace obvykle přicházejí s BIOSu, takže ujistěte se, že máte spuštěnou nejnovější BIOS, a to zejména pokud máte SMP systém. – Jeffrey Friedl (Email odepřen).

OTÁZKA
Problémy RAM načasování? pohrávala jsem se nastavení systému BIOS více než před měsícem. Jsem sestavil řadu jader v mezidobí a nic se pokazilo. To nemůže být časování RAM. Že jo?

ODPOVĚDĚT
Špatně. Myslíte si, že výrobci RAM mít stroj, který dělá 60ns RAM a ještě jeden, který dělá 70ns RAM? Samozřejmě že ne! Dělají spoustu, a poté je testovat. Některé splňují specifikace po dobu 60 ns, jiní ne. Ty by mohly být 61 ns, pokud by výrobce musel dát číslo na něj. V tomto případě to je docela pravděpodobné, že to funguje ve vašem počítači, když je například teplota klesne pod 40 stupňů Celsia (čipy stanou pomalejší, kdy teplota stoupá. To je důvod, proč někteří superpočítače potřebovat tolik chlazení).

Nicméně „příchod léta“ nebo dlouho kompilace úloha může posunout teplotu uvnitř počítače přes „hranice“. – Philippe Troin (ptroin@compass-da.com)

OTÁZKA
Dostal jsem suckered do nekupujete ECC paměti, protože to bylo o něco levnější. Cítím se jako blázen. Měl jsem si koupil dražší ECC paměti. Že jo?

ODPOVĚDĚT
Kupovat dražší ECC paměti a základní desky vás chrání proti určitému druhu chyby: Ty, které se vyskytují náhodně při průchodu částice alfa.

Vzhledem k tomu, že většina lidí dokáže reprodukovat signál „11“ problémy během půlhodiny pomocí „gcc“, ale nelze reprodukovat testem paměti pro hodin v kuse, která ukáže mi, že to není jen náhodný alfa částice proletí kousek. To by si všiml testem paměti taky. To znamená, že něco se děje.

Mám dojem, že většina problémů sig11 jsou způsobené načasování chyb na CPU <-> Cache <-> cesta paměti. ECC z hlavní paměti nepomůže vám v tomto případě.

Kdy byste měli koupit ECC? a) Když máte pocit, že ji budete potřebovat. b) Pokud máte spoustu RAM. (Proč ne číslo cut-off? Vzhledem k tomu, že cut-off se mění s časem, stejně jako „Spousta“). Někteří lidé cítí velmi silně o všem pomocí ECC paměti. Mám na mysli, aby rozum „a)“.

OTÁZKA
Problémy s pamětí? Můj BIOS otestuje svou paměť a řekne mi jeho ok. Mám tento efektní programu DOS, který mi říká moje paměť je v pořádku. Nemůže být paměť v pořádku?

ODPOVĚDĚT
Špatně. Test paměti v systému BIOS je naprosto k ničemu. To může dokonce příležitostně OK více paměti než je skutečně k dispozici, natož vyzkoušet, zda je to dobře nebo ne.

Jeden můj přítel míval 640K PC (jo, to bylo už dávno), který měl místo jednoho 64kbit čip je 256kbit čip ve druhém 256k banky. To znamená, že ve skutečnosti měl 320K pracovní paměť. Někdy BIOS bude testovat 384k jako „OK“. Mimochodem, jen se nepodaří některé aplikace. Bylo to velmi těžké diagnostikovat skutečný problém…

Většina problémy s pamětí dojít pouze za zvláštních okolností. Tyto okolnosti jsou sotva znal. gcc Zdá se, že jejich uplatnění. Některé paměťové testy, zejména testy paměti BIOS, ne. Jsem již pracuje na vytvoření diskety s linuxové jádro a dobrou paměť testeru na něm. Zapomeňte na mě štve o tom……

Důvodem je skutečnost, že test paměti způsobí, že CPU vykonat jen několik instrukcí a přístupu do paměti vzory se mají tendenci být velmi pravidelný. Za těchto okolností jen velmi malá část vzpomínek porouchá. Pokud jste studoval elektrotechniku ​​a mají zájem o testování paměti, Masters práce by mohlo být, aby zjistili, co se děje. Existují výrobci počítačů, že by chtěl sponzorovat takový projekt s některými hardware, který klienti tvrdí, že je nespolehlivý, ale neselže výrobní testy……

OTÁZKA
Stává se, jen když jsem kompilace jádra?

ODPOVĚDĚT
Ani náhodou. Neexistuje žádný způsob, jak váš hardware může vědět, že jste kompilaci jádra. To jen tak se stane, že jádro kompilace je velmi těžké na hardwaru, tak prostě se to stane hodně, když jste kompilaci jádra. Kompilace další velké balíky jako gcc nebo glibc také často vyvolat sig11.

• Lidé viděli „náhodné“ zhroucení například při instalaci pomocí instalačního slackware skript…. – dhn@pluto.njcc.com
• Jiní dostat „chybám obecné ochrany“ od jádra (s crashdump). Ty jsou obvykle v /var/adm/messages. – fox@graphics.cs.nyu.edu
• Někteří vidí bzip2crash s „signal 11“ nebo „internal assertion failure (#1007).“ Bzip2 je docela dobře testovány, takže pokud dojde k chybě, je pravděpodobné, že není chyba v bzip2. – Julian Seward (jseward@acm.org)

OTÁZKA
Nic se zhroutí na NT, Windows 95, 98, Millennium nebo XP. Musí to být něco, co Linux specifické.

ODPOVĚDĚT
Za prvé, Linux zdůrazňuje hardwaru více než všechny výše uvedené. Některé operační systémy, jako jsou ty společnosti, pojmenovaný výše havárii v nepředvídatelným způsobem stejně. Nikdo se chystá zavolat Microsoft a říct: „Hej, moje okna box dnes havaroval“. Pokud tak učiníte tak jako tak, řeknou vám, že jste uživatel, udělal chybu (viz rozhovor s Billem Gatesem v německém časopise….) a že od té doby to funguje teď, měli byste se držet hubu.
Tyto operační systémy jsou také o něco více „předvídatelné“ než Linux. To znamená, že Excel by mohla být vždy vložen do přesně stejné oblasti paměti. Proto pokud dojde k bit-error, je vždy excel, že ji dostane. Excel se zhroutí. Nebo excel se zhroutí jinou aplikaci. V každém případě to bude jevit jako jediná aplikace, která selže, a nesouvisí s pamětí.
To, co jsem si jist, ze je to čistě nainstalovaný systém Linux by měl být schopen sestavit jádro bez chyby. Určitě ne sig-11 z nich. (** Výjimka: Red Hat 5.0 s procesorem Cyrix Viz jinde **).
Opravdu Linux a gcc stres váš hardware více než u jiných operačních systémů. Potřebujete-li non-linux věcičku, která zdůrazňuje váš hardware k bodu shazovat, můžete zkusit Winstone. – Jonathan Bright (bright@informix.com)

OTÁZKA
Je to vždy signal 11?

ODPOVĚDĚT
Ani náhodou. Jiné signály, jako například čtyři, šest a sedm také nastat příležitostně. Signál 11 je nejběžnější ačkoli.
Tak dlouho, jak paměť je stále poškozen, může se stát cokoli. Očekával bych špatné binárky dochází mnohem častěji než ve skutečnosti dělají. V každém případě se zdá, že šance jsou silně zkreslené směrem gcc dostává 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í z nich jen málo, jsou případy, kdy se jádro „podezřelých“ kernel-programování-chybě, která je ve skutečnosti způsobeno špatnou pamětí. V posledních několika přejděte na aplikačních programů, které skončí s problémy.
– S.G.de Marinis (trance@interseg.it)
– Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)

OTÁZKA
Co mám dělat?

ODPOVĚDĚT
Zde jsou některé věci vyzkoušet, pokud chcete zjistit, co je špatně … Poznámka: Některé z nich budou výrazně pomalý počítač dolů. Tyto věci jsou určeny, aby váš počítač správně fungovat a umožní zúžit, co je na tom špatného. Na základě těchto informací můžete například pokusit získat vadného dílu nahrazena vašeho dodavatele.

• Mikiny základní desky pro nižší CPU a rychlost sběrnice.
• Jít do BIOSu a říct, že „výchozí zatížení systému BIOS“. Ujistěte se, že píšete nastavení disková jednotka se předem.
• Vypnout cache (BIOS) (nebo ji vytáhněte, jestli je to na „stick“).
• Bota jádro s “Linux mem=4M” (deaktivuje paměť nad 4MB).
• Zkuste vyndání polovinu paměti. Zkuste obě poloviny v pořadí.
• Housle s nastavením refresh (BIOS)
• Zkuste výpůjční paměť od někoho jiného. Přednostně by to mělo být paměti, která běží Linux bezchybně v jiném počítači … (Silicon Graphics Indy stroje jsou také pěkné cíle, které půjčují paměti z)
• Chcete-li ověřit, zda řešení opravdu funguje zkuste následující scénář:

   #!/bin/sh
   #set -x
   t=1
   while [ -f log.$t ] 
     do
     t=`expr $t + 1`
   done

   while true
     do
     make clean
     make -k bzImage > log.cur 2>&1
     mv log.cur log.$t
     t=`expr $t + 1`
   done

Všechny výsledné logfiles by měla být stejná (tj. Stejnou velikost a stejný obsah). Každý kernel build trvá asi 4 minuty na 1GHz Athlon s 512 MB paměti. (A asi 3 měsíce na 386 s 4MB :-).

• Dalším způsobem, jak otestovat, zda vaše aktuální nastavení je stabilní může být ke spuštění “md5sum” na soubory různých velikostí (dd if=/dev/random of=testfile bs=1024k count=). Máte-li soubor použít dvakrát velikost paměti RAM, budete vykonávat svůj disk. Používáte-li soubor 4 až 10 Mb menší než paměti RAM, budete vykonávat svou RAM/CPU.
Zda je tato metoda zachycuje všechny možné problémy, je však nejistý. Gcc provádí spoustu různých instrukcí v různých pořadích, a md5sum možná prostě trefit ten správný sled instrukcí, které gcc dělá. Ale pokud md5sum vede k chybám, může to učinit rychleji než kompilace jádra. – Rob Ludwick (rob@no-spam)

Nejtěžší je, že většina lidí bude moci dělat vše výše uvedené s výjimkou půjčování paměť od někoho jiného, a to neznamená, že rozdíl. Je pravděpodobné, že to opravdu je RAM. RAM býval jedním z priciest částí počítače, takže byste raději přijít k tomuto závěru, ale je mi líto, mám spoustu reakcí, které nakonec se ukáže, že je RAM. Avšak nezoufejte zatím jen: vaše RAM nemusí být zcela zbytečná: můžete se vždy snažit vyměnit ji za jinou nebo více paměti RAM.

OTÁZKA
Měl jsem RAM testován v RAM-testeru zařízení, a jsou v pořádku. Nemůže být právo RAM?

ODPOVĚDĚT
Špatně. Zdá se, že chyby, které se v současné době vyskytují v RAMS nejsou detekovatelné RAM testery. Mohlo by se stát, že vaše základní deska je přístup k RAM v pochybných způsobů nebo jiným zásahům do RAM, zatímco je v počítači. Výhodou je, že můžete prodat svůj RAM pro někoho, kdo má stále důvěru v jeho RAM-testerem……

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

ODPOVĚDĚT
No, jakýkoli hardware problém uvnitř počítače. Ale věci, které lze snadno zjistit třeba zkontrolovat jako první. Tak například všechny vaše karty by měly být správně vložena do základní desky.

OTÁZKA
Proč je Red Hat nainstalovat bombardování na mě?

ODPOVĚDĚT
Red Hat 5.x, 6.xa 7.x nainstalovat má problémy na některých počítačích. Zkuste spustit instalaci pouze 32M. To může být obvykle provedeno s mem=32m jako parametr spuštění.
Mohlo by se stát, že je čtení chyby na disku CD-ROM. Instalační program zvládá to méně než perfektní….. Ujistěte se, že vaše CD je dokonalý! Zdá se, že instalační program bude bombardovat na marginálních CD!

Lidé hlásit, a já jsem viděl na vlastní oči, že Red Hat instaluje se může pokazit (selhání signálem 7 nebo signálem 11) na strojích, které jsou naprosto v pořádku. Můj počítač byl a stále je 100% spolehlivý (vlastně stroj jsem testoval to dál, je teď spolehlivě mrtvý). Lidé se dostal do potíží, že ničí staré „pracovní pohodě“ distribuce, a pak chtějí nainstalovat novější Red Hat distribuce. Vraťme se zpět je pak již není možné, protože se vrací do 5.x má také za následek stejné „zhroutí při instalaci“.

Patrick Haley (haleyp@austin.rr.com) uvádí, že se snažil všechny konfigurace paměti až 96Mb (32 a 64), a zjistil, že pouze tehdy, když instaloval 96Mb, instalace bude fungovat. To je rovněž v souladu s vlastní zkušenosti (Red Hat instaluje selhání): Zkoušel jsem instalaci na 32M stroji.

NOVÝ: Zdá se, že to může být kvůli problému jádra. Jádro může (temporarliy) docházet paměti a zabít aktuální proces. Oprava Hubert Mantel (mantel@suse.de) je na adrese: http://juanjox.linuxhq.com/patch/20-p0459.html.

Pokud je to skutečně případ, zkuste přepnout na druhou virtuální konzoli (ctrl-alt-F2) a typu „SYNC“ tam každých několik sekund. To snižuje množství paměti přijaté harddisk nárazníky… Já bych opravdu ocenil ozvete, pokud jste viděli Red Hat nainstalovat havárii dvakrát nebo vícekrát za sebou, a pak byli schopni dokončit instalaci pomocí tohoto triku!!!

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

• Použít SuSE. Je to lepší: To není krach během instalace. (Kromě toho, že ve skutečnosti je lepší. 😉
• Možná máte spuštěnou do špatného bloku na disku CD-ROM. To může být pohon závislé. Jestli je to tento případ, zkuste dělat kopie CD v jiné jednotce. Zkuste půjčování někdo elses kopii Red Hat.
• Zkuste konfiguraci gigabajt odkládacího prostoru. Mám dvě nezávislé zprávy, které hlásí, že se dostali až s vystoupením o swapu. Prosím, hlaste se mě, jestli to pomůže!
• Upravte „Nastavení“ na pevném disku. Změna nastavení z „LBA“ na „Normální“ v systému BIOS pomohl nejméně jednu osobu. Pokusíte-li se to, tak bych opravdu ocenil, kdyby jste mi to e-mail: Já bych rád slyšel od vás, jestli to pomůže, nebo ne. (A co přesně se změnil na dostat do práce)
• Já mám stroj instalovat instalováním minimálního základního systému, a pak přidávání balíků do instalovaného systému.
• Někdo navrhl, že stroj může být out-of-paměti, když se to stane. Zkuste s odkládací oddíl připraven. Také instalace je „připraven“ zvládnout nízké Mem situací, ale vyhodnotili situaci. Například to může načíst RAMDISK, odcházející jen 1M volné paměti RAM, a pak se při pokusu o načtení aplikace 2M. Takže pokud máte 16M RAM, bootování se mem = 14M může skutečně pomoci, jako „zatížení RAMDISK“ fáze by pak nezdaří a instalace by pak víte spustit z CD namísto off ramdisku. (Nainstaluje dříve pracoval pro> 8M strojů. Je to ještě pravda?)
• Zkuste, v jednom sezení vyčistit disk ze všech oblastí, které mají v úmyslu použít Linux. Reboot. Potom zkuste nainstalovat. Buď rozdělením ručně, nebo nechat instalační program na to přijít. (Beru to, že Red Hat má tuto možnost také SuSE má to …) Je-li to funguje u vás, tak bych ocenil, kdyby jste mi to říct.
• Poškozený download může také způsobit to. Duh.
• Někdo uvádí, že se instaluje na 8MB strojích již nepracují, a že instalace ungracefully ukončí s sig7. – Chris Rocco (crocco@earthlink.net)
• Jedna osoba hlásí, že zákaz „BIOS stín“ (systém a VIDEO), pomáhal mu. Jako Linux nepoužívá BIOS, stínování to nepomůže. Některé počítače mohou dokonce vám 384k extra RAM, pokud zakážete stínování. Jen ji zakázat, a uvidíme, co se stane. – Philippe d’Offay (pdoffay@pmdsoft.com).

OTÁZKA
Jaké jsou další možnosti?

ODPOVĚDĚT
Jiní si všimli následující možnosti:

• Překladač a libc zahrnuty v Red Hat 5.0 mají zvláštní interakci s procesorem Cyrix. Došlo ke zhroucení kompilátoru, je to velmi zvláštní. Řekl bych, že jediný způsob, jak to může být případ, kdy je Cyrix má chybu, která odešla nezjištěný celou tu dobu a spolehlivě dostane spustí, když ŽE gcc zkompiluje linuxové jádro. V každém případě chci kompilace jádra, pokud byste měli dostat nový kompilátor a/nebo libc z webu Red Hat. (Start na domovské stránce, a klikněte na errata).
• Kompilace 2.0.x jádro s 2.8.x gcc nebo jakékoliv egcs nefunguje. Existuje několik chyb v jádře, které nevykazují, protože gcc 2.7.x dělá mizernou práci optimalizací. gcc 2.8.x a egcs jen výpis některých kódu, protože jsme neměli to neříct. Mimochodem, obvykle dostanete jádro, které se zdá fungovat, ale má legrační chyby. Například X může dojít k selhání s signálu 11. Oh, a než se zeptáš, ne, že to nebude možné opravit. Neobtěžujte Alana nebo Linuse o to v pořádku? – Hans Peter Verne (h.p.verne@kjemi.uio.no)
• Pentium-optimalizace-gcc (ten s číslem verze končící na „p“) selže s výchozí možnosti pro určité zdrojové soubory, jako floppy.c v jádře. Dále jen „spouštěče“ jsou v jádře, libc av samotném gcc. To je snadno diagnostikována jako „není hardwarový problém“, protože se vždy děje na stejném místě. Můžete buď zakázat některé optimalizace (zkuste -fno-rozbalit smyček první) nebo použijte jiný gcc. – Evan Cheng (evan@top.cis.syr.edu) (Jinými slovy:.. Gcc 2.7.2p srážkách s sig11 na floppy.c Řešení-1: Použití prostý gcc Řešení-2: Ruční sestavit floppy.c s “-O” namísto “-O2”.)
• Špatné spojení mezi diskem a systémem. Například jsou kabely IDE povoleny pouze být 40 cm (16″ ) dlouhé. Mnoho systémů přijít s delšími kabely. Také odnímatelný rack IDE může přidat dost starostí zhroucení systému.
• Špatně špatně nakonfigurovány gcc – některé součásti z jedné verze, někteří z jiného. Po několika týdnech jsem skončil nainstalovat znovu od nuly, aby všechno správně. – Richard H. Derr III (rhd@Mars.mcs.com).
• Gcc nebo výsledné aplikace může ukončit s sig11 když je program propojen proti knihoven SCO (které přicházejí s IBC). K tomu dochází v některých aplikacích, které mají -L/lib ve svých LDFLAGS….
• Při kompilaci jádra s ELF kompilátorem, ale nakonfigurován pro a.out (nebo opačně, zapomněl jsem), dostanete signál 11 na první výzvu k „ld“. To je snadno identifikován jako problém softwaru, protože vždy dojde na první volání „ld“ během sestavení. – REW
• Ethernet karta spolu se špatně nakonfigurované BIOS PCI. Pokud je váš (ISA) Ethernet karta má otvor na sběrnici ISA, možná budete muset nastavit někde v BIOSu. V opačném případě by hardware vypadat na sběrnici PCI sdílené oblasti paměti. Vzhledem k tomu, ISA karta nemůže reagovat na požadavky na sběrnici PCI, čtete prázdnou „vzduch“. To může vést k porušení ochrany paměti a pády jádra. – REW
• Poškozený odkládacím prostorem. Tony Nugent (T.Nugent@sct.gu.edu.au) hlásí míval tento problém a vyřešit ho pomocí mkswap na jeho swap. (Nezapomeňte na typ “sync” před dělat něco jiného po mkswap. – Louis J. LaBash Jr. (lou@minuet.siue.edu))
• NE2000 karty. Některé levné NE2000 karty by mohlo zkazit systému. – Danny ter Haar (dth@cistron.nl) Já osobně mohl mít podobné problémy, jako můj mail server narazil tvrdě občas (jednou denně). Nyní se zdá, že 1.2.13 a hodně se 1.3.x jádra mají tuto chybu. Neviděl jsem to v 1.3.48. Pravděpodobně dostal někde pevně do té doby…. – REW
• Zdroj napájení? Ne, já si to nemyslím. Moderní stavební systém s dvěma nebo třemi disku, jak SCSI a IDE nebude vyšší než 120 W nebo tak. Pokud máte spoustu starých pevných disků a starých rozšiřujících karet požadavky na výkon bude vyšší, ale přesto je velmi těžké dosáhnout hranice napájení. Samozřejmě někteří lidé podaří najít spoustu starých plné velikosti pevných disků a jejich instalaci do jejich velké věže. Můžete skutečně Nepřetěžujte powersupply tímto způsobem. – Greg Nicholson (greg@job.cba.ua.edu) Vadný zdroj napájení lze samozřejmě dodat mezní sílu, která způsobí, že všechny vadné, že budete číst o v tomto souboru …. – Thorsten Kuehnemann (thorsten @ actis.de)
• Nekonzistentní ext2fs. Některé okolnosti mohou způsobit kernel kód souborového systému ext2 za následek signál 11 pro GCC. – Morten Welinder (terra@diku.dk)
• CMOS baterie. I když nastavíte BIOS tak, jak chcete, by to mohlo být se vrátit do „špatných“ nastavení pod nosem, pokud je baterie CMOS je špatný. – Heonmin Lim (coco@me.umn.edu)
• Žádný nebo příliš malý odkládací prostor. Gcc není řádně zvládnout „nedostatek paměti“ stavu. – Paul Brannan (brannanp@musc.edu)
• Nekompatibilní knihovny. Když máte symbolický odkaz z „libc.so.5“ ukazuje na „libc.so.6“, budou některé aplikace bombardovat s sig11. – Piete Brooks (piete.brooks@cl.cam.ac.uk).

• Zlomený myší. Nějak, myš se zdá být schopna prolomit takovým způsobem, že to způsobuje některé programy (související myš) ke srážce s Sig11. Viděl jsem to stalo na X serveru, který by selhat, pokud se rychle přesunul myš. Matthew ani nemusí být v pohybu jeho myši. – REW a Matthew Duggan (stauff@guarana.org).
• Špatně sedící RAM. Ujistěte se, že RAM je správně usazen do zásuvky…. – Carroll Kong (me@carrollkong.com).

OTÁZKA
Zjistil jsem, že běží….. detekuje chyby mnohem rychleji než jen kompilovat jader. Uveďte to na svých stránkách.

ODPOVĚDĚT
Mnoho lidí mi email s poznámkami, jako je tento. Avšak to, co mnozí si neuvědomují, je, že se setkal jeden případ problémového hardwaru. Osoba doporučovat „unzip -t“ se stalo, že mají určitou zlomenou DRAM hůl. A rozbalte stalo „najít“, které mnohem rychleji než kompilace jádra.
Nicméně, jsem si jistý, že pro mnoho dalších problémů, jádro kompilace ji najde, zatímco jiné testy ne. Myslím, že jádro kompilace je dobré, protože to zdůrazňuje, že mnoho různých částí počítače. Mnoho dalších testů právě vykonávat jen jednu oblast. V případě, že oblast se stane být rozděleny v případě, bude to ukáže nějaký problém mnohem rychleji než „jádro kompilaci“ vůle. Ale pokud váš počítač je v pořádku na danou oblast a zlomený na druhou, „rychlejší“ test může jen říct, počítač je v pořádku, zatímco testovací jádro kompilace by vám řekl něco není v pořádku.

V každém případě bych mohl stejně dobře seznam toho, co si lidé myslí, jsou dobré testy, které jsou, ale ne tak obecně jako „pokusila sestavit jádro“ test….

• Spustit rozbalit při kompilaci jádra. Použijte .zip archivu zhruba stejně velký jako RAM.
• použít “Memtest86” našel na adrese: http://www.memtest86.com/.
• dělat dd if =/dev/hda z =/dev/null při kompilaci jádra.
• běžet md5sum na velkých stromů.

Všimněte si, že bez ohledu na rychlý způsob, můžete najít vám říci, že váš počítač je rozbité, bude to nezaručuje počítač je v pořádku, pokud takový test najednou není nezdaří už ne. Vždycky jsem doporučujeme, aby po hrát s věcmi, aby to fungovalo, měli byste spustit kernel-sestavit test 24 hodin denně.

OTÁZKA
Proč není „memtest86“ první zkusit, když mám podezření problémy s pamětí?

ODPOVĚDĚT
Neváhejte, aby tak učinily. Něco z toho je černá magie. Nicméně, když „memtest86“ vám řekne, že vaše RAM je v pořádku, můžete být v pokušení věřit. Je ti, že nemůže najít žádné problémy. Není to ti, že RAM je bezchybný.
Podle mých zkušeností, problémy související s RAM jsou někdy nebyl nalezen pomocí paměťové tester. Vzory jsou všechno pěkné a správné. Některé problematické RAM prostě funguje dobře pod tímto druhem stresu, ale selže pod prudším pole napětí způsobené „gcc“ nebo „zip“.

Tak jsem ještě doporučujeme zkusit ověření systému pomocí jádro zkompiluje a nevěřil paměťové testeru….

OTÁZKA
Nevěřím, že toto. Komu se to stalo?

ODPOVĚDĚT
No na jednu se to stalo mně osobně. Ale nemusíte mi věřit. To také stalo:

  • 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 mezipaměti)
  • Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu)
  • Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Problémy s temp)
  • Michael Blandford (mikey@azalea.lanl.gov) (Problémy s temp: ventilátor CPU selhal)
  • Alex Butcher (Alex.Butcher@bristol.ac.uk) (Paměti čekání stavy)
  • Richard Postgate (postgate@cafe.net) (VLB načítání)
  • Bert Meijs (L.Meijs@et.tudelft.nl) (špatný SIMM)
  • J. Van Stonecypher (scypher@cs.fsu.edu)
  • Mark Kettner (kettner@cat.et.tudelft.nl) (špatný SIMM)
  • Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 konvertor)
  • Rick Lim (ricklim@freenet.vancouver.bc.ca) (špatný mezipaměti)
  • Scott Brumbaugh (scottb@borris.beachnet.com)
  • Paul Gortmaker (paul.gortmaker@anu.edu.au)
  • Mike Tayter (tayter@ncats.newaygo.mi.us) (Něco s mezipaměti)
  • Benni ??? (benni@informatik.uni-frankfurt.de) (VLB přetížení)
  • Oliver Schoett (os@sdm.de) (Mezipaměti skokan)
  • Morten Welinder (terra@diku.dk)
  • Warwick Harvey (warwick@cs.mu.oz.au) (bitové chybovosti v mezipaměti)
  • Hank Barta (hank@pswin.chi.il.us)
  • Jeffrey J. Radice (jjr@zilker.net) (Ram napětí)
  • Samuel Ramac (sramac@vnet.ibm.com) (CPU hraničí)
  • Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM rychlost)
  • W. Paul Mills (wpmills@midusa.net) (CPU ventilátor odpojen od CPU)
  • Joseph Barone (barone@mntr02.psf.ge.com) (špatný mezipaměti)
  • Philippe Troin (ptroin@compass-da.com) (zpožděné RAM časování problémy)
  • Koen D’Hondt (koen@dutlhs1.lr.tudelft.nl) (více chybových hlášek)
  • Bill Faust (faust@pobox.com) (mezipaměti problém)
  • Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: ventilátor instalován)
  • Andrew R. Cook (andy@anchtk.chm.anl.gov) (špatný mezipaměti)
  • Allan Wind (wind@imada.ou.dk) (P66 přehřátí)
  • Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p oběť)
  • R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok měsíce…)
  • Florin (florin@monet.telebyte.nl) (Overclocked CPU podle dodavatele)
  • Dale J March (dmarch@pcocd2.intel.com) (CPU přehřátí na notebooku)
  • Markus Schulte (markus@dom.de) (špatný RAM)
  • Mark Davis (mark_d_davis@usa.pipeline.com) (špatný P120?)
  • Josep Lladonosa i Capell (jllado@arrakis.es) (PCI opce na optimalizaci)
  • Emilio Federici (mc9995@mclink.it) (P120 přehřátí)
  • Conor McCarthy (conormc@cclana.ucd.ie) (špatný SIMM)
  • Matthias Petofalvi (mpetofal@ulb.ac.be) (“Simmverter” problém)
  • Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p oběť)
  • Greg Nicholson (greg@job.cba.ua.edu) (mnoho starých disků)
  • Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking)
  • Daniel Pancamo (pancamo@infocom.net) (70 ns namísto 60 ns RAM)
  • David Halls (david.halls@cl.cam.ac.uk)
  • Mark Zusman (marklz@pointer.israel.net) (špatný deska)
  • Elizabeth Ayer (eca23@cam.ac.uk) (Funkce pro správu napájení)
  • Thorsten Kuehnemann (thorsten@actis.de)

BitWizard B.V. is a registered trademark