ata3: reiniting channel

[Dan Lukes]

Miroslav Lachman napsal/wrote, On 08/23/06 18:00:
>>>Aug 23 14:31:35 track kernel: ata3: reiniting channel ..

>> 	Hlasku je mozne videt jen za zapnuteho "bootverbose".

> 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

>> 1. v prubehu ata_resume (coz se dela pri probouzeni ze sleep)
> 
> Sleep jako spanek celeho systemu
...
> Jelikoz se jedna o server, na kterem zrovna bezel zatezovy test, 
> tak urcite nespal :)

	Slep v kontextu power managementu. Coz al enemusi nutne znamenat system 
jako celek - v zasade lze uspavat komponenty selektivne. Nicmene, ani to 
by nemelo nastavat "samo".

	Dalsi otazka je, jestli resume je podmineno predchozim sleepem - 
jakkoli to zni logicky.

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

>> 2. protoze si to nekdo opravneny vyzadal pomoci ioctl IOCATAREINIT
> 
> Tim je mysleno manualni `atacontrol reinit`

	Napriklad - nebo jakakoliv jina systemova ci uzivatelska utilita a 
rutina s dostatkem opravneni.

> nebo se toto volani deje i 
> nejak "samo" na zaklade jakesi systemove udalosti, ktera nastava zcela 
> bezne? (omlouvam se za ty dotazy, ale nevidim do systemu tak hluboko, 

	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.

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

>> 	Bohuzel, dostupne udaje neumoznuji zadne velke zkoumani ani jedne z 
>> techto moznosti. A krome analyzy memory-dumpu (kdyby byl k dispozici) me 
>> ani nenapada, jake informace by k odpovedi mohly prispet ...
> 
> Sam bohuzel vice informaci nemam, jen to, co mi poskytnul 
> /var/log/messages, kde opravdu neni zachyceno nic vic predem, ani po 
> tom. O memory-dumpu v logu zadny zaznam neni, znamena to tedy, ze se ani 
> nestihnul vytvorit, nebo jsem nekde neco zakazal/nenastavil, takze se mi 

	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.

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

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

	Abych ukazal, proc ta analyza muze byt prakticky nemozna - vemte chybu 
v komunikaci s nejakou periferii, ktera pomoci DMA prenasi data do 
pameti - sitova karta, radic disku, neco takoveho. V jednu chvili 
naprogramujete (blbe) periferii a jdete si delat neco uplne jineho. A 
ona periferie si resi svoje problemy a kdyz ma data k dispozici, coz je 
za nahodnou dobu, tak je zapise do pameti. A neni-li to tam, kde to ma 
byt, je to nekde jinde a nejspis to neco prepsalo. Ale neda se rict, kdy 
se ta nahodne prepsana pamet projevi a jak - proste se nekdy projevi. 
Informace, jakou instrukci v te chvili vykonaval procesor je celkem k 
nicemu ...

	Cimz nerikam, ze tohle je problem dotceneho stroje - jen chci rict, ze 
ja analyzu toho dumpu delat nebudu, i kdyby byl k dispozici ;-)

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

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

				Zdravi

					Dan


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