Send mondo Timeout o problema de Hardware y/o Software

Problema de Hardware o Software ? leer todo

Send mondo timeout panic

El equipo, genero un panic y switcheo al otro nodo del cluster, aparentemente seria por hardware, esta es la salida fmdump

Jun 13 07:51:24 sol5002 fmd: [ID 441519 daemon.error] SUNW-MSG-ID: FMD-8000-2K, TYPE: Defect, VER: 1, SEVERITY: Minor
Jun 13 07:51:24 sol5002 EVENT-TIME: Wed Jun 13 07:51:24 ART 2012
Jun 13 07:51:24 sol5002 PLATFORM: SUNW,Sun-Fire-15000, CSN: -, HOSTNAME: sol5002
Jun 13 07:51:24 sol5002 SOURCE: fmd-self-diagnosis, REV: 1.0
Jun 13 07:51:24 sol5002 EVENT-ID: 2ad4ec18-b1a4-eca0-a67d-a268a7af7071
Jun 13 07:51:24 sol5002 DESC: A Solaris Fault Manager component has experienced an error that required the module to be disabled. Refer to http://sun.com/msg/FMD-8000-2K for more information.
Jun 13 07:51:24 sol5002 AUTO-RESPONSE: The module has been disabled. Events destined for the module will be saved for manual diagnosis.
Jun 13 07:51:24 sol5002 IMPACT: Automated diagnosis and response for subsequent events associated with this module will not occur.
Envie un explorer del equipo y explorer de la SC para que lo analizaran en Oracle.

Lo que vi, fue que la falla estaria en el dimm de memoria J16301 . de la SB1,P3,B1

Lo primero que vieron en el analisis del explorer fue lo siguiente :

*///Salida del FMA confirma evento de hardware.
::::::::::::::
fmadm-faulty.out
::::::::::::::
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
faulted fmd:///module/cpumem-diagnosis
2ad4ec18-b1a4-eca0-a67d-a268a7af7071

*///La probalidad de falla es del 100% en memoria RAM, pero no apunta a un FRU especfico.

fmdump-vu_2ad4ec18-b1a4-eca0-a67d-a268a7af7071.out
::::::::::::::
TIME UUID SUNW-MSG-ID
Jun 13 07:51:24.7743 2ad4ec18-b1a4-eca0-a67d-a268a7af7071 FMD-8000-2K
100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis
FRU: -
Location: -

*///Numero alto de errores en DIMM
fmdump-e.out
::::::::::::::
TIME CLASS
Jun 13 03:09:59.7741 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7740 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7736 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7733 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7731 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7730 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 03:09:59.7730 ereport.cpu.ultraSPARC-IVplus.ce

*///Ubicando el origen exacto de la falla, multiples dimms en SB1 involucrados.

fmdump-eV.out |grep unum|more
unum = SB1/P2/B1/D0 J15301
unum = SB1/P1/B1/D0 J14301
unum = SB1/P2/B0/D0 J15300
unum = SB1/P3/B0/D0 J16300
unum = SB1/P3/B1/D0 J16301

unum = SB1/P0/B0/D0 J13300
unum = SB1/P1/B0/D0 J14300
unum = SB1/P0/B1/D0 J13301
unum = SB1/P2/B0/D0 J15300
unum = SB1/P0/B0/D0 J13300
unum = SB1/P0/B1/D0 J13301

1er conclusion

Luego, del analisis del ingeniero del caso, realizado al explorer de la System controller, nos indica que hay muchos RSTOPS reportados, comenzaron en Junio 10, apuntando a DIMMs de SB1/P1

