Depurando modulos en OpenSolaris

Hace ya algo de tiempo había venido experimentando algunos reboots injustificados en mi laptop al momento del inicio de sesión en SXCE b83. Cuando el escritorio empezaba a cargar, repentinamente se congelaba todo el laptop y se reiniciaba el sistema luego de unos segundos después de quedar sin vida. Al principio no le pare bolas, ya que no tenia tiempo para ver que es lo que estaba pasando, sin embargo, ahora que me volvió a pasar (de hecho, de manera más frecuente) y dada la oportunidad que no tengo nada que hacer esta tarde, me puse en la tarea de diagnosticar la razón de las fritadas.

En Solaris (por ende, OpenSolaris), los logs de los crashes son guardados en /var/crash/`hostname` y dependen de la configuración del dump facility, que se configura con dumpadm. En el momento en que el sistema va a colapsar, dependiendo de la configuración del volcado, el servicio SMF de dumpadm guarda una copia en el disco de la memoria física del equipo antes de que este se muriera, y luego de que el dump haya sido guardado, el servicio continua con el reboot del sistema.

# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c1t0d0s1 (swap)
Savecore directory: /var/crash/futurisk
Savecore enabled: yes
#


Pero, ¿que podemos diagnosticar de los volcados?. Utilizando nuestro buen amigo mdb y teniendo los dos archivos requeridos para diagnosticar el problema, podemos ver en que estado estuvo la maquina antes de que se reiniciara el equipo; los archivos son vmcore.X y unix.X, donde vmcore es el archivo que contiene todos los datos del volcado del crash y unix es el que tiene los datos de los módulos que estaban cargados en el kernel al momento de la pataleta.

# mdb unix.0 vmcore.0
Loading modules: [ unix genunix specfs dtrace cpu.generic uppc pcplusmp scsi_vhci ufs ip hook neti sctp arp usba uhci s1394 fctl nca lofs zfs random audiosup sppp ptm crypto ipc md cpc smbsrv fcip fcp logindmux nsctl sdbc sv ii rdc ]
> ::status
debugging crash dump vmcore.0 (64-bit) from futurisk
operating system: 5.11 snv_83 (i86pc)
panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff0005403600 addr=ffffff015134c6e2
dump content: kernel pages only
>

Genial, ahora sabemos que es un page fault. Por lo general esto indica problemas de software, entonces puedo descartar la posibilidad de que mi laptop se este dañando. Sin embargo, ya entrando en gastos con mdb, veamos que otro tipo de información podemos obtener.

> ::panicinfo
cpu 0
thread ffffff014b54e940
message BAD TRAP: type=e (#pf Page fault) rp=ffffff0005403600 addr=ffffff015134c6e2
rdi ffffff015134b000
rsi 0
rdx 40000
rcx 5dae00
[más y más registros...]


Y ahora con la dirección del thread que se estaba ejecutando en el momento del crash, podemos ver el contenido de lo ultimo que paso.

> ffffff014b54e940::findstack
stack pointer for thread ffffff014b54e940: ffffff0005403190
ffffff00054031c0 apic_intr_exit+0x30()
ffffff0005403220 hilevel_intr_epilog+0x11c()
ffffff0005403270 do_interrupt+0xeb()
ffffff0005403280 _sys_rtt_ints_disabled+8()
ffffff0005403460 as_fault+0x6d8()
ffffff00054034e0 die+0xea()
ffffff00054035f0 trap+0x13b9()
ffffff0005403600 0xfffffffffb8001d9()
ffffff0005403720 oss_memset+0x37()
ffffff0005403760 audio_reset_adev+0xfd()
ffffff00054037f0 oss_audio_ioctl+0x1d2()
ffffff0005403830 stop_engines+0x92()
ffffff0005403890 vmix_close+0x124()
ffffff00054038d0 oss_audio_release+0x10b()
ffffff0005403920 oss_close+0x16a()
ffffff0005403950 dev_close+0x40()
ffffff00054039a0 device_close+0xd1()
ffffff0005403a30 spec_close+0x168()
ffffff0005403ab0 fop_close+0x6e()
ffffff0005403b10 ldi_close+0xc2()
ffffff0005403b50 sadasupport_close+0x14b()
ffffff0005403bc0 qdetach+0xbf()
ffffff0005403c60 strclose+0x357()
ffffff0005403cb0 device_close+0xb8()
ffffff0005403d40 spec_close+0x168()
ffffff0005403dc0 fop_close+0x6e()
ffffff0005403e00 closef+0x59()
ffffff0005403ea0 closeandsetf+0x458()
ffffff0005403ec0 close+0x14()
ffffff0005403f10 _sys_sysenter_post_swapgs+0x14b()


Y ese es el ejercicio de hoy. Hasta el momento el problema parece ser de OSS, sin embargo, ¿algún tip de lo que podría estar matando al sistema?

Artículo escrito por Ricardo Lanziano entusiasta del software libre y Solaris para La Comunidad DragonJAR.