ata3: reiniting channel

[Dan Lukes]

Miroslav Lachman napsal/wrote, On 08/24/06 00:06:
> ACPI je zapnuty, mam pocit, ze bez toho mi nepobezi SMP, nebo se pletu?

	No, technicky jsou to zcela nezavisle veci, takze nevidim duvod. Ale je 
mozne, ze nejaka cast systemu je napsana tak, ze to bez sebe nechodi ...

> 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?

	Kdyz budu na ten seriak napojen minicomem se zapnutym logovanim ? Jiste ;-)

	Pokud system pred padem stihl vubec neco napsat. Ale jestli ne, je to 
dukaz bud' hardwaroveho problemu (spise nesouvisejiciho nez 
souvisejiciho s disky), nebo vazne chyby v systemu jako takovem. System 
nema narok padat "nahle a bez varovani" - jedina "dovolena" havarie je 
panic() - a to je vlastne rozhodnuti systemu, ze hodla havarovat a o tom 
se na obrazovce pise (i proc se tak rozhodl).

> 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 

	Defaultni hodnota dumpdev je NO ...

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

	No, tak jsem to sice nerekl, ale je pravda, ze na to, ze je to v 
podstate jediny zdroj informaci o pricine je prilis pravdepodobne, ze 
ani s nim nebude odhalena ...

>>>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.)

> 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.)

	Pak je zrejme, ze je v systemu chyba. Background fsck bezi nad snapem - 
a ano, mohlo by se rozhodnout, ze chyby jsou takoveho razu, ze jsou 
timto zpusobem neopravitelne a je treba je opravit na popredi, na zive 
verzi disku, ale nemuze system shodit a/nebo rebootovat.

> Nalezene problemy pri fsck byly nasledujici:

	I to naznacuje chybu v systemu. Softupdaty by mely zajistit 
konzistentni stav disku. Neplati to pro vypadky napajeni a hardwarove 
zavady disku (proste, pro situace, kdy si system mysli, ze data na disk 
zapsal, ale ve skutecnosti se tak nestalo - kvuli chybe, nebo proto,z e 
disk je jen prevzal do cache a pred vypadkem proudu je uz nestihl 
zapsat) ale jinak by to platit melo. Vcetne panicu a "nahlych" rebootu 
bez varovani.

	Takze, tyhle chyby oznamuji chybu v ovladacich, nebo to, ze doslo k 
nerizenemu zapisu na nespravne (nahodne) misto disku.

	Nic moc povzbuzujiciho ...

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

	Nic me nenapada ...

	Zbavit se tohohle hardware a pouzit nejaky uplne jiny. Obcas neni jine 
cesty ...

						Dan


-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz