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.
