Kernel panic a nefunkcni remote management

Dan Lukes dan at obluda.cz
Thu Apr 14 11:01:40 CEST 2016


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



More information about the Users-l mailing list