Jun 10 12:14:13 2012 e25k-5-sc0 ssd[1091]: [1319 7280716936303484 NOTICE StartupManager.cc 2602] efhd output: ECC correctable errors detected from Processor Port SB1/P1, no
Jun 10 12:14:13 2012 e25k-5-sc0 ssd[1091]: [1319 7280716944070151 NOTICE StartupManager.cc 2602] efhd output: corresponding parity error in DXs or DCDSs.
Jun 10 12:14:13 2012 e25k-5-sc0 ssd[1091]: [1319 7280716944567150 NOTICE StartupManager.cc 2602] efhd output: Assuming the error originated in memory on this port.
Jun 10 12:14:13 2012 e25k-5-sc0 ssd[1091]: [1319 7280716944976756 NOTICE StartupManager.cc 2602] efhd output: Data syndrome 049 is CE bit 49.
Jun 10 12:14:13 2012 e25k-5-sc0 ssd[1091]: [1319 7280716945364851 NOTICE StartupManager.cc 2602] efhd output: This bit is in one of Dimm SB1/P1/B0/D0 or Dimm SB1/P1/B1/D0.

Jun 10 12:15:24 2012 e25k-5-sc0 dsmd[27493]: [2517 7280787849650558 WARNING Domain.cc 591] Record stop has been detected in domain B.
Jun 10 12:16:14 2012 e25k-5-sc0 dsmd[27493]: [2517 7280837789222307 WARNING Domain.cc 591] Record stop has been detected in domain B.
Jun 10 12:16:46 2012 e25k-5-sc0 dsmd[27493]: [2517 7280869346469788 WARNING Domain.cc 591] Record stop has been detected in domain B.
Jun 10 12:17:02 2012 e25k-5-sc0 dsmd[27493]: [2517 7280886045362988 WARNING Domain.cc 591] Record stop has been detected in domain B.

El 12 de Junio, mas rstops, esta vez sobre DIMMs de SB1/P2

Jun 12 19:37:13 2012 e25k-5-sc0 ssd[1091]: [1319 7480096796647204 NOTICE StartupManager.cc 2602] efhd output: This bit is in one of Dimm SB1/P2/B0/D0 or Dimm SB1/P2/B1/D0.
Jun 12 19:37:13 2012 e25k-5-sc0 ssd[1091]: [1319 7480096797043039 NOTICE StartupManager.cc 2602] efhd output: Bank/Dimm fault attribution for data CEs is the responsibility of

Jun 12 19:37:13 2012 e25k-5-sc0 ssd[1091]: [1319 7480096797435634 NOTICE StartupManager.cc 2602] efhd output: lpost or domain software which has address information that
Jun 12 19:37:13 2012 e25k-5-sc0 ssd[1091]: [1319 7480096797824449 NOTICE StartupManager.cc 2602] efhd output: allows error attribution to a bank. No action taken here.
NW,UltraSPARC-IV+:send_one_mondo+160 (24, 24, 995c5647, 1, 18b1448, 1)


*///Finalmente viene el panic en el dominio en Junio 13.

Jun 13 06:39:34 sol5002 ^Mpanic[cpu35]/thread=2a100a77cc0:
Jun 13 06:39:34 sol5002 unix: [ID 862289 kern.notice] send mondo timeout (target 0x24) [1470496 NACK 0 BUSY]
Jun 13 06:39:34 sol5002 unix: [ID 100000 kern.notice]

*////El rstop mas cercano a esa hora, es este. Donde se reporta falla en los procesadores P2 y P1. de la SB1.-------------------------------------------------------------------
desde la SC, dentro de /var/opt/SUNWMS/adm/B/dump , podemos ver el log de los record stop
redxl> dumpf load dsmd.rstop.120613.0647.41
Created Wed Jun 13 06:47:41 2012
By hpost v. 1.6 Generic 124319-04 Oct 12 2007 11:30:48 executing as pid=20198
On ssc name: e25k-5-sc0.
Primary service FRU is Slot SB1.

redxl> wfail -B
port SB1/P2 # redx wfail of dump 120613.0447.41
port SB1/P3 # redx wfail of dump 120613.0447.41

CONCLUSION de los ingenieros de Oracle
==============================

Panic producido por falla de hardware en SB1.

PLAN de ACCION
===========

Reemplazo de SB1
540-6753
540-6753 [F] CPU/Memory Uniboard w/4× US IV+ 1.8GHz, 0MB

