Guía de estabilidad hardware Linux, Parte 1

1.  CPU troubleshooting

Muchos de nosotros en el mundo Linux hemos tenido alguna vez problemas con el hardware. ¿Cuántos de nosotros hemos configurado un sistema Linux, instalado nuestra distribución preferida, compilado e instalado algunas aplicaciones adicionales y hemos dejado todo funcionando perfectamente solo para encontrar que nuestro sistema tenía un error fatal en el hardware? Si los síntomas son violaciones de segmento aleatorias, corrupción de datos, bloqueos o pérdida de datos es irrelevante -- esta interferencia del hardware hace que nuestro sistema Linux estable sea incapaz de permanecer a flote. En este artículo, miraremos en profundidad cómo detectar CPUs o RAM defectuosas -- permitiendo reemplazar las partes defectuosas, antes de que causen un daño mucho más serio.

Si se están teniendo problemas de inestabilidad y se sospecha que pueden ser ocasionados por el hardware, recomiendo encarecidamente comprobar la CPU y la memoria para asegurarnos de que están funcionando correctamente. De cualquier forma, incluso si no se han experimentado estos problemas, es buena idea realizar estas comprobaciones de memoria y de la CPU. Haciéndolo, puede detectarse un problema de hardware que podría aparecer justo en el momento más inoportuno, causando pérdida de datos o bien horas de frustración buscando la posible causa del problema. La aplicación de estas técnicas adecuadamente nos puede ayudar a evitar muchos dolores de cabeza, si el sistemas pasa todas las pruebas, tendremos la total tranquilidad de saber que nuestro sistema responderá adecuadamente.

Problemas de la CPU

Si se tiene una CPU horriblemente defectuosa, la máquina será completamente incapaz de iniciar Linux o podrá funcionar únicamente durante unos minutos antes de bloquearse. Las CPUs que se encuentran en dicho estado son fáciles de detectar como defectuosas porque los síntomas son obvios. Pero hay muchos otros posibles defectos en una CPU que no son tan fáciles de detectar; generalmente, los errores menos obvios son aquellos que causan que la máquina se bloquee de vez en cuando sin ninguna razón aparente, o causan que ciertos procesos mueran inesperadamente. La mayor parte de inestabilidades de la CPU pueden notarse "ejercitando" la CPU -- dándole gran cantidad de trabajo a realizar, causándole que se caliente y que posiblemente la hagan llegar al límite. Veamos algunas formas de hacer este tipo de pruebas intensivas a la CPU.

Podría sorprendernos oír que una de las mejores pruebas para comprobar la estabilidad de una CPU sea construir Linux -- la compilación del núcleo. El compilador gcc es una gran herramienta para probar la estabilidad general de la CPU, y la construcción del núcleo usa gcc. Con la creación de la siguiente macro y ejecución de la misma en el directorio /usr/src/linux, proporcionaremos a nuestra máquina una prueba de utilización intensiva de la CPU:

#!/bin/bash
make dep
while [ "foo" = "foo" ]
do
  make clean
  make -j2 bzImage
  if [ $? -ne 0 ]
  then
    echo OUCH OUCH OUCH OUCH
    exit 1
  fi
done

Se notará que esta macro compila el núcleo repetidamente. La razón para ello es simple -- algunas CPUs pueden tener problemas técnicos intermitentes, permitiendo compilar el núcleo perfectamente en el 95% de ocasiones, pero causando que la compilación del núcleo falle de vez en cuando. Normalmente, esto se debe a que necesita compilar cinco o más veces el núcleo hasta que llega a calentarse lo suficiente como para llegar a un estado inestable.

En la anterior macro, hay que asegurarse de ajustar la opción -j para que el número posterior sea una unidad mayor que el número total de CPUs en el sistema; en otras palabras, hay que usar "2" en sistemas con un solo procesador, "3" en un sistema con dos, etc. La opción -j le dice a make que compile el núcleo en paralelo, asegurándose de que hay al menos un proceso gcc en ejecución después de que cada archivo de código fuente se compile -- asegurándonos de que estamos haciendo un uso intensivo de la CPU. Si nuestro sistema Linux no se va a usar durante la tarde, iremos adelante y ejecutaremos esta macro, dejando a la máquina recompilar el núcleo durante algunas horas.

Posibles problemas de CPU

Si la macro se ejecuta correctamente durante algunas horas, ¡enhorabuena! La CPU ha superado la primera prueba. De cualquier forma, es posible que la macro falle inesperadamente. ¿Cómo podemos saber si estamos teniendo un problema con la CPU o bien con cualquier otra cosa? Bien, si gcc muestra un error como este, entonces lo más posible es que nuestra CPU sea defectuosa:

