Hace un par de días estaba compilando el kernel 2.4.21 en el ordenador de sobremesa y me dió por hacerlo desde un kterminal. Es un equipo que, aunque viejo, no lo utilizo mucho, y cuando lo hago suelo tirar frecuentemente de consola. El caso es que compilando el kernel me dió un signal 4, y no terminó la cosa. Tras varios makes adicionales, el proceso siguió con interrupciones de signals 11 y demás, hasta conseguir terminarlo.
Lo de los signals 11 (en realidad un segmentation fault en gcc) suele ser síntoma inequívoco de problemas hardware, como podéis leer ampliamente en la Signal 11 FAQ. Generalmente, además suelen ser problemas asociados principalmente con la memoria RAM (la principal o la cache). Esto es porque gcc hace un uso intensivo del hard cuando compila alguna cosa "gorda" (léase kernel, X-Window, KDE, GNOME, ...). Sobre todo, tiene un mecanismo que hace de las compilaciones muy "esparsas", esto es, que tienden a ocupar mucha memoria principal. Con una ocupaciones de memoria de cerca del 100% cualquier problema de memoria que hubiera pasado desapercibido ¡plop! surge de la nada para estropearnos nuestra compilación además de nuestra reputación. ;-)
¿Qué hacer ante estos casos? Primero, leernos detalladamente la mencionada FAQ donde nos dan consejos para probar que realmente es el hardware el que falla (aunque gran parte de las veces lo es, salvo en causísticas concretas que se comentan allí, como en los instaladores de RH 5.x, 6.x y 7.x). Incluso se puede hacer una primera acotación sobre qué componente puede ser el "culpable".
Si lo que queremos es verificar la memoria, lo mejor es emplear en memtest86. No os fiéis del chequeo inicial de la BIOS -es pura filfa-, ni de cualquier programa de "verificación" que os encontréis por ahí. No dudo que los habrá fiables, pero no todos lo son. Con memtest86 incluso tenéis una ISO para hacer un CD-ROM de arranque con memtest86 (descomprimido son 1,6 Megas). Y es el mejor método, puesto que así pasamos de sistemas operativos y capas intermedias que puedan "esconder" problemas con la memoria.
Vale, ya nos hemos llevado el disgusto de saber que tenemos la RAM chunga. ¿Y ahora qué? Pues tranquilos, porque Linux Siempre Tiene Solución Para Todo(TM). ;-) Hace tiempo, Rick van Riel leyó esta página pidiendo un parche para Linux que implementara soporte para chips RAM defectuosos, y se puso manos a la obra. El resultado lo podéis encontrar en esta página: BadRAM: Linux kernel support for broken RAM.
BadRAM consiste fundamentalmente en un parche para el kernel que reserva ciertas direcciones y tamaños físicos de memoria para el kernel, impidiendo su utilización y paginación. Esto se consigue pasándole los parámetros adecuados mediante LILO (badram=...). Pero no hace falta que lo hagamos a mano. El propio memtest86 puede extraer esos datos para nosotros en el formato adecuado. El parche está actualmente disponible hasta para la versión 2.4.20 -aunque indica que sin testear-. Eso sí, me temo que todo lo dicho está desarrollado para plataformas x86. Otras arquitecturas podrían encontrarlo inútil (aunque es probable que no sea tan complicado hacer un apaño similar para ellas).
En definitiva, que no debemos asustarnos por que de repente encontremos que nuestra RAM está defectuosa. Bien sea porque es un equipo obsoleto, con formato de memoria difícil de encontrar actualmente, o que sea memoria lo suficientemente cara como para disuadirnos de su sustitución (imaginemos los precios de la RAM de ciertos portátiles o ciertos servidores de "marca"), siempre podemos utilizar badRAM para evitarnos funcionamientos erráticos.
Si les interesa leer algo más acerca de la gestión de memoria en Linux, les aconsejo que se pasen también por linux-mm.org, el sitio oficial del subsistema de memoria del kernel.