Se recomienda altamente actualizar los patches de kernel para un mejor control de estos eventos.
Referencia:
Systems With UltraSPARC IV+ Processors Running Solaris 9 or 10 May Experience "send mondo timeout" Panic (Doc ID 1019109.1)

Eso hicimos, instalamos los parches recomendados , pero …....
Luego de reemplazar la System Board, y memoria
El equipo levanto.
Luego del boot, se chequeo los eventos fma y vimos esta condicion
 fmd:///module/cpumem-diagnosis degraded, se le hizo un fmadm repair y lo reparo.

el fmdump muestra eventos anteriores sobre el mismo modulo.

Envio el explorer y la contestacion fue :

Hemos revisado la información del explorer del dominio , luego del cambio de la SB1.

//La salida del comando 'fmadm faulty" no muestra enventos.
::::::::::::::
fmadm-faulty.out
::::::::::::::
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
//La salida del comando "fmadm faulty -a" siempre mostrara los eventos anteriores. Estos ya no requieren ninguna accion.

:::::::::::::
fmadm-faulty-a.out
::::::::::::::
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e70d5a
ff12f344-8d86-eac6-832b-92ac8e1063eb
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e712fa
7ea9887b-6631-4a28-806e-d74a61cd4733
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e7368e
44d9d55f-8277-cdeb-f205-8ca3a2d52ab6
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P1/B0/D0,J14300/offset=227500dc

d100412a-3592-493e-95f1-d460a157e15b
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P1/B0/D0,J14300/offset=4657339a

//El FMA (fmdump -e ) reporta eventos nuevamente  uhhhh
Jun 13 17:30:30.2977 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.293 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.3054 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.3113 ereport.cpu.ultraSPARC-IVplus.ce

*///Estos son los DIMMS involucrados.

unum = SB1/P3/B0/D0 J16300
unum = SB1/P2/B0/D0 J15300
unum = SB1/P1/B1/D0 J14301
unum = SB1/P3/B1/D0 J16301

Me pidieron otro explorer del equipo y de la System Controller

Envie un explorer de la sc y me contestaron :

// El ultimo rstop registrado en el equipo, se presento el dia de hoy, 13 de Junio, a las 15:01 horas.
-rw-r--r-- 1 sctools other 2288 Jun 13 15:00 wfailoutput.120613.1659.57
-rw-r--r-- 1 sctools other 1934 Jun 13 15:00 wfailoutput.120613.1700.32
-rw-r--r-- 1 sctools other 2288 Jun 13 15:01 wfailoutput.120613.1701.16 

 El ultimo POST registrado en el equipo, nos indica a que hora fue remplazada la system board y la ultima vez en que el dominio fue encendido.
/// Los logs nos dan la misma fecha: 13 de Junio a las 15:01 horas:-rw-r--r-- 1 sctools other 1035 Jun 13 15:00 post120613.1700.10.log
-rw-r--r-- 1 sctools other 924 Jun 13 15:00 post120613.1700.33.log
-rw-r--r-- 1 sctools other 1035 Jun 13 15:00 post120613.1700.52.log
-rw-r--r-- 1 sctools other 924 Jun 13 15:01 post120613.1701.16.log
-rw-r--r-- 1 sctools other 1035 Jun 13 15:01 post120613.1701.27.log <----


/// Esta es la hora en la que se capturo el explorer de la SC:

=========== SUN(TM) EXPLORER DATA COLLECTOR (Version 5.10) =======
== Esto indica que desde las 15:01, hora en que se levanto por ultima vez el dominio, hasta las 20:42, hora en que se recolecto el explorer, no se han presentado nuevos record stops.


REVISANDO EL EXPLORER DEL DOMINIO
=================================
/ El fma faulty no muestra errores:
$ more fmadm-faulty.ou
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------

/// El fmadm faulty -i tampoco aparecen errores:
$ more fmadm-faulty-i.out
STATE RESOURCE / CACHE-ID
-------- ----------------------------------------------------------------------

// Es en el fmdump -a donde aparecen errores de memoria, pero no se muestra la fecha de origen de dichos eventos:

ATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e70d5a
ff12f344-8d86-eac6-832b-92ac8e1063eb
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e712fa
7ea9887b-6631-4a28-806e-d74a61cd4733
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P0/B1/D0,J13301/offset=22e7368e
44d9d55f-8277-cdeb-f205-8ca3a2d52ab6
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P1/B0/D0,J14300/offset=227500dc
d100412a-3592-493e-95f1-d460a157e15b
-------- ----------------------------------------------------------------------
faulted mem:///unum=SB1/P1/B0/D0,J14300/offset=4657339a
296a078c-9763-6c57-f7c9-89a413657bdc

 En el fmdump -e, aparecen algunos errores que parecieran indicar errores de ecc en memoria y cpu:
bash-3.2$ tail fmdump-e.out
Jun 13 17:30:20.8827 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 17:30:22.9015 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:22.9015 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 17:30:24.8022 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:26.8814 ereport.cpu.ultraSPARC-IVplus.ce
Jun 13 17:30:30.1206 ereport.io.xmits.ecc.dwce
Jun 13 17:30:30.2977 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.2993 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.3054 ereport.cpu.ultraSPARC-IVplus.ivc
Jun 13 17:30:30.3113 ereport.cpu.ultraSPARC-IVplus.ce// Estos son todos los archivos fmdump -vu recolectados en el explorer:
bash-3.2$ ls -lrt | grep fmdump-vu
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_2bd9feed-7269-c64a-8f54-a269a93cec55.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_ca963465-a151-cc2d-9521-a8e0e6749a70.out-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_d002087b-50d0-64c8-fe5a-8de2099fa3b4.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_bd302929-fe79-49bd-b1b4-9c9599c7f7db.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_d1c88b3a-affd-c8fd-b7ad-e161f51f7c2d.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:30 fmdump-vu_92f53876-b809-4969-d00d-dac6859754b6.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:31 fmdump-vu_210c66e3-a939-62c6-d0e3-8b040b97ff82.out
-rwxrwxrwx+ 1 root staff 320 Jun 13 15:31 fmdump-vu_cdf55e54-0758-6e26-9f46-de77a562dd5a.out

/ Revisando del ultimo hacia el primero, se encuentra que siempre se reporta un error en el modulo de fma llamado cpumem-diagnosis:

bash-3.2$ more fmdump-vu_fde87c22-19d6-e8c6-a9a6-a80bb9a1dcf4.out
TIME UUID SUNW-MSG-ID
Jun 13 09:03:58.0344 fde87c22-19d6-e8c6-a9a6-a80bb9a1dcf4 FMD-8000-2K
100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis
FRU: -
Location: -

bash-3.2$ more fmdump-vu_e2ca8c9b-20e2-c419-a73a-e3f0f3198fd2.out
TIME UUID SUNW-MSG-ID

Jun 13 08:46:46.2303 e2ca8c9b-20e2-c419-a73a-e3f0f3198fd2 FMD-8000-2K
100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis
FRU: -
Location: -

bash-3.2$ more fmdump-vu_2ad4ec18-b1a4-eca0-a67d-a268a7af7071.out
TIME UUID SUNW-MSG-ID
Jun 13 07:51:24.7743 2ad4ec18-b1a4-eca0-a67d-a268a7af7071 FMD-8000-2K
100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis

FRU: -
Location: -

bash-3.2$ more fmdump-vu_2af501d9-6d9b-cc47-bfd9-b27d4214a161.out
TIME UUID SUNW-MSG-ID
Jun 08 02:41:09.9915 2af501d9-6d9b-cc47-bfd9-b27d4214a161 FMD-8000-2K
100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis
FRU: -
Location: -

bash-3.2$ more fmdump-vu_9512e0a0-f65f-4d3d-8010-c94ad974d5de.out
TIME UUID SUNW-MSG-ID
Jun 01 02:40:48.2977 9512e0a0-f65f-4d3d-8010-c94ad974d5de FMD-8000-2K

100% defect.sunos.fmd.module