gcc: Internal compiler error: program cc1 got fatal signal 11

En este punto, tenemos tres posibilidades con respecto al estado de nuestra CPU:

• Si se teclea make bzImage para restaurar la compilación del núcleo, y el compilador falla exactamente en el mismo archivo, seguiremos intentando hacer make bzImage de nuevo, repetidamente. Si después de unos diez intentos el proceso de compilación sigue deteniéndose en el mismo archivo, el problema podría deberse a un (rarísimo) error en el compilador gcc que sale a la luz por este archivo de código fuente en concreto, en lugar de por una CPU defectuosa. De cualquier forma, estos días, gcc es muy estable, así que lo más probable es que esto no ocurra.
• Si tecleamos make bzImage para restaurar la compilación del núcleo, y obtenemos otro "signal 11" un poco más tarde, entonces quizá la CPU esté dando sus últimos pasos.
• Si tecleamos make bzImage para restaurar la compilación del núcleo, y el núcleo se compila satisfactoriamente, esto no significa que la CPU esté en buen estado. Esto suele significar que el problema técnico de nuestra CPU solo aparece de vez en cuando, normalmente solo cuando la CPU supera una cierta temperatura (una CPU se calienta cuando está siendo usada por un largo periodo de tiempo y puede requerir que compilemos el núcleo varias veces hasta que alcancemos ese punto crítico).

Rescatar la CPU

Si la CPU está experimentando problemas intermitentes de forma aleatoria cuando tiene una carga muy pesada, es muy posible que la CPU no sea defectuosa en absoluto -- puede ser que sencillamente no se esté refrigerando adecuadamente. He aquí algunas cosas que deben comprobarse:

• ¿Está el ventilador (fan) de la CPU conectado?
• ¿Está limpio de polvo?
• ¿Gira el ventilador (y gira a la velocidad adecuada) cuando está en funcionamiento el sistema?
• ¿Está el disipador afirmado adecuadamente a la CPU?
• ¿Hay pasta térmica entre la CPU y el disipador?
• ¿Tiene la carcasa una ventilación adecuada?

Si todo parece correcto, entonces podemos volver a ejecutar la prueba de compilación repetida del núcleo con la carcasa abierta. Dejamos el núcleo que compile durante unos cinco minutos y después ponemos la mano en el interior de la máquina en funcionamiento y tocamos el envoltorio de metal de la fuente de alimentación para ponernos en contacto con la toma a tierra. Entonces, cuidadosamente tocaremos con el dedo el disipador. Si se encuentra anormalmente caliente, entonces es muy posible que la combinación de disipador/ventilador no sea la adecuada para nuestra CPU en concreto. En este caso, debemos mejorar los dispositivos de refrigeración de nuestro sistema -- probablemente, nuestra CPU aún no ha sufrido ningún daño permanente y es todavía completamente funcional.

La última prueba de CPU

La prueba de la compilación del núcleo es una gran forma de comprobar la estabilidad de la CPU, pero hay otra prueba aún más extrema disponible que puede quererse usar. He dejado esta prueba para el final porque si la CPU se encuentra inadecuadamente refrigerada, esta prueba en concreto puede calentarla sobremanera y puede teóricamente causar un daño permanente a la CPU. Esta prueba es para sistemas que han superado la prueba de compilación repetida del núcleo sin el más mínimo problema -- sistemas que querernos asegurarnos de que puedan soportar las mayores cargas imaginables de CPU con facilidad. Si la CPU se encuentra debidamente refrigerada, superará esta prueba, si no la supera necesitaremos refrigerarla aún más.

Para realizar mi última prueba a la CPU, lo primero que hago es ir a la página de lm_sensors (ver Recursos) y descargar el paquete lm_sensors. El código fuente contiene varios módulos para el núcleo que harán de interfaz con todas las características de monitorización de salud (health) que están integradas en casi todas las placas madre modernas. Una vez que este paquete está correctamente instalado y se han cargado los módulos adecuados (puede usarse la macro prog/detect/sensors-detect para que nos muestre toda la información necesaria), veremos que aparecen nuevos archivos y directorios en /proc/sys/dev/sensors. Estos archivos contienen información muy práctica, tal como la velocidad de los ventiladores, la temperatura de la CPU y de la placa madre y las lecturas de voltaje de la misma, todas ellas actualizadas en tiempo real. Recomiendo configurar este paquete para que se compile como módulos y usar la macro sensors-detect para configurar el sistema para que cargue los módulos al inicio, dado que he tenido mejores resultados con esta configuración.

