ata3: reiniting channel

[Miroslav Lachman]

Dan Lukes wrote:
> Miroslav Lachman napsal/wrote, On 08/23/06 18:00:

[...]
>>Aha! Je pravda, ze jsem naposledy bootoval system prave s volbou verbose 
>>logging - lze toto chovani nekde nastavit, aby se system vzdy (dokud 
>>nereknu jinak) bootoval s verbose logging? 
> 
> 
> /boot/loader.conf (see /boot/default/loader.conf)
> za behu systemu take pomoci nastaveni prislusne sysctl

Diky moc, to jsem vubec netusil.

[...]

> 	Neznam konfiguraci toho stroje - je-li aktivni APM nebo ACPI, muze byt 
> zdrojem techto udalosti i BIOS. A na korektnost implementace techto veci 
> v BIOSu mam vlastni nazor ...
> 
> 	Mozna reseni je pozakazovat v tomto ohledu vsechno co je mozne (uz v 
> BIOSu).
> 
> 	Nicmene, to tu spradam hypotezy - nerikam, ze onen konkretni problem 
> pochazi odsud ...

S pokracujicimi problemy jsem v BIOSu vypnul snad uz vsechno, co me 
napadlo, takze jsou vypnute vsechny periferie, ktere se nepouzivaji 
(USB, LPT, FDD...), je vypnuty i APM. ACPI je zapnuty, mam pocit, ze bez 
toho mi nepobezi SMP, nebo se pletu? Kazdopadne i s UP kernelem to v 
minulosti vykazovalo stejne chyby (ztratu disku, nikoliv ata_reinit, to 
jsem dnes videl prvne - vlastne dnes poprve se se serverem stalo neco 
jineho, nez ze zmizel disk - driv zmizel disk, objevila se hlaska v logu 
a jeste nejaky cas (hodiny i dny) system bezel dal z jedineho disku v 
mirroru, ted je ale mirror zruseny a jede se primo z ad4, ad6 je jen 
jako druhy disk - takze se mozna stalo to same co jindy, ale system to 
neustal diky tomu, ze mu zmizel disk, ze ktereho jel... to ale jen hadam)

[...]

> 	Ani ja ne - nemam predstavu, zda nektera kompomenta za nejakych 
> okolnosti takovy pozadavek vyslovi. "Podezrelym" v rade prvni je v tomto 
> pripade kod softwaroveho raidu - ale opravdu nevim, jestli je to 
> podezreni opravnene.

SW RAID je na tomto serveru prave vypnuty, abych mel jistotu, ze problem 
neni v kodu gmirroru - coz se patrne potvrdilo, geom_mirror se ted vubec 
pri bootu neloaduje a system startuje z /dev/ad4s1a (drive 
/dev/mirror/gm0s1a)

> 	V nejhorsim pripade lze grepem projit kompletni zdrojaky na vyskyt 
> IOCATAREINIT - tim by se melo dat zjistit, zda jej neco pouciva, pokdu 
> ani tak co a kdy ...

[...]

> 	Zmineny dump by se vytvoril, pokud pri padu doslo k panicu systemu, v 
> konfiguraci je nastaveno kam se dump ma delat (dela se vzdy do swapu, 
> ale je treba oznacit do ktereho), onen swap je k dispozici a jeho 
> velikost je vetsi nez velikost fyzicke pameti.

