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" <d...@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@freebsd.cz) > http://www.freebsd.cz/listserv/listinfo/users-l > -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