Una vez tenemos los módulos de lm_sensors cargados, recomiendo instalar una utilidad que monitorice nuestra CPU y sensores, que nos permitirá ver la carga en la CPU y las temperaturas en tiempo real sin tener que estar haciendo repetidos cat a archivos que se encuentran en /proc/sys/dev/sensors. Para este propósito uso un pequeño gran programa que se llama gkrellm (ver Recursos). Aquí hay una captura de mi aplicación gkrellm, monitorizando el uso de CPU, la temperatura de la placa madre y muchas otras cosas más:

Ilustración 1.1: gkrellm en funcionamiento

Hay otros monitores gráficos disponibles que son compatibles con lm_sensors; pueden encontrarse gran cantidad de ellos en la página principal de lm_sensors, en la sección "links".

El último paso de preparación es descargar el programa cpuburn (ver Recursos). Este pequeño y práctico programa usa combinaciones preparadas con astucia de instrucciones en código máquina para generar la mayor carga posible en nuestra CPU -- incluso un poco más que con la repetitiva compilación del núcleo. Se incluyen en el archivo varios pequeños programas preparados específicamente para la clase de procesadores P5 y P6, también incluye una versión especial para los AMD K6. Una vez hemos descomprimido el archivo, leemos el archivo README; explica cómo compilar los ficheros incluidos en ensamblador. En cuanto concluyamos, tendremos nuestro propio programa cpuburn.

Ahora, para la prueba. Normalmente lanzo el monitor gráfico para los sensores y después ejecuto el programa cpuburn como root. Entonces veo que la lectura de la temperatura de la CPU aumenta y se estabiliza, por último, dejo cpuburn ejecutándose durante aproximadamente una hora o más. Si se siguen estos pasos y la temperatura de la CPU sigue aumentando hasta una temperatura anormal (70 grados Centígrados ó 160 grados Farenheit, empieza a ser una temperatura anormal), entonces el sistema de refrigeración de nuestra CPU necesita que le prestemos más atención. Si la máquina se cuelga o bloquea, o el proceso cpuburn muere, entonces necesitamos mejorar el sistema de refrigeración -- o puede ser que la CPU no esté conforme a "spec". Se pueden usar las lecturas de la temperatura de la CPU para llegar a esta conclusión. Pero si todo funciona adecuadamente, entonces nuestro sistema estará preparado para enfrentarse a cualquier batalla. Después de una hora o así, podemos hacer un kill al programa cpuburn y continuar con sus operaciones normales.

2.  Problemas con la memoria

Pruebas de memoria

Es realmente importante tener una CPU en la que podamos confiar por completo, es casi tan importante como que tengamos chips de RAM tan sólidos como una roca. Mucha gente cree que los SIMMS y los DIMMS nunca fallan y nunca necesitan que se les hagan pruebas. Desafortunadamente, esto no es así -- la mala memoria es algo muy común, y es algo que todos debemos comprobar y vigilar. Otras personas piensan que mientras que puede haber mala memoria por ahí, cualquier error en la RAM será auto-detectado por la comprobación que hace la BIOS al iniciar el sistema. Esto también es falso; la comprobación de memoria que hace la BIOS no detectará la gran mayoría de malas memorias, así pues, no debemos dejar que la BIOS nos proporcione una sensación de falsa seguridad.

Síntomas de una mala memoria

Bien, hay malas memorias por ahí y puede que alguna de ellas se encuentre en nuestra máquina en este preciso instante. He aquí algunos signos que deben alertarnos en caso de tener una computadora que contenga mala memoria:

• Cuando cargamos un montón de programas a la vez, de vez en cuando hay un programa que muere sin razón aparente.
• De vez en cuando, cuando abrimos un archivo, aparece corrupto. Si lo volvemos a abrir más tarde, esto no ocurre y aparece correctamente.
• Cuando extraemos "tarballs" (tar -xzvf), tar muestra frecuentemente que el archivo está corrupto. Tratamos de extraer el archivo con posterioridad, cualquier otro día, y tar no muestra ningún error. Pueden ocurrir problemas similares tanto con gzip como con bzip2.
• Si se tienen problemas como estos, es muy probable que la RAM de nuestro sistema esté defectuosa. Definitivamente, se querrá usar el siguiente método para comprobar la RAM. Incluso si no se han notado ninguno de estos errores, es una buena idea comprobar la memoria para asegurarnos de que no aparecerán problemas con la misma en el futuro. He aquí cómo hacerlo.

memtest86

Afortunadamente para nosotros, existe un excelente programa basado en Linux para comprobar la memoria que se instala en un disquete de inicio. Se llama memtest86 (ver Recursos para obtenerlo). Crear un disquete memtest es simple. Primero, descargamos el tarball. Después descomprimimos el archivo y construimos la imagen binaria del disco:

# tar -xzvf memtest86-2.5.tar.gz
# cd memtest86-2.5
# make

