ata3: reiniting channel

[Miroslav Lachman]

Dan Lukes wrote:
> Miroslav Lachman napsal/wrote, On 08/23/06 14:49:
> 
>>Chtel bych se zeptat (a dnes vyjimecne jednoduse) pri cem / proc v 
>>systemu FreeBSD 6.1 dojde za provozu k "samovolne" reinicializaci ata 
>>kanalu?
>>Dnes to vidim poprve a doslo pri tom k padu systemu a rebootu:
>>
>>Aug 23 01:29:16 track ntpd[455]: kernel time sync enabled 2001
>>Aug 23 14:31:35 track kernel: ata3: reiniting channel ..
>>Aug 23 14:33:28 track syslogd: kernel boot file is /boot/kernel/kernel
> 
> 
> 	Hlasku je mozne videt jen za zapnuteho "bootverbose". Vypisuje se na 
> pocatku ata_reinit(). Z chybejiciho "reinit done" soudim, ze k restartu 
> doslo prave v prubehu teto funkce ...

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? Myslim tim, jak to nastavit, 
kdyz k serveru mam jen SSH a nechci s kazdym bootem jezdit do serverovny 
vybrat verbose boot v konzoli.

> 	ata_reinit() se vola
> 1. v prubehu ata_resume (coz se dela pri probouzeni ze sleep)

Sleep jako spanek celeho systemu, nebo sleep jako nejake bezne systemove 
volani? Jelikoz se jedna o server, na kterem zrovna bezel zatezovy test, 
tak urcite nespal :)

> 2. protoze si to nekdo opravneny vyzadal pomoci ioctl IOCATAREINIT

Tim je mysleno manualni `atacontrol reinit`, 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, 
takze ioctl IOCATAREINIT mi zkratka nic nerika)

> 	Moznosti jsou dve:
> 
> 1. chyba je pouze "pod" - pak nas nezajima kdo a proc reinit volal, ale 
> co z toho, co delal, se nepovedlo natolik, ze to vedlo k padu
> 
> 2. chyba je "nad" - to neco, co reinit delal se nepovedlo proto, ze v te 
> chvili byl uz system v neutesenem stavu z duvodu, ktere nastaly drive a 
> jinde
> 
> 
> 	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 
dump nedela i kdyz by se jinak udelal? (opet se omlouvam, ale jelikoz 
systemu nevidim do hloubky, tak jsem ani nikdy nemel potrebu studovat 
memory-dump - navic jsem az do nedavna mel celkem poklidny zivot s 
bezproblemovym FreeBSD, az ted stema dvouma ASUSama se "vsechno zmenilo")

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

Mile rad na tom systemu zkusim cokoliv, co mi konecne pomuze odhalit a 
napravit problemy (kdyz mi tedy nekdo ochotne poradi co) ;]

Opet diky

Miroslav Lachman