Chyba v Jádře?

11.1.2010 09:16 | Přečteno: 1358× | Linuxení aneb hrátky se šrotem | poslední úprava: 11.1.2010 09:16

Před nedávnem jsem dostal nový služební počítač, se čtyřjádrem od AMD. Osadil jsem jej velmi čerstvou openSUSE 11.2 (kernel 2.6.31.5), nainstaloval aplikace a vše běželo jako po másle. Až na BOINC...

S programem BOINC, respektive s prací, kterou přijímal (v mém případě: rosetta@home, Einstein@home, lhc@home) jsem nikdy neměl problémy - vše se vždy na předchozím PC (dvojjádro AMD, openSUSE 10.3, kernel 2.6.22.19) spočetlo, jak mělo, a to i když jsem počítači dával kouř jak se patří (týdenní výpočty MKP a podobně). Nyní se ale začaly objevovat chyby ve výpočtech, které Einstein@home kvalifikoval jako Client Errors.

První problémy začaly s využíváním GPU pro výpočty BOINCu. Vzhledem k tomu, že BOINC není schopen používat pro výpočty GPU ATI s proprietárními ovladači (tehdy jsem měl Catalyst 9.11), nehodlal se mi nastartovat BOINC client, což vyřešilo explicitní vypnutí GPU v konfiguračním souboru (celý postup je zde). Pak se mi již podařilo BOINC bez problémů zprovoznit a začaly se objevovat ony Client Errors.

Vrcholem všeho byla chvíle, kdy jsem byl na víkend pryč a při pohledu na statistiky jsem viděl ve výsledcích pouze Client Error, a to asi u třiceti workunit. Po návratu do práce jsem zjistil, že došlo k pádu plasmy a kwin4 a ve chvíli, kdy jsem hnul s myší má Xka spadla. Po restartu vše naběhlo OK, jen se prostě čas od času objeví naprosto zbytečná Client Error.

Rozhodl jsem se tedy napsat do fóra Einstein@home, zda někdo nemá podobné problémy. (Celý thread je zde.) Po všech možných úvahách (chyba CPU, problémy s GPU a podobně) vše ukazuje na chybu jádra. tato chyba by se měla projevovat pouze ve chvílích, kdy větší počet aplikací, nežli je počet fyzických jader, chce využívat CPU na 100%.

Důvodem k tomuto podezření (symptomy chyby) je:

• chyby se vyskytují v nevytíženém systému sporadicky - mé podezření je, že vznikají ve chvílích, kdy se přepínají workunity a může jich krátkodobě v jednu chvíli běžet více, nežli je celkový počet jader CPU, případně prostě náhodná aplikace vytíží jedno jádro naplno (třeba Flash, že )
• ve vytíženém systému (když běží výpočty MKP) jejich počet roste. Počet aplikací, využívajících CPU na 100% je zde opět větší, než počet jader (1 jádro zabere FEMM, o zbylá tři se dělí čtyři aplikace BOINC, vitřinou i s wineserver).
• všechny worunity byly chybné ve chvíli, kdy běžela naplno dvě jádra, ve kterých se zasekly procesy plasmy a kwin4 (každý sežral jedno jádro) a zbylé čtyři aplikace BOINC se musely dělit o dvě jádra.

A nyní můj dotaz: je možné, aby chyba vznikala tímto mechanizmem? Oficiálně se tvrdí, že tato chyba byla odstraněna v jádře 2.6.27 (její příčinou je nastavení CONFIG_PREEMPT), nicméně, jak zjistili někteří diskutující, právě tato nastavení umožňuje chybovost workunit ovlivnit. A ještě jeden dotaz: máte někdo podobné zkušenosti s touto chybou, a to ať už v rámci BOINC nebo v rámci jiné aplikace?

---

Ok, vím, že jde vlastně o dotaz, ale jednak je úvod k němu docela dlouhý a jednak bych rád vyvolal širší diskuzi o této chybě, včetně toho, zda a jak ji hlásit.

---

Díky moc,
Pushkin

       

Komentáře

[fraxinus]

A skusal si co sa stane ked spustis (PocetJadier+1) procesov so 100% zatazou? Napr. nejaku nekonecnu slucku v c. Ide mi o vylucenei vplyvy komplexnych aplikacii ako je boinc alebo kde.

void main(void) {
  while(1) {
  }
}

[pushkin]

OK, zkusím. Jenom takový začátečnický dotaz ... jak to zkompilovat?

[trekker.dk]

gcc -o program program.c

[pushkin]

Bezva, díky, už jsem tím vytížil dvě jádra. Uvidíme, jak to dopadne.

[fraxinus]

Skus viacej ako mas jadier. Napr. 10 procesov. Ak mas dve jadra (bez HT) tak load by mal byt asi 5.

[pushkin]