Después, insertamos un disquete virgen de 3.5" en la unidad, y tecleamos:

# make install

Después de unos pocos segundos, tendremos un disco de 3.5" con un maravilloso programa para comprobar la memoria, listo para poder iniciarse. La mejor forma de realizar esta prueba es encontrar algo de tiempo cuando la máquina pueda quedarse en reposo durante al menos seis horas -- ejecutar la prueba justo antes de marcharnos a dormir (o cuando dejamos de trabajar) es una buena idea. Para empezar la prueba, reiniciamos la máquina con el disquete en la unidad. Cuando el sistema inicie, el programa memtest86 empezará inmediatamente:

Ilustración 2.1: memtest86 comprobando la RAM en mi máquina de desarrollo

Los mayores problemas técnicos (como bits "muertos") se detectarán en segundos. Los fallos ocasionados por patrones específicos de bits (los cuales son desgraciadamente muy comunes) pueden no detectarse durante varias horas, pero a la larga los detectará. Tan pronto como memtest86 detecte un bit defectuoso, aparecerá un mensaje en la parte inferior de la pantalla -- y las pruebas continuarán. Cuando pongamos a funcionar el monitor por la mañana, encontremos que las pruebas han terminado y no veamos ningún aviso en la pantalla, entonces tendremos todas las probabilidades de que la memoria se encuentre en perfecto estado. De cualquier forma, si se siguen experimentando los problemas aludidos en la sección Síntomas de una mala memoria es posible que nuestra RAM tenga un problema técnico muy poco frecuente que haga que tengamos que reemplazarla de todas formas.

Resolviendo problemas de RAM

Espero que toda su memoria esté funcionando correctamente. De todos modos, si somos uno de los desafortunados, puede que no todo esté perdido -- hay algunas cosas que pueden hacerse para "reparar" la RAM con problemas. La primera cosa que sugiero hacer es ir a la configuración de la BIOS y comprobar los parámetros de la memoria. Algunas BIOS tienen una opción de memoria denominada "Turbo Mode" -- obviamente, si tenemos algo así habilitado, entonces deberíamos deshabilitarlo. También es posible que los parámetros de tiempo de la memoria estén ajustados incorrectamente -- se puede tratar de ajustarlos (incrementando la tasa de refresco (refresh rate), disminuyendo el ajuste CAS) y volveremos a ejecutar memtest86 para ver si el problema desaparece.

Si memtest sigue encontrando errores, entonces es el momento de localizar el SIMM o el DIMM defectuoso y quitarlo de la máquina. Si se tiene más de un módulo de memoria instalado, entonces dejaremos un solo módulo (o dos, si se tienen SIMMS), y ejecutaremos memtest86. Vamos probando con todos los módulos uno por uno y podremos determinar aquellos que son defectuosos -- no hay necesidad de tirar a la basura un buen módulo de memoria.

Esto es todo por ahora; en el segundo y último apartado de esta serie, veremos cómo solucionar problemas relacionados con la configuración del hardware, incluyendo problemas con interrupciones IRQ y de latencia PCI. Mientras tanto, pueden consultarse los siguientes recursos.

Recursos

• Descargar el paquete lm_sensors.
• Hacerse con una copia de gkrellm.
• Obtener el programa cpuburn.
• Crear nuestra copia de memtest86.
• Para más información acerca del problema "signal 11", puede comprobarse el PUF Sig 11.
• Se pueden encontrar muchas dockapps Window-maker (algunas de las cuales muestran gráficos de la CPU y datos de los sensores) en la sección de enlaces de Window-maker en Linuxpowered.com.
• Si se está tratando de diagnosticar un problema hardware relacionado con una tarjeta gráfica nVidia, deberían comprobarse las PUF GeForce. Hay mucha información relacionada con Linux y Windows allí.
• Para más información relacionada con la resolución de problemas nVidia, comprobar la Guía nVidia Gentoo de Sven Vermeulen.

Acerca del autor

Daniel Robbins vive en Albuquerque, Nuevo Méjico. Fue el Presidente/CEO de Gentoo Technologies Inc., el Arquitecto Jefe del Proyecto Gentoo y contribuye como autor de varios libros publicados por MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, y Samba Unleashed. Daniel se ha visto involucrado en el mundo de las computadoras de algún modo desde segundo grado cuando se expuso al lenguaje de programación Logo y a una potencialmente letal dosis de Pac Man. Ésto probablemente explica porqué ha sido un artista de gráficos en SONY Electronic Publishing/Psygnosis. Daniel disfruta pasando el tiempo con su mujer Mary y con su hija, Hadassah. Se puede contactar con Daniel en Daniel Robbins.