Problem in: fmd:///module/cpumem-diagnosis
Affects: fmd:///module/cpumem-diagnosis
FRU: -
Location: -


== Esta informacion nos direcciona hacia un posible error o bug del fma.


Plan de accion.
1) Limpiar logs de fma.
(aun no se han limpiado todos, ya que en el explorer hay logs con fecha del 1 de Junio y anteriores; si estuviera completamente limpio, veriamos solo logs de fma del dia de hoy).

Favor de aplicar todos los pasos.

Clearing FMA Faults from the O/S
================================

Please run the following commands from the O/S:

1. Run the fmadm faulty command

# fmadm faulty

When you run the fmadm faulty command you may see the output similar to below, and it is the long hex number that is the UUID
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
degraded dev:////pci@8,700000 d83323bd-f87b-6cc9-f754-c62f479c7706

-------- ----------------------------------------------------------------------

**NOTE: if fmadm comes back clean, skip to step 3 and continue

2. Run the fmadm repair command on all the UUIDs.
Since you will probably see the same UUID for each event, you will only need to repair that UUID. If you see different UUIDs, run it on each one.

# fmadm repair d83323bd-f87b-6cc9-f754-c62f479c7706

3. Clear ereports and resource cache

# cd /var/fm/fmd
# rm e* f* c*/eft/* r*/*

4. Reset the fmd serd modules

# fmadm reset cpumem-diagnosis
# fmadm reset cpumem-retire
# fmadm reset eft
# fmadm reset io-retire

5. Reboot the system to clear the errors.
En este punto, es necesario monitorear si aparecen nuevos errores de fma despues del reboot.


2) Si llegara a suceder que el problema continuara (que aparecieran nuevos errores de fma), entonces sera necesario aplicar un POST 96 al dominio ,para descartar en su totalidad que haya una falla de hardware en el system board, memoria o en el expander board.

Para correr el POST 96, es necesario dar de baja y apagar el dominio con un setkeyswitch off y encenderlo con el siguiente comando:

setkeyswitch -d B -l 96 on
donde "B" es el identificador del dominio y "l" es el nivel del POST
A esta Altura, el ingeniero de Oracle, recomendo cambiar el EXPANDER BOARD ( ya habiamos reemplazados 2 SB y Memorias )

Al momento, las cosas venian asi :

El equipo venia presentando record stops desde Diciembre, pero el 13 de Junio a las 07:51 presento un panic.

Con la ayuda de un ingeniero de campo, reemplazamos la system board y todos los dimms de memoria, pero el problema continuaba. Entonces se remplazo tambien la expander board pero el problema persiste.

Se corrio un post 96 con todo este nuevo hardware y no aparecio ningun error.

El ingeniero en sitio hizo la prueba de hacer un boot del dominio desde un dvd de solaris en una version mas reciente a la que esta instalada en el equipo (utilizo Solaris 10 Release 09/10)y el problema persistio, se siguieron presentando los record stops en el dominio.

A esta altura es un kilombo, esto seria un resumen
====================
El equipo genera record stops todo el tiempo cuando el sistema operativo esta corriendo. Los record stops indican problemas en los cpus.
En el sistema operativo, se presentan mensajes de fma que indican errores de memoria.
AUN NO HEMOS PODIDO DETERMINAR SI EL PROBLEMA ES DE HARDWARE O DE SOFTWARE.

De acuerdo al analisis del nuevo ingeniero que tomo el caso se desprende:
Del core generado Jun 13 9:03 ,
- El panic fue debido a un "send mondo timeout", lo cual se traduce a un excesivo numero de CE registrados, sumado a que no se tienen los parches para hacer un mejor manejo de los errores de FMA.
- Los parches de FMA estan desactualizados, se deben actualizar para mejorar el manejo de los mensajes de error (rstops)
- La SB actual no presenta falla en ninguno de sus componentes en Post 96 , pero los rstops siguen generandose.

$ strings vmcore.0 | head
SunOS
sol5002
5.10
Generic_127111-09
sun4u
SUNW,Sun-Fire-15000
send mondo timeout (target 0x24) [1470496 NACK 0 BUSY] --* Indica el problema antes mencionado!!
.symtab
.strtab
.shstrtab