Uvidíme, zatím mám spuštěnou tu nekonečnou smyčku 2x, takže o zbylá dvě jádra se dělí čtyři aplikace z BOINCu, to už by generovat chyby mohlo. Uvidíme zítra.

[Ivan]

Tak jsem koukal na ten patch a tam se mluvi o FPU. Jestli si jeste dobre pamatuju problematiku a tak je problem s tim, ze pri prepnuti kontextu procesu by se mely zazalohovat hodnoty vsech registru, tzn. i FPU. To by bylo ale pomaly a hlavne ne vsechny aplikace FPU pouzivaji. Proto ma FPU flag, ktery rika jestli byla/nebyla pouzita a OS zalohuje stav FPU pouze pokud je tento flag nastaven. Podle komentare k tomu patchi to vypada, ze behem poslednich par let pribyla do kernelu heuristika, ktera rika kdy zalohovat stav FPU, a ta nejak "blble" pri preentivnim modu.

[pushkin]

Tak jsem nechal běžet nějakých 18 hodin tu nekonečnou smyčku na dvou jádrech. Výsledek: Einstein@home má 4 zničené workunity, pouze dvě se dopočítaly do konce (souhrn). Tato workunita padla ještě před zacyklením jader.

[fraxinus]

Nerozumiem. Co je to zacyklenie jadier? Zamrzol pocitac po 18tich hodinach?

[pushkin]

nn, vzal jsem tu nekonečnou smyčku, zkompiloval jí a spustil (2x). Každý z těch procesů zatížil naplno jedno jádro, takže zbytek procesů běžel na zbylých dvou jádrech. Jinak počítač nezamrznul, ty dvě smyčky jsem po 18 hodinách killnul.

[petr_p]

Z toho, že jedna aplikace blbne, nota bene uzavřená binárka, a která místo rozumného vysvětlení vrátí akorát nic neříkající číselný kód, věštit, že je chyba v jádře, je opravdu odvážné.

[pushkin]

Mno, ona ta binárka až tak uzavřená není a poskytuje i poměrně dobrý výstup (1, 2, 3, 4, atd...). Navíc se ta chyba kromě Einsteinu objevuje i v Rosettě...

[petr_p]

Aha, autoři BOINC otevřeli. Tak to je jiná.

Zmiňovaný src/protocols/ProteinInterfaceDesign/read_patchdock.cc jste už prohlížel, že si myslíte, že je chyba v jádře? Je totiž dost možné, že mají v aplikaci chybu souběhu nebo zapomněli ošetřit nepřidělení paměti nebo cokoliv jiného, co může způsobit změněné chování jádra, které přesto je zcela v souladu s API/ABI.

[pushkin]

Na tu chybu v jádře mě zaměřil fakt, že se již jednou v jádře vyskytovala a byla údajně i opravena. Jinak zdrojové kódy jsem nestudoval, tak daleko moje znalosti céčka nesahají

[Michal2]

Jaka chyba v jadre? To jsou naprosto bezne priznaky potizi s procesorem nebo pameti. A ze jsem jich jako hardore overclocker uz videl

Pro overeni sosnout prime95 http://www.mersenne.org/freesoft/ (pokud mas 64bit distro tak 64bit vezi) a spustit v torture rezimu.

[pushkin]

O tomhle jsme taky uvažovali, ale je to divné. Memtest86+ mi paměť projel dvakrát a problém nenašel a co se týče CPU, tak to přetaktované nemám. Celý systém se pak chová stabilně - tedy až na onen jeden výpadek plasmy a kwinu. Ale ten nástroj zkusím, čím víc testů, tím lépe. Díky

[Dr. Eddy]

Koukal jsem, ze jsi nechal bezet Memtest nejdrive 35min, pak hodinu - pokud se nepletu, tak memtest zkousi ruzne testy pameti, kdy nekolikrat projede pamet. Nekteri nechavaji Memtest bezet i nekolik hodin (ja jsem nechal treba 3 hodiny, nekdo jiny 8 hodin)...

[fraxinus]

Memtest & spol. dokaze len pritomnost chyby, nie jej absenciu!

[kotyz]

me einstein, seti i rosetta jedou dobre, ale climate prediction sem musel zrusit, protoze mel moc dlouhy workunity a ani jedna se mi nikdy nedopocitala, skoncila po par hodinach s chybou. system je ale stabilni a memtest nic nenasel.

[RapMan]

Vy fakt verite, ze to pocita nejaka smysluplna data?

[fraxinus]

Ja si to nemyslim. Stacil mi letmy pohlad na data ktore SETI spracovava aby mi bolo jasne ze nikdy nic nenajdu. Ked totiz ovzorkujete biely sum, bethovenovu piatu symfoniu alebo dokonaly sinus 1Hz vzorkovacou frekvenciou (arecibo) dostanete na vystupe 1Hz biely sum.

[pushkin]

Já doufám, že ano, jinak by to bylo docela mrhání výpočetním výkonem...