Kernel panic a nefunkcni remote management

[Pavel Baculák]

A náhodou jsi se nekoukal na LOM port log? Mam jednu zkušenost, že občas
pomůže reset LOM portu (přesně v případě, jak jsi popsal, ze se nemůžeš
pripojit) a pak se už vše chová korektně.
V práci používáme velké množství Sun serveru a na vyschlé kondenzátory bych
to spis neviděl. Z toho množství co mi prošlo rukou, byl na platformě x86,
1 X vadny MB. Ale dosti často odcházejí, právě na platformě x86, HDD.

Baci
Dne 14. 4. 2016 11:01 napsal uživatel "Dan Lukes" <dan na obluda.cz>:

> Miroslav Lachman wrote:
>
>> Na pomerne starem stroji Sun Fire x2100 M2 mam FreeBSD 10.3 a o vikendu
>> doslo na kernel panic:
>>
>
>   kernel trap 12 with interrupts disabled
>>   #7 0xffffffff80e3f7de at handleevents+0x18e
>>   #8 0xffffffff80e40118 at timercb+0x318
>>   #9 0xffffffff80e794fc at lapic_handle_timer+0x9c
>>   #10 0xffffffff80d3c42c at Xtimerint+0x8c
>>   #11 0xffffffff803f68e5 at ata_interrupt+0x45
>>   #12 0xffffffff803fdcfe at ata_generic_intr+0x1e
>>
>
> Server v tomhle stavu zustal viset a musel jsem ho restartovat pres IP
>> zasuvky, protoze se nedalo dostat ani na embedded remote management (eLOM)
>>
>
> eLOM by mel byt samostatny chip, se samostatnym OS, na hlavnim procesoru a
> OS zcela nezavisly. V optimalnim pripade i s nezavislou sitovkou.
>
> Dojde-li tedy k soucasne zavade na hlavnim OS i managementu (nemluvim o
> sotuaci, ze management nebyl funkcni uz davno pred tim - coz se u verejne
> dostupnych managementu nezridka stava) pak to spis vede ke spolecne externi
> pricine, ktera zpusobila obe zavady na obou nezavislych systemech.
>
> Spolecnou zavadou je nejcasteji hardwarovy problem, treba vysychajici
> kondenzatory v napajecim zdroji (nebo primo na desce) a s tim souvisejici
> zvlneni/(neod)ruseni neceho, co pak rozlozi funkci obou systemu.
>
> U sdilene sitovky pak pripada v uvahu jeste problem s touto konkretni
> sitovkou.
>
> Do puvodniho HW jsem dal jine disky a zkusil ten server ruzne zatezovat,
>> udelat upgrade OS, reinstalaci baliku a vsechno bezi normalne.
>>
>
> Zavada, kterou jsem popsal, se zpocatku projevuje statisticky.
>
> No a pak to samozrejme muze byt neco uplne jineho ...
>
> takze pri panicu muze dojit k nejake spatne reinicializaci sitovky a
>> prestane fungovat management. (je tahle domenka spravna?)
>>
>
> Panic kod je od bezneho systemu relativne oddeleny a nic slozitejsiho
> nedela - protoze system je v nedefinovanem stavu a je obava, ze pro volani
> standardnich funkci se neco tezce podela. I zapis core-dump souboru se dela
> az po restartu, kdyz uz je system v definovanem stavu.
>
> Takze "vedomy" zasah do sitovky nepredpokladam. Ale panic muze byt nikoliv
> pricina, ale dusledek jine zavady, procesor se uz delsi dobu mohl toulat po
> ahodnych kusech kodu (but' backtrace na to nevypada) a tam se samozrejme
> mohlo dit zcela cokoliv.
>
> Sitovka se taky muze rozhasit i pasivne - tedy ne tim, ze system neco
> udela, ale naopak, tim, ze neco neudela.  Teda, dobre udelana sdilena
> sitovka by nemela, ale nevime s cim tady mame co do cineni ...
>
> Takze zadnou jednoznacnou odpoved necekej ...
>
> Dan
>
> --
> FreeBSD mailing list (users-l na freebsd.cz)
> http://www.freebsd.cz/listserv/listinfo/users-l
>