Anexo link con informacion al respecto :

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1019109.1&h=Y
https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1000495.1&h=Y

patch 125369-03 esta obsoleto y reemplazado por 127755-01
patch 137111-01 esta obsoleto y reemplazado por 137137-09

*** Rstops :
------------

Cambian un poco en relacion al Hw instalado pero me da la impresion que la mayor parte de ellos hacen referencia a CE.
por lo que la instalacion de los parches de FMA son necesarios

-Current Action Plan:
--------------------------------------------------------------

1.- Instalar parches faltantes de FMA:
FMA Patch 127755 missing (rps -01, current -01): SunOS 5.10: Fault Manager patch
FMA Patch 127127 missing (rps -11, current -11): SunOS 5.10: kernel patch
FMA Patch 137137 missing (rps -09, current -09): SunOS 5.10: kernel patch
FMA Patch 139555 missing (rps -08, current -08): SunOS 5.10: Kernel Patch
FMA Patch 141444 missing (rps -09, current -09): SunOS 5.10: kernel patch
FMA Patch 142909 missing (rps -17, current -17): SunOS 5.10: kernel patch
FMA Patch 144500 missing (rps -19, current -19): SunOS 5.10: Solaris kernel patch
FMA Patch 147790 missing (current -01): SunOS 5.10: fmd patch
FMA Patch 146582 missing (current -02): SunOS 5.10: fmadm patch
FMA Patch 147705 missing (rps -01, current -02): SunOS 5.10: pciex patch

FMA Patch 147778 missing (current -01): SunOS 5.10: fmd patch
FMA Patch 148629 missing (current -01): SunOS 5.10: xaui patch

2.- Reiniciar equipo y verificar que haya reducido o detenido el numero de rstops

Se abrieron dos escalaciones técnicas, a ingenieros de Kernel y a Ingenieros de Sparc
De las dos escalaciones se logra concluir:

1)causa del panic reportado por cliente en este SR:
Could be a hardware or OBP, firmware and fma patch issues.

Solucion:
Actulizar patches de OS

Solucion implementada:
Patches recomendados del EIS-March-2012 fueron aplicados anoche por FEs. 

2)Respecto a los Rstops.

Estos vienen ocurriendo desde el 2011, son del tipo CE, "errores corregibles" por lo que no
requieren accion.
Solo si el FMA del dominio los reporta deberan ser reemplazados. No se deben cambiar DIMMS que no
esten reportados en logs del FMA.



Plan de accion
================
1. Actualizar patches de SC-SMS

Correr post en nivel 127 domain B.


El post 127 tarda aprox 70 minutos

_________________________________-

Esto conteste yo

Se realizo, el ultimo action plan, que consistia en la instalacion de parches de SC-SMS + un setkeyswitch -d B -l 127.

Al levantar el dominio luego de pocos minutos el FMA reporta errores nuevamente:
[sol5002] /opt/SUNWexplo/output # fmdump -v
TIME UUID SUNW-MSG-ID
Jun 16 02:54:24.5023 79a1d7cf-9a4a-cd58-b57b-ca35d705af4c SUN4U-8001-32
100% fault.memory.datapath

Problem in: hc://:product-id=SUNW,Sun-Fire-15000:server-id=sol5002/component=EX1
Affects: hc://:product-id=SUNW,Sun-Fire-15000:server-id=sol5002/component=EX1
FRU: hc://:product-id=SUNW,Sun-Fire-15000:server-id=sol5002/component=EX1
Location: -

A esta altura ( empezamos un miercoles a las 7am y terminamos un sabado 15 hs ) el ingeniero de campo Ojea Quintana tuvo la solucion final.

Probamos de levantar el sistema operativo con las placas de red unplumbed y levanta sin RecordStop (es decir, sin fallas).

El problema se acoto a lo que es el IO Board, y se reemplazo la IO1 (501-7394 que es el IO board completo).

El cluster levanto sin errores de ningún tipo.