Bohuzel nemam sanci zjistit, co se objevilo na konzoli tesne pred tim, 
nez se system odporoucel k rebootu :( Lze tohle vyresit napriklad 
seriovym kabelem do druheho serveru? Zustane tam i po rebootu informace 
o tom, co se stalo tesne pred rebootem?

> 	Doufam, ze jsem na nic nezapomel ...
> 
> 	Pri (pristim) startu systemu je mozne dump ze swapu vytahnout a ulozit 
> si ho jako "normalni" soubor.

> 	Do LOGu se o tom zadny zaznam nedela - system v panicu, delajici tento 
> dump je ve velmi spatne definovanem stavu - ten uz neni zpusobily psat 
> do nejakych souboru - je rad, ze zvladne to raw zarizeni (swap).

Mam takovy pocit, ze kdyz se dump vytvori ve swapu, tak je pri dalsim 
bootu o tom zaznam v messages, ze byl nalezen dump ve swapu, ne? Matne 
si vzpominam, ze jsem neco takoveho parkrat zahlednul, ale tentokrat to 
v logu nebylo.

> 	A nekdy ani to ne - pri urcitem typu zavady je stav systemu natolik 
> spatny, ze neni schopen udelat ani tohle. A to pomijim takove stavy 
> systemu (na urovni hardwarove), ze o vzniklem problemu se OS proste 
> vubec nedozvi. Urcite stavy procesoru (napriklad triple-fault) proste 
> znamenaji okamzity reset - nikomu se nedava prilezitost se o tom 
> dozvedet natozpak s tim neco udelat ...
> 
> 	Neni jiste, ze se dump udelal ...
> 
> 	Nicmene, i v pripade, ze dump nemate, neni to takova skoda - on je 
> celkem k nicemu, pokud nemate jadro (to, ktere bylo aktivni, kdyz to 
> spadlo) prelozene s debugovacimi informacemi.
> 
> 	A dokonce i kdyz je tohle splnene - tak se proste dokazete podivat v 
> kterem miste kodu to spadlo - a jaky byl stav pameti. Ale pokud nejde o 
> nejaky trivialni problem a aktualni pad byl napriklad zpusoben tim, ze 
> obsah pameti byl poskozen nejakou uplne jinou udalosti, ke ktere doslo 
> nekdy drive a ktera sama bezprostredne k padu nevedla, tak to se z 
> takoveho dumpu zjistuje velice problematicky ...

Takze pro me je v podstate pripadny dump jen neuzitecnou hromadou dat, 
ze kterych stejne nic nevyctu :(

[...]

>>Navic po bootu se spusti fsck a pri kontrole posledniho oddilu prvniho 
>>disku dojde opet k samovolnemu rebootu (probehlo jich 5, pak jsem 
>>background fsck zastavil a pokusim se "nejak" zjistit, co vede system k 
>>tomu, ze pri fsck spadne - opet bez jakekoliv hlasky v logu.)
> 
> 
> 	Pad uplne bez varovani (musite byt u console - na dalku to nepoznate) 
> je obvykle spis znamka problemu hardware, nebo komunikace te nejnizsi 
> vrstvy systemu s hardwarem ...
> 
> 	Jeste tak by mohlo jit o poskozeny filesystem v kombinaci s chybou 
> jadra ...

Kdyz jsem stopnul bezici background fsck (pokazde to padlo pri kontrole 
ad4s2d) a pak provedl kontrolu oddilu v popredi primo ze systemu, tak uz 
fsck probehlo az do konce, ale takovym zpusbem, ze mi to napriklad 
smazalo vsechny soubory v adresari mrtg (tedy ne jen vygenerovane grafy, 
ale i ty databazove soubory atd.)

Nalezene problemy pri fsck byly nasledujici:

87036137 DUP I=21785724
UNEXPECTED SOFT UPDATE INCONSISTENCY

87036138 DUP I=21785724
UNEXPECTED SOFT UPDATE INCONSISTENCY

EXCESSIVE DUP BLKS I=21785724
CONTINUE? [yn] y

INCORRECT BLOCK COUNT I=21785724 (96 should be 40)
CORRECT? no

INTERNAL ERROR: dups with -p
UNEXPECTED SOFT UPDATE INCONSISTENCY
** Phase 1b - Rescan For More DUPS

Nakonec hromada (desitky/stovky) hlasek jako je tato

ALLOCATED FRAGS 87881200-87897583 MARKED FREE

a nazaver

514 files, 22374762 used, 62651156 free (572 frags, 7831323 blocks, 0.0% 
fragmentation)

Po teto kontrole a manualnim rebootu uz system bezi zase normalne 
(patrne do pristiho padu)

Je jeste neco, co bych mohl na dalku zapnout (nejaky debug pomoci sysctl 
nastaveni) a mit tak pri dalsim padu vice informaci?

> 	S timhle vam opravdu prilis nepomohu - v podobnych pripadech pomaha jen 
> zarikavani ...

Zarikavam uz mesic a pul. :( Poskytovatel tvrdi, ze Linux jim na 
stejnych strojich bezi bez problemu, tezko rict, jestli je tedy problem 
ve FreeBSD, nebo jen v tom, ze na tech linuxovych strojich nikdo neudela 
takovou zatez, jako ja pri zahorovacich testech.

Miroslav